Search

结构

Version 24.2.9039

结构

知行之桥是一个用于集成业务流程的消息驱动平台。像传统的企业服务总线（ESB）一样，知行之桥提供了一个集中式通信中心，使应用程序、数据库和外部消息传递系统能够相互通信。

知行之桥是 ESB 基本特性的轻量级且可访问的实现。使用了一种简单而轻量级的基于文件的方法，虽然这种方法可能不适合“传统的 ESB”模式，但是知行之桥能以较低的复杂度高效、透明地处理各种业务场景。

设计原则和实施

知行之桥的架构决策源于一套核心设计原则。本节重点介绍知行之桥设计的三个方面：

  • 优先考虑的原则和价值观
  • 对知行之桥的高级理解所必需的核心概念
  • 架构决策以及它们如何符合我们的设计原则

原则和概念部分面向技术和非技术用户。其余的实现部分旨在帮助工程师理解如何利用知行之桥的体系结构。

核心原则

以下是知行之桥设计的主要原则：

  • 透明
  • 简单
  • 模块化
  • 可访问

知行之桥的架构不是上述设计原则在集成平台中实现的唯一方式。以下是对我们的实现选择以及它们如何与我们的设计原则相适应的解释。

概念

在更高的层面上，知行之桥解决方案由三个要素组成：

  • 工作流
  • 端口
  • 消息

工作流

工作流是执行一组自动化数据处理任务的配置工作流。工作流由许多相互连接的端口组成，因此由一个端口处理的数据会自动传递到流中的下一个端口。

在用户界面中，工作流显示在 工作流 页面中。端口被从左侧窗口拖到右侧工作区中，可以配置不同端口间相互连接。下图显示了由两个端口组成的简单流程：AS2 端口和 X12 端口：

两个端口之间的蓝色箭头表示 AS2 端口接收到的数据将自动发送到 X12 端口。将任何端口右侧的蓝点拖动到任何其它端口的左侧将建立这种关系。

工作流中的一系列端口建立了数据处理的逻辑链，因此应设计工作流以完成特定的业务任务。从简单地一直下载文件到根据接收到的业务文档同步多个后端应用程序，这些任务的复杂度可能会有所不同。

可以在知行之桥中配置多个工作流以完成单独的任务。除非它们通过蓝色的流动箭头明确地相互连接，否则它们的行为将彼此独立。

有关工作流的更多信息，请参考工作流部分。

端口

端口是工作流的独立组成部分，对应用程序数据或消息进行操作。每个端口对消息执行特定的操作，并将其传递到流中的下一个端口，或传递给外部参与者（例如，传递到 FTP 目标）。

操作主要分为三类：

  • 接收数据（从传输的文件，数据库输出等）
  • 处理／转换数据（在格式之间转换数据，将数据映射到新结构等）
  • 传输数据（发送／上传文件，将数据插入数据库等）

每次端口执行上述操作之一时，都会处理交易。

在 工作流 页面中，将端口从左侧窗口拖到右侧画布中，以创建端口的实例。单击工作流中的端口，将显示配置设置面板：

根据端口的类型（例如 AS2，SQL Server，XML 等），端口具有一组不同的配置设置。

某些端口，例如 AS2 端口，SFTP 端口等，要么从外部参与者/服务器接收数据，要么将数据发送到外部参与者/服务器（或两者）。这些端口通常位于工作流的开头或结尾，因为这是数据进入或退出应用程序的地方。

其它端口（例如 XML Map 端口，X12 端口等）在应用程序内部本地处理数据。这些端口通常位于已配置的工作流中间，因为它们只能从其它端口（而不是来自外部源）接收数据，并且只能将数据发送到其它端口（而不是外部目标）。

有关工作流的更多信息，请参考端口部分。

消息

当数据在工作流中的端口之间传递时，以消息的形式传递。消息是简单的文件，其中包含供应用程序处理的数据。 消息主要由文件有效负载数据（知行之桥正在处理的数据）和元数据（知行之桥用来跟踪通过应用程序的数据流的信息）组成。

在消息实现部分中对消息进行了更详细的说明，但是重点是，消息是标准 RFC822（Internet 消息）格式的文件。当端口将数据传递到工作流中的另一个端口时，它将数据写入文件，然后将该文件向下传递到下一个端口。

在工作流的每个步骤中，都将消息（文件）接收/下载到应用程序中，在本地（在应用程序内）进行转换，或者从应用程序上载/发送出去。这些操作中的每一个都称为交易。

知行之桥是透明的；通过查看文件系统，可查看如何将消息从一个文件夹复制到另一个文件夹，以及使用常规文本编辑器或其它工具查看消息内容来观察平台内部发生的情况。

实施概述

本节提供有关知行之桥的上述核心概念（消息，端口，流）的实现的技术细节，并解释为什么我们认为我们的实现满足设计原则。

基于文件的架构

知行之桥将所有数据存储在文件系统上的文件中，因此应用程序中的所有内容都保留在磁盘上：

  • 应用程序数据（消息）
  • 配置数据（配置文件和工作流）
  • 日志等

配置的工作流中的端口从 Send 文件夹读取文件（消息），并将文件（消息）写入 Receive 文件夹。当数据从一个端口传递到下一个端口时，这些消息文件将从第一个端口的 Receive 文件夹移动到下一个端口的 Send 文件夹中。

知行之桥在此基于文件系统的基础结构之上提供了 Web UI，可轻松构造和配置流程。但是，在了解了应用程序中使用的文件夹结构和文件约定（如下节所述）后，也可以通过直接操作文件系统来配置知行之桥的流程。知行之桥利用分层文件夹结构来组织应用程序的文件。在文件夹层次结构部分中对此进行了描述。

基本消息结构

基本消息有两个部分：(1) 一组名称-值对作为消息头部，以及 (2) 消息有效负载。 该消息格式一起存储在“.eml”文件类型中，任何标准文本编辑器或电子邮件客户端都可以打开该文件类型。

消息头部

消息头部帮助知行之桥通过应用程序跟踪数据的处理进度。 消息头部包括唯一的消息 ID（帮助知行之桥了解消息的完整生命周期，即使文件名已更改）、端口处理消息时的时间戳、处理过程中可能发生的任何错误以及其他元数据。

消息头部在消息顶部的 headerName: headerValue 语法中，由换行符分隔。 单击知行之桥 中的消息（例如，在端口面板的输入或输出选项卡中）将显示与消息关联的标题，并允许下载消息的文件内容。

消息还用于有助于了解知行之桥在工作流中的杂项值。 例如，当从远程 FTP 服务器上的子文件夹下载文件时，知行之桥使用消息头部来跟踪消息的文件夹路径，以防需要在本地系统上重新创建此文件夹路径。

消息负载

消息负载是应用程序正在处理的实际文件数据。 这是从远程源接收/下载的数据，由转换端口等操作。虽然知行之桥主要使用消息头部来跟踪消息，但消息有效负载包含用户主要关心的数据。

消息有效负载通过两个换行符与消息头部分开。 在文本编辑器或电子邮件客户端中打开知行之桥消息将以纯文本形式显示消息负载。

工作流中的消息

虽然知行之桥在内部使用消息头来跟踪和理解应用程序处理的数据，但除非消息被检查，否则默认对用户隐藏这些详细信息。 例如，知行之桥使用内部消息 ID 来标识消息，但会在输入/输出选项卡、事务日志等中显示公共文件名。

要检查消息的头部，只需单击显示的文件名即可查看更多消息信息。

一旦第一个端口处理文件，消息头部就会被添加到文件中。 在工作流的末尾（在工作流中的最后一个端口处理完消息之后）从消息中剥离消息头部。 换言之，消息头部和“.eml”格式仅在知行之桥工作流中正在处理文件数据时才相关。

消息日志

每当端口处理消息时，知行之桥都会为其处理生成事务日志。 这些日志可以通过 状态 页面中的交易日志访问，或者通过单击端口面板中的消息文件名并选择 下载日志 来访问。

批处理组和批处理消息

消息可以包含多个有效负载，在这种情况下，它们被视为“批处理组”。 批处理组中的每个单独的有效负载都被视为一个“批处理消息”。

批处理组

批处理组是 MIME 格式的文件，其中每个 MIME 部分都是一个单独的批处理消息。 批处理组使用基本消息使用的相同消息头部方案维护有关批处理的元数据。 这些头部信息跟踪整个批次的处理，而不是批次的各个部分。

批处理消息

批处理组中的每条批处理消息都是一个 MIME 部分，其中包含应用程序处理的文件负载数据。 每个批处理消息都包含与 MIME 部分内的有效负载（但不是批处理组）关联的元数据。 因此，批处理消息具有多组元数据：一组用于跟踪整个批处理组的头部，以及批处理中每个单独 MIME 部分（每个批处理消息）的一组单独头部。

消息实现

知行之桥中的消息是磁盘上的简单文件，其中包含应用程序处理的原始数据。消息分为两个部分：

  • 正文 - 应用程序数据有效载荷
  • 头部 - 消息元数据

头部和正文的组合存储在扩展名为 .eml 的 RFC2822 兼容文件中。头部是 name: value 头部的简单列表，由 newline 字符分隔，正文与头部由两个 newline 字符分隔。

正文

收到数据后，知行之桥会生成一条消息（即，将新的消息文件写入磁盘），并将传入的数据用作消息的主体。例如，当 SFTP 端口从远程服务器下载文件时，该远程文件的内容将成为新消息的主体。

当在应用程序内本地处理数据时（例如，将 EDI 转换为 XML 或将文件映射为新格式时），执行该操作的端口将读取输入消息的正文，处理内存中的数据并写入 结果放入输出消息的正文中。

当数据离开应用程序时（例如，将文件上传到远程服务器，将文件发送给对等方或插入数据库时​​），仅发送输入消息的主体。

头部

知行之桥使用描述应用程序如何处理文件的元数据来扩充原始数据文件。这是一些最常见的头部：

  • 唯一的，持久的 消息 ID ，可在整个工作流中识别文件
  • 正在处理的文件的时间戳
  • 处理该文件的所有端口的端口 ID
  • 文件的任何实例由于错误而无法处理

消息头部永远不会被应用程序编辑或覆盖。新的头部始终会附加到现有列表中，以便保留完整的处理历史记录。

批处理组

消息可以一起批处理以提高性能，使大量消息更易于管理。 批处理的多个消息称为“批处理组”。 批处理组是 MIME 格式的文件，其中每个 MIME 部分都是一个单独的批处理消息。 批处理组使用与基本消息相同的消息头部方案维护有关批处理的元数据。 这些头部可以跟踪整个批次的处理，而不是批次的各个部分。

批处理消息

批处理组中的每条批处理消息都是一个 MIME 部分，其中包含应用程序处理的文件负载数据。 每个批处理消息都包含与 MIME 部分内的有效负载（但不是批处理组）关联的元数据。 因此，批处理消息具有多组元数据：一组用于跟踪整个批处理组的头部，以及批处理中每个单独 MIME 部分（每个批处理消息）的一组单独头部。

访问和查看消息

由于消息只是磁盘上的简单文件，因此用户和外部系统可以访问和查看知行之桥系统中当前的消息。使用外部应用程序访问消息仅需要了解在文件系统上何处查找消息 .eml 文件。这些消息文件的确切位置在文件夹层次结构部分中进行了描述。

消息也可以通过知行之桥的 Web UI 以及知行之桥的 REST API 获得。对于已处理消息的任何端口，以及在 状态 页面上的 事务日志 ，消息将显示在输入界面或输出界面中。在以下三个界面中的任何一个界面上单击文件名，都会显示消息信息模式：

该面板中显示的值是消息的头部。单击 下载 按钮可以访问消息的正文。可以通过 下载日志文件 按钮下载与消息关联的日志（如消息日志文件夹部分中所述）。

消息跟踪和日志

消息包含 消息 ID 头部，该头部用作消息的唯一标识符。即使文件本身已重命名，此 消息 ID 仍与文件通过工作流时相同。结果，可以通过引用其 消息 ID 来跟踪整个工作流中任何文件的进度。

知行之桥以两种方式存储日志数据：

  • 应用数据库
  • 磁盘上的详细日志文件

这两种方式以及两者之间的关系将在下文详细说明。

应用数据库

应用数据库 是通过多种方式使用的关系数据库：

  • 存储有关应用程序处理的每笔交易的元数据
  • 存储不特定于任何交易的应用程序操作日志
  • 存储某些端口的状态（例如，当端口正在等待功能性确认文件或回执时）

知行之桥默认自带 SQLite（Windows／.NET）或 Derby（Java）数据库，但也可以配置外部数据库，例如 MySQL 或 SQL Server。知行之桥可以处理应用程序数据库内所有相关表的创建和维护。

交易日志 是应用数据库的表，用于跟踪消息和查找特定交易的日志。该表存储由应用程序处理的每笔交易的元数据，并且元数据包括已处理的消息的 消息 ID 。Web UI 的 状态 页面提供了一个浏览器，用于浏览 交易日志 和数据库中的其它表。

可通过交易元数据（例如 timestamp, filename, ConnectorId 等）查询 交易日志 。为了最大程度地减少数据库占用， 交易日志 中不包含详细的日志记录，而是将他们存储在磁盘上的日志文件中。

详细日志文件

每处理一条消息时，知行之桥都会生成一个与 消息 ID 同名的日志文件夹。该文件夹包含了详细的日志文件，并且特定的日志记录内容取决于发送／接收文件的端口类型。例如，除了本身的 .eml 外，AS2 端口还会记录 MDN 回执，原始请求和响应以及连接日志。

这些日志文件对于仅追踪工作流的消息来说是非必需的；存储在应用数据库中的元数据足以跟踪消息。但是要查找特定交易的详细信息（尤其在进行程序调试时），必需根据消息的 消息 ID 和处理该消息的端口，在磁盘上找到正确的日志文件。

当然，用户一旦清楚 消息 ID ，便可以手动定位到磁盘上的相关的日志文件夹，但是使用应用程序数据库查找这些日志文件更为方便，如下所述。

应用程序数据库和日志文件之间的关联

存储在应用程序数据库中的元数据包括查找与特定交易关联的日志文件所需的内容。知行之桥的 Web UI 和 系统 API 利用此关系可为任何交易提供对日志文件的轻松访问。

状态 页面包括 交易日志 表，其中包含交易元数据。展开任一笔交易记录可显示与交易关联的日志文件；在下文，知行之桥将使用 消息 ID 在磁盘上找到适当的日志文件。

同样，端口设置界面中的输入／输出选项卡，提供对由该特定端口处理的任何交易的访问，也可以展开其条目以便查看和下载交易的详细日志文件。

应用程序数据库还有助于手动导航到保存交易日志文件的适当文件夹。通常，用户会知晓交易的文件名（或时间戳等），而不是内部的 消息 ID 。 交易日志 是可搜索的，因此搜索特定文件名将显示 消息 ID ，用于与该文件名相关的所有交易。文件夹层次结构 部分包含更多的信息，若知道 消息 ID 和端口后，即可找到相关的日志文件夹。

消息实现背后的设计决策

为了使得应用程序数据对用户和外部系统保持透明，因此消息是通过文件系统上的简单数据文件而不是不透明的内部数据通道传递的。知行之桥不是一个在处理过程中隐藏数据的黑匣子。知行之桥可以有效地嵌入到拾取文件或将文件拖放到文件系统上指定文件夹的任何系统中。

同时还希望无需借助于专用工具或程序即可访问消息。消息存储在 RFC2822 兼容文件中，因此任何常用的文本编辑器都可以轻松打开该文件。使用 .eml 扩展名，以便双击该文件将导致系统的默认电子邮件客户端打开消息并显示内容。

为了使消息和日志易于访问和透明，提供了可搜索的交易元数据数据库。该数据库可用于直接访问消息有效负载和详细的日志文件，同时保持较小的数据库占用空间。

端口实现

端口代表工作流中一个独立的步骤。复杂的工作流是通过将任意组端口连接在一起以执行数据处理的逻辑链而创建的。

端口可以执行三种类型的操作：

  • 接收数据并编写输出消息（例如，通过 SFTP 下载远程文件）
  • 读取输入消息并将数据发送给外部方（例如，通过 AS2 发送文件）
  • 读取输入消息，在本地进行处理，并编写输出消息（例如，将 EDI 文件翻译成 XML）

大多数端口可以执行前两个操作（向/从远程接口发送和接收数据），也可以执行最后一个操作（在本地转换数据）。端口执行的每个操作都称为事务。

所有端口从输入文件夹读取输入消息，并将输出消息写入输出文件夹。当工作流中端口相互连接时，知行之桥会自动将消息从第一个端口的输出文件夹移动到下一个端口的输入文件夹。

端口文件和文件夹

端口的每个实例都作为一个文件夹存在于磁盘上，该文件夹的名称与 端口 ID （流程中的显示名称）相同。每个端口文件夹包含以下内容：

  • port.cfg 文件包含配置的设置
  • 在 Send 子文件夹中发送/处理的消息（即输入消息）
  • 在 Receive 子文件夹中接收的消息（即输出消息）
  • 端口处理的消息的日志文件
  • 特定于端口的文件，如映射、模板和脚本

本节说明这些文件夹在应用程序中的作用，而文件夹层次结构部分说明端口文件夹和子文件夹层次结构在中的确切位置。

Port.cfg

每个端口的 port.cfg 文件都包含控制端口行为的设置（即出现在端口用户界面的设置和高级选项卡中的设置）。该文件为 INI 格式：端口设置列在 SettingName = SettingValue 语法中，每行一个设置。

port.cfg 文件支持 indirect values，或使用引用而不是字符串文字设置字段。从概念上来讲，这类似于在应用程序的另一部分设置变量，并在 port.cfg 文件中引用变量名称。有关设置间接值的详细信息，请参考数据目录部分的 Settings.cfg 小节。

在应用程序界面中编辑端口设置在功能上等同于直接在文件中编辑设置。

输入消息

Send 文件夹保存输入消息或排队等待端口处理的消息。

每个应用程序时钟节拍（默认情况下每 5 秒），知行之桥查询文件系统中每个端口的发送文件夹的内容，并将工作线程分派给任何具有可用消息的端口。当一条消息被处理时，知行之桥会在该消息的头部添加处理尝试的时间戳。

知行之桥根据上次修改时间对输入消息进行排序，以便先处理较旧的文件。由于知行之桥在每次尝试时都会附加一个头部，这可以确保导致错误的消息不会通过重复重试而不必要地阻塞端口。

请注意，端口必须启用发送自动化，以便在每个时钟周期处理输入消息。

输出消息

Receive 文件夹保存输出消息，或已由端口接收/下载/处理的消息。

一些端口在处理完输入消息后立即编写输出消息（例如，转换数据格式的端口）。其它端口在不读取输入消息的情况下编写输出消息，例如 SFTP 端口轮询远程服务器以下载文件，或者 AS2 端口被动侦听传入的文件。

当一个端口连接到工作流中的另一个端口时，输出消息不会保留在接收文件夹中，而是传递到下一个端口的发送文件夹中。

日志文件

端口处理的每个事务都会生成一组日志文件。有关事务的元数据被添加到 交易日志 中，详细的日志信息作为文件存储在磁盘上。日志文件总是在 .eml 中包含消息本身，与任何特定于端口的日志文件一起格式化。

默认情况下，日志文件按以下文件夹结构组织：

├── Logs
    ├── Sent
        ├── MessageId_1
        ├── MessageId_2
    ├── Received
        ├── MessageId_3
        ├── MessageId_4

换句话说，日志文件都保存在一个与 消息 ID 名称一致的文件夹中，该文件夹与已处理消息的消息标识相同，位于上一级 Logs 文件夹中的 Sent 或 Received 文件夹中。

可以通过根据生成时间将日志文件夹组合在一起来进一步组织日志。 任何端口的 日志文件夹结构 字段都可以设置为一个时间间隔（例如 Weekly），以便在该间隔内将日志分组在一起（例如，同一周生成的所有日志都保存在相同的子文件夹中）。 这可以通过减小任何单个子文件夹的大小来提高磁盘 I/O 性能。

可能需要使用 交易日志 来查找适当的日志文件夹，方法是确定 消息 ID 或使用应用程序用户界面中的 下载日志文件 功能。

已发送文件

除了详细日志文件，端口还在 Sent 文件夹中维护所有已发送/已处理消息的副本。请注意，此 Sent 文件夹是端口文件夹的直接子文件夹，而不是上一节 Logs 文件夹中的 Sent 文件夹。

Sent 文件夹中的文件仅包含已成功发送的消息的数据负载。出现错误而没有成功处理的消息不会添加到 Sent 文件夹中。

可以通过根据生成时间将它们组合在一起来进一步组织已发送文件。 已发送目录格式 字段可以设置为一个时间间隔（例如 Weekly），以便在该间隔内将文件分组在一起（例如，同一周内发送的所有文件都保存在相同的子文件夹中）。 这可以通过减小任何单个子文件夹的大小来提高磁盘 I/O 性能。

其它配置文件

根据端口类型，某些端口文件夹将包含附加配置文件。这些附加文件包括：

  • map.json
  • script.rsb
  • 模板 XML 文件

这些文件存储映射关系、自定义脚本行为以及端口输入和输出的结构。在磁盘上编辑这些文件相当于在应用程序用户界面中编辑关联的端口设置。

端口实现背后的设计决策

希望流程完全模块化，这意味着每个端口都应该以可预测和直观的方式提供一个简单的功能。知行之桥执行复杂任务的能力来自于组合任意组端口的能力，而端口接口保持简单。通过将端口链分解成离散的步骤，复杂的流程仍然易于理解。

希望与端口相关的所有数据（配置数据、应用程序数据、日志数据等）都易于访问。由于所有这些数据都存放在特定于端口的文件夹中，因此访问数据很简单，只需知道在哪里可以找到该文件夹。配置数据以透明的 INI 格式存储，因此它像消息数据一样，可以用简单的工具轻松查看和编辑。

端口的基于文件夹的方法也使得理解数据如何在端口之间传递变得容易：对消息文件的简单文件移动操作将一个端口的输出转换成另一个端口的输入。知行之桥包含自动建立这些文件移动关系的内置工具，但是同样的结果可以通过直接操作文件系统来实现。

工作流和工作区实现

工作流在文件系统上表示为一个包含工作流中每个端口的位置和连接的 flow.json 文件。此文件的位置在下面的文件夹层次结构部分中指定。

端口在工作流中的位置纯粹是修饰性的，仅在应用程序用户界面中配置流时使用。端口之间的连接在数据处理级别是相关的：在每个端口写完输出消息后，它将查询应用程序引擎，看它是否需要将输出消息传递到另一个端口的输入文件夹。该应用程序使用文件来确定哪个端口（如果有的话）被给予该文件。

可以在同一个画布中配置多个工作流，知行之桥的用户界面允许拖动画布在工作流之间导航。这类似于在线导航地理地图，例如在谷歌地图中查看道路地图。

工作区提供了工作流之间的逻辑分离。每个工作区都提供了一个新的画布，可以在其中将端口配置为逻辑流。扩展谷歌地图的类比，工作区的功能就像完全独立的“行星”。

决定是在不同的工作区还是在同一个工作区内配置新的工作流是首要事项。

文件系统上的工作区

引入新的（非默认）工作区在知行之桥的文件夹层次结构中添加了一组新的文件夹。 workspaces 目录包含在非默认工作区中配置的所有端口的端口文件夹。这个 workspaces 文件夹是下一节中描述的 data 目录的同级文件夹。

工作流和工作区背后的设计决策

保持工作流中各个端口之间简单和模块化关系的最好方法是将工作流视为一个纯粹的逻辑概念。确定数据处理的逻辑系列所需的所有信息已经包含在端口实现中。

工作区能够在更大程度上提供分隔端口的能力。单独的工作区被赋予单独的文件夹来容纳端口，以便文件系统级操作（例如，权限、目录列表）可以容易地分隔到特定的工作区。

文件夹层次结构

由于知行之桥的所有资源都在文件系统上，所以从较低的层次理解知行之桥需要学习应用程序的文件夹结构。本节描述文件和文件夹在磁盘上的组织方式。

为了更好地理解层次结构，查看知行之桥安装的目录视图很有帮助。下图提供了文件夹结构的可视化表示，细节将在下面的小节中解释。

├── Arc
    ├── data
        ├── AS2_Amazon
            ├── Archive
            ├── Logs
            ├── Pending
            ├── Receive
            ├── Send
            ├── Sent
        ├── Database_MySQL
            ├── Archive
            ├── Logs
            ├── Receive
            ├── Send
            ├── Sent
            ├── Templates

请注意，此层次结构假设仅在默认工作区中配置工作流。其它工作区在工作流和工作区部分进行了说明。

根安装目录

知行之桥的所有资源都保存在安装目录中，默认情况下可以在这里找到：

  • Windows: C:\Program Files\CData\CData Arc
  • Linux/: /opt/arc

当知行之桥的 Java 版本托管在像 Tomcat 这样的外部 Java servlet 上时，知行之桥的资源可以在这里找到：

~/cdata/arc

其中 ~ 解析为托管 Java servlet 的用户的主目录.

在 文件夹层次结构中，根安装目录是位于树顶部的 Arc 文件夹。

数据目录

data 目录包含以下内容：

  • 工作流页面（默认工作区）中配置的每个端口的子文件夹
  • profile.cfg
  • flow.json
  • settings.cfg
  • 所有证书文件

Profile.cfg

profile.cfg 文件包含应用程序范围的设置，如配置的本地配置文件（如 AS2 配置文件）。该文件为 INI 格式：应用程序设置列在 SettingName = SettingValue 语法中，每行一个设置。

profile.cfg 设置分为几个部分：一般应用部分的 Application 部分，以及每个配置文件的专用部分（例如，AS2 个人配置的 AS2 部分，本地 SFTP 服务器设置的 SFTPServer 部分，等等）。

在应用程序界面的 个人配置 页面中编辑应用程序设置等同于直接在 profile.cfg 文件中编辑设置。

Flow.json

flow.json 文件包含配置工作流的结构：每个端口实例之间的位置和连接。直接编辑 flow.json 文件与在 工作流 页面中移动或重新连接端口的操作是一样的。

Settings.json

Settings.json 文件包含一个设置列表，这些设置可以在应用程序的其他地方通过使用引用名称而不是值来引用。 这使你能够以不在应用程序中显示它们的方式存储安全值（如密码）。 你还可以使用引用名称来集中配置跨多个实例部署的流。

支持这种集中引用语法的设置将在 Web UI 中有一个钥匙图标，单击该图标可以查看 Settings.json 文件中定义的引用列表。 有关此功能的详细信息，请参阅 全局设置库。

证书

应用程序中创建或上传的所有证书都存储在 data 目录中。通常，证书以公钥/私钥对的形式出现，具有相同的文件名但不同的文件扩展名： .pfx 适用于公钥和 .cer 适用于私钥。应用程序中上传的其它格式的证书将按原样存储。

知行之桥将枚举 data 目录中的证书，以确定通过下拉菜单在用户界面中配置证书时可用的选项。将证书文件直接放在 data 目录中完成了与在应用程序中上传证书相同的事情。

端口文件夹

每个已配置的端口实例在 data 目录中都有一个专用文件夹。这些文件夹的名称与工作流中每个端口的 端口 ID 值（即显示名称）相同。上图中，工作流中的两个已配置端口是 ‘AS2_Amazon’ 和 ‘Database_MySQL’。

文件系统上的端口一节中解释了端口文件夹的内容，以下是端口文件夹中子文件夹结构的概述：

  • 发送（输入）- 端口从此文件夹中读取待发送/处理的消息
  • 接收（输出）- 端口已接收/处理的消息被写入此文件夹
  • 已发送 - 已成功处理的消息副本（原始数据文件格式）被写入此文件夹
  • 日志 - 端口处理的每个消息的详细日志文件
    • 已发送 - 端口已发送的消息的日志；每个消息都有自己的文件夹，由 消息 ID 命名
    • 已接收 - 端口已接收的消息的日志；每个消息都有自己的文件夹，由 消息 ID 命名
  • 归档 - 旧的日志文件被压缩并移动到此文件夹

某些端口可能有其它子文件夹，具体取决于端口类型：

  • Pending - 已处理但等待另一方确认的消息
  • Templates - 端口输入和输出数据的 XML 样式
  • Public - 应该在应用程序中作为公共接口发布的文件放在此文件夹
  • Schemas - 特定于特定端口的 Schema 文件（如 EDI schemas）放在此文件夹

文件夹层次结构背后的设计决策

因为希望知行之桥中的数据是透明和可访问的，所以应用程序中特定文件的位置应该很容易找到。简单的分层文件夹结构有助于确保用户和外部系统知道在哪里查找知行之桥的数据文件。

希望知行之桥的用户界面为应用程序的配置和使用提供一个方便的界面，但也希望应用程序能够完全嵌入到其它解决方案中。理解知行之桥的文件夹结构是将这些其它解决方案指向知行之桥的任何相关数据的全部要求。

自动化

知行之桥的自动化服务为每个端口处理 Send 文件夹中的文件。自动化服务以 5 秒钟的频次循环运行，每一次循环消息都在工作流中向前移动一步。

知行之桥通过向每个端口分配多个线程来支持并行处理，并且每个线程可以在该端口内处理多个文件。每个线程分配的特定线程数量和处理的文件数量取决于配置文件和特定端口设置中的性能设置。

时钟节拍

每隔 0.5 秒，知行之桥会为应用程序中每个已配置的端口枚举输入文件夹的内容。对于输入文件夹中有文件的任何端口，应用程序会根据端口的设置分配工作线程来处理文件。

应用程序并不保证首先枚举哪个端口的输入。当单个端口的输入文件夹中有多个文件时，这些文件将根据上次修改时间按顺序处理（最近修改最少的文件将首先被处理）。

当知行之桥尝试处理文件时，会添加一个带有处理时间戳的消息头，这将更改文件的最后修改时间。这意味着，如果一个文件无法处理（导致错误），与 Send 文件夹中的其它文件相比，它将成为优先级最低的文件。这可以防止单个文件通过重复抛出错误并立即重试导致端口阻塞。

并行处理

启用并行处理后，知行之桥可在单个时钟节拍中将多个工作线程分配到同一端口。这些工作线程的数量和行为由 系统设置 页面的高级设置选项卡中的三个设置确定（其中某些可以被该端口的高级设置页面中的设置覆盖）：

  • 工作池
  • 每个端口最多可容纳线程
  • 每个端口的最大文件数

线程以循环方式分配给端口，因此调整这些值（全局或特定端口）有助于缓解吞吐量问题或防止某些端口占用系统资源。

工作池确定了应用程序可以同时分配给所有端口（组合）的全局最大线程数。当一个线程在一个特定的端口中完成分配给它的工作时，会被回收到工作池中。主机上可用的硬件资源决定了此设置的上限。

每个端口最大线程数确定同时分配给单个端口的最大线程数。分配给端口的每个线程一次处理一个端口的输入文件夹中的文件，直到该文件夹为空（或者直到达到每个端口的最大文件数，如下所述）。一旦达到此条件，分配给端口的线程在完成处理后将被回收到工作池中。对于特定端口，在高级设置中可以覆盖此设置。

每个端口最大文件数限制了单个连接时钟内单个端口中处理的文件数。例如，如果此设置设置为 5，则分配给端口的线程在（共同）处理 5 个文件之后将被回收回到工作池中，即使该端口的 Send 文件夹中仍剩余文件。对于特定端口，在高级设置中可以覆盖此设置。

最大化性能

可以在各个端口内调整每个端口最大线程数和每个端口最大文件数设置，以在某些端口比其它端口需要更多或更少资源时最大化知行之桥的性能。

增加特定端口的每个端口最大线程数告诉应用程序在处理该端口的输入文件时分配更多的系统资源。当特定的端口成为工作流吞吐量的瓶颈时，这很有用。但是，由于线程是以循环方式分配的，因此为许多不同的端口增加此设置可能会导致应用程序耗尽工作池中的线程。在这种情况下，应用程序必须等待其它线程完成并被回收，然后才能将它们分配给其它的端口。

减少特定端口的每个端口最大线程数可以防止该端口在处理文件时严重消耗工作池。有助于避免在循环分配期间应用程序用尽线程以进行分发的问题。但是，如果端口的 Send 文件夹中有许多文件，则较少的线程数可能需要很长时间才能完成文件的处理并被回收回池中（除非还对每个端口最大文件数进行了调整，如下所述）。

增大特定端口的每个端口最大文件数有助于避免经过多个时钟节拍后文件依然滞留在该端口的 Send 文件夹中。这可能有助于提高大容量端口的吞吐量，但是，也可能增加分配给端口的线程长时间不能被回收到工作池（从而导致线程短缺）。

减少特定端口的每个端口最大文件数有助于确保及时将分配给该端口的线程回收到工作池中。但是，这可能意味着，如果 Send 文件夹中的文件数超过了每个时刻的最大处理量，则并非总是在单个时刻内处理文件。

最大化性能是特定于特定环境和用例的。通常，应该为需要处理/发送大量文件的端口分配更多的工作线程，并应允许这些工作线程在回收之前处理更多的文件。为防止线程池用尽，应为其它端口分配较少的工作线程，并且应将这些工作线程限制为较少的文件。

接收自动化

在知行之桥中，上述输入文件的自动处理称为发送自动化。知行之桥还支持接收自动化，该过程描述了端口根据计划的时间间隔将文件拉入知行之桥工作流中的自动化过程。

接收操作分为两类：

  • 从远程主机/服务器下载文件（FTP，SFTP，S3 等）
  • 从后端系统（数据库，ERP 系统，CRM 等）中提取数据并将其写为 XML

接收自动化始终与调度间隔相关，调度间隔确定端口尝试从外部系统下载文件或提取数据的频率。

每个时钟节拍，自动化服务都会检查端口的接收间隔是否已经过去。任何此类端口都会立即建立出站连接，并根据端口的设置提取数据。

某些端口（例如 AS2 端口）被动地侦听要接收的传入数据。这些端口不支持接收自动化，因为它们无法主动轮询外部系统以获取数据。

使用本文档

知行之桥入门不需要完全了解基础架构。但是，剥离应用程序的各层确实提供了一些重要的好处：

  • 评估知行之桥的方法是否符合更具体的技术要求
  • 在更深入的了解和控制下操作和配置应用程序
  • 了解如何将知行之桥作为数据处理解决方案的一部分

评估知行之桥的技术特征

知行之桥是消息驱动的集成框架的轻量级实现。了解其基础可以帮助工程师了解此方法是否适合其特定的业务需求。

阅读本文后，我们希望指导设计决策的原则清晰明了，因为这些原则将继续影响应用程序的成长和发展。了解应用程序设计背后的“原因”可帮助用户做出明智的决定，以决定是否适合他们。

操作自如

知行之桥的 Web UI 提供了用于操作和配置应用程序的可访问界面。对底层体系结构的更好理解有助于用户“在幕后”执行更高级的工作，例如：

  • 创建脚本化管理程序来直接修改知行之桥的文件和文件夹
  • 将文件和文件夹添加到版本控制系统中以维护备份
  • 设置特定文件夹的权限，以对用户访问进行精细控制

此外，我们认为从概念上掌握工作流，端口及其与应用程序数据的关系可以帮助用户快速轻松地配置最佳工作流。我们优先考虑用户以最小的配置开销来利用知行之桥功能集的能力。

在解决方案中使用知行之桥

一旦用户了解知行之桥的文件夹结构，将知行之桥嵌入另一个数据处理系统的过程就很简单。由于知行之桥通过磁盘上一组定义明确的文件夹与系统进行接口，因此从指定文件夹进行读写的任何其它应用程序都可以与知行之桥无缝地传递数据。

舒适度

最后，我们认为工程师们普遍希望了解他们所使用的系统的基础机制。即使上面列出的所有优势均不适用于你的特定情况，我们希望本文档在帮你使用知行之桥构建自己的数据集成工作流时，为你提供了额外的舒适度和熟悉度。