Version 24.2.9039

• 概览
• 先决条件
• 端口配置
  • 设置
    • 转换配置
    • 交换头配置
    • ACK
  • 自动化
    • 自动化设置
    • 性能
  • 通知
    • 端口邮件设置
    • 服务等级协议 (SLA) 配置
  • 高级设置
    • EDI 分隔符
    • 交换头配置
    • 功能组配置
    • 高级设置
    • 消息
    • 日志
    • 特殊设置
• 转换格式
  • X12 转换为 XML
  • XML 转换为 X12
• X12 ACK
  • 交换 ACK，997，和 999
  • 期待 ACK、处理 ACK 和生成 ACK
    • 期待 ACK
    • 处理 ACK
    • 生成 ACK
• 主从层次结构：转换 HLLoop
  • HLLoop 层次结构
    • HLLoop 示例
  • 将 HLLoop 层次结构转换为 XML
• 宏
  • 示例
• X12 操作
  • x12Scan
    • 必须的参数
    • 可选的参数
    • 输出属性
• 常见错误
  • 错误：
  • 错误：

X12 端口支持从 XML 生成 X12 文件以及将 X12 文件转换为 XML。

概览

接收 X12 报文时，X12 端口会验证 X12 交互头部并将 X12 报文转换为 XML。这是一个非常有用的准备步骤，因为 XML 是知行之桥用于处理工作流中数据的主要格式。X12 端口自动读取输入文件以确定与报文相匹配的 X12 模式，然后根据该模式解析报文。

生成 X12 报文时，X12 端口将 XML 文件转化为符合 X12 语法规则的 X12 报文，并应用此端口配置的 X12 交换头信息。这个 XML 文件已在工作流其它位置被转换获取，这一步对于创建 X12 报文非常重要。

注意：可以通过在端口的 测试指示符 设置中选择 Test Data 来避免交换头验证。

X12 端口还可以自动为传入的 X12 报文生成 ACK。有关更多信息，请参考 ACK 部分。

先决条件

开始之前，请确保已为需要处理的文档类型安装了正确的 Schema。X12 端口本身支持以下 Schema 定义：00401、00403 和 00501。可以在知行之桥安装的 app_data/x12_schemas 目录中找到它们。如果需要不同的 Schema ，可以联系我们免费获取其他 Schema 文件。

下载并解压 zip 存档后，将整个文件夹放入 app_data/x12_schemas 目录下适当命名的子目录中。

端口配置

本节包含所有可配置的端口属性。

设置

转换配置

与端口核心操作相关的设置。

• 端口 Id 端口的静态、唯一标识符。
• 端口类型 显示端口类型及其用途的描述。
• 端口描述 一个可选字段，用于提供端口及其在流中的角色的自由格式描述。
• 转换类型 端口是将 X12 报文转换为 XML 文件还是将 XML 文件转换为 X12 报文。

交换头配置

与 X12 文档的交换头相关的设置。 生成文档时，这些设置将作为交换头应用到生成的文档中。 解析文档时，交换头设置用于验证传入文档。

• 发送方 ID 限定符（ISA05） 通过提供值的上下文来限定发送方 ID（ISA06）。
• 发送方 ID（ISA06） 标识 X12 通信中的发送方。
• 接收方 ID 限定符（ISA07） 通过提供值的上下文来限定接收方 ID（ISA08）。
• 接收方 ID（ISA08） 标识 X12 通信中的接收方。
• 控制版本号（ISA12） 标识交换的控制版本。
• 测试指示符（ISA15） 交换的数据是否代表测试数据、生产数据或常规信息。 当此项设置为 Test Data 时，交换头不会被验证。
• 功能组 选中此选项可自动将发送者和接收者标识符添加到 高级 选项卡上的 功能组设置。

ACK

与生成和请求确认相关的设置。

• TA1 ACK 是否发送 TA1 ACK
• 功能性 ACK 是否应返回（接收时）和请求（发送时）功能性 ACK。功能性 ACK 标识接收或拒绝已收到的交换和交换集。
• 功能性 ACK 类型 选中此项以指定是否使用 997 或 999 功能确认。

自动化

自动化设置

与端口自动处理文件有关的设置。

• 发送 切换后，端口将在文件准备好时自动发送文件。
• 重发间隔 端口在重新发送收到否定 ACK 的文件之前等待的时间间隔。 例如，如果交易伙伴收到文件但出现问题并且发回否定 ACK，则此设置指定再次发送文件之前等待的时间。
• 最大次数（异步） 当请求功能性 ACK 时，端口处理输入文件的最大次数。 成功取决于在重发间隔内返回功能性 ACK。 如果未返回成功的功能 ACK，端口将重新发送文件，直到达到最大次数。 如果将此设置为 0，端口将无限期地重新发送文件。

性能

与端口资源分配相关的设置。

• 最大线程数 从线程池中消耗用于处理此端口上的文件的最大工作线程数。 如果设置，这将覆盖 设置 > 自动化 页面上的默认设置。
• 最大文件数 分配给端口的每个线程发送的最大文件数。 如果设置，这将覆盖 设置 > 自动化 页面上的默认设置。

通知

与配置警报和服务等级协议 (SLA) 相关的设置。

端口邮件设置

在执行 SLA 之前，需要设置电子邮件警报以获取通知。 单击 配置通知 将打开一个新的浏览器窗口，转到 系统设置，可以在其中设置系统范围的警报。 有关详细信息，请参阅通知。

服务等级协议 (SLA) 配置

SLA 能够配置期望工作流中的端口发送或接收的数量，并设置期望满足该数量的时间范围。 知行之桥在不满足 SLA 时发送电子邮件警告用户，并将 SLA 标记为 有风险，这意味着如果很快不满足 SLA，则会将其标记为 已违反。 这使用户有机会介入并确定未满足 SLA 的原因，并采取适当的措施。 如果在风险时间段结束时仍未满足 SLA，则将 SLA 标记为违反，并再次通知用户。

要定义 SLA，请单击 添加预期数量条件。

• 如果端口具有单独的发送和接收操作，请使用单选按钮指定 SLA 所属的方向。
• 将 期待至少 设置为期望处理的最小交易数量（交易量），然后使用 每 字段指定时间范围。
• 默认情况下，SLA 每天都有效。 要更改此设置，请取消选中每日，然后选中想要的一周中的几天的框。
• 使用 将状态设置为“有风险” 来指示何时应将 SLA 标记为存在风险。
• 默认情况下，在违反 SLA 之前不会发送通知。 要更改此设置，请选中 发送“有风险”通知。

以下示例显示为预计周一至周五每天接收 1000 个文件的端口配置的 SLA。 如果尚未收到 1000 个文件，则会在该时间段结束前 1 小时发送风险通知。

高级设置

EDI 分隔符

指定哪些字符作为元素、段等的分隔符。

• 数据元素分隔符 分隔文档中各个数据元素的字符。
• 组件元素分隔符 分隔文档中组件数据结构内元素的字符。
• 段终止符 指示文档中段结尾的字符。
• 后缀 附加到段终止符中以区分段。

交换头配置

与 X12 交换头相关的其他设置。

• 授权限定符 (ISA01) 通过提供值的上下文来限定 授权 ID 设置。
• 授权 ID (ISA02) 标识与交换关联的授权级别。
• 安全限定符 (ISA03) 通过提供值的上下文来限定 安全密码 设置。
• 安全密码 (ISA04) 表示有关交换的安全信息。
• 控制标准标识符 (ISA11) 标识 X12 标准。 唯一有效的值是 U。

功能组配置

与X12文档的功能组相关的设置。 这些可选标识符可以帮助对类似的交换进行分组或促进机构中的子寻址。

• 发送方 ID (GS02) 标识 X12 通信中的发送方。
• 接收方 ID (GS03) 标识 X12 通信中的接收方。
• 日期格式 (GS04) 日期戳的格式应如何。
• 时间格式 (GS05) 时间戳应如何格式化。
• 负责机构代码 (GS07) 标识 X12 标准的发行者。
• ID 编码 (GS08) 标识 X12 标准的版本、发行版和行业。

高级设置

先前类别中未包含的设置。

• 批处理 一个交换（Interchange）可以包含多个事务。如果不启用，端口将为交换中的每个事务创建单独的输出文档。如果启用该配置，同一个交换中的所有事务都会被组织输出在一个文件中。仅当 转换类型 为 X12 到 XML 时适用。
• 使用标准 ID 命名 选中后，当将 X12 转换为 XML 时，引用 Id 将用于命名 XML 元素。 仅当 转换类型 为 X12 到 XML 时适用。 例如：
  <_143>value</_143>
  如果未选中此选项，则引用指示符将用于命名 XML 元素：
  <BEG03>value</BEG03>
• 编码 指定字符编码（例如 ASCII 或 UTF-8）。
• 扩展限定符值 选中时，包含 EDI 限定符的 XML 元素包括包含限定符代码和值的子元素。 例如：
  <N101>
   <Code>ST</Code>
   <Value>Ship To</Value>
  </N101>
• 功能性 ACK 默认情况下，所有功能确认（997、999）都会路由到流程图中选择的端口，并且“输出”选项卡中不会接收 XML 转换。 选中此项以使转换后的 ACK 也包含在“输出”选项卡中。 除了新的 EDI 文档之外，这还允许将功能确认集成到目标源中。
• 将描述生成为 将 X12 转换为 XML 时，可以提供 X12 段和元素的描述作为 X12 数据的上下文。 使用此下拉列表可以选择是否将此上下文添加为 XML 注释或 XML 属性。
• HIPAA 模式 选中后，端口将使用一组单独的 EDI Schema ，并在转换和验证文档时应用 HIPAA 约束。 对于除受 HIPAA 约束的医疗保健文档之外的 EDI 文档，此设置将被忽略。
• HIPAA 278 两个单独的 Schema 可用于 278 文档，具体取决于这些文档是否应解释为请求或响应。 选中后，将使用请求 Schema；否则使用响应 Schema。
• 本地文件名格式 用于为端口输出的消息分配文件名的方案。 可以在文件名中动态使用宏来包含标识符和时间戳等信息。 有关详细信息，请参阅宏。
• 嵌套循环 选中后，端口会检测 EDI 数据中嵌入了层次关系的 EDI 结构，并生成 XML，其中这些层次关系表示为父子关系。 有关详细信息，请参阅主从层次结构：转换 HLLoop。
• 延迟处理 放置在输入文件夹中的文件的处理延迟的时间量（以秒为单位）。 这是一个遗留设置。 最佳实践是使用 File 端口 来管理本地文件系统，而不是此设置。
• SNIP 验证 启用后，端口将执行前三个级别的 SNIP 验证以确保 HIPAA 合规性：(1) 文档的语法完整性，(2) 是否存在所需的段以及重复段的适当重复，以及 (3) 索赔行项目和索赔总额之间正确的数学关系。 更高级别的 SNIP 验证 (4+) 可能需要 验证端口 或自定义脚本。
• 严格模式验证 当检测到以下情况时，端口是否应忽略、警告或失败：重复计数超过允许的数量、缺少必需的元素或段、无效的限定符和代码值、不允许的元素长度以及无效元素 价值观。 选择“禁用”会关闭 Schema 验证检查。
• 跟踪 ISA06 是否将 ISA06 值作为跟踪头添加到已处理的消息中。 运行 EDI 报告 时需要这些消息头。
• 跟踪 ISA08 是否将 ISA08 值作为跟踪头添加到已处理的消息中。 运行 EDI 报告 时需要这些消息头。
• 跟踪事务类型 是否将事务类型作为跟踪头添加到已处理的消息中。 运行 EDI 报告 时需要这些消息头。
• 验证标识符 检查此项以确保已翻译文档中的标识符与端口配置中的标识符匹配。
• 上传 Schema 使用此选项可上传架构并将其安装在端口的架构文件夹中。如果架构已存在，系统会询问您是否要覆盖它。
• 重置状态 EDI 端口会跟踪已使用的控制编号并增加该编号以确保将来的运行不会重复数据。使用此按钮可将计数器重置为其初始状态，而无需更改任何配置的设置。

消息

• 保存至 Sent 文件夹 选中此选项可将端口处理的文件复制到端口的已发送文件夹中。
• 已发送文件夹方案 指示端口根据选定的时间间隔对已发送文件夹中的消息进行分组。 例如，Weekly 选项指示端口每周创建一个新的子文件夹，并将该周的所有消息存储在该文件夹中。 空白设置告诉端口将所有消息直接保存在“已发送”文件夹中。 对于处理许多消息的端口，使用子文件夹有助于保持消息的组织性并提高性能。

日志

• 日志级别 端口生成的日志的详细程度。 当请求支持时，请将其设置为 Debug。
• 日志子文件夹方案 指端口根据选定的时间间隔对日志文件夹中的文件进行分组。 例如，Weekly 选项表示端口每周创建一个新子文件夹并将该周的所有日志存储在该文件夹中。 空白设置告诉端口将所有日志直接保存在 Logs 文件夹中。 对于处理大量事务的端口，使用子文件夹有助于保持日志井井有条并提高性能。
• 保留消息副本 检查此项以使已处理文件的日志条目包含文件本身的副本。 如果禁用此功能，可能无法从 输入 或 输出 选项卡下载文件的副本。

特殊设置

特殊设置 适用于特定用例。

• 其他设置 允许在以分号分隔的列表中配置隐藏的端口设置，例如setting1=value1;setting2=value2。 正常的端口用例和功能不需要使用这些设置。

转换格式

以下各节详细介绍了将 X12 转换为 XML 的过程，以及将 XML 转换为 X12 的过程。

X12 转换为 XML

将 转换类型 设置为 X12 转换为 XML 表示端口将传入的 X12 文档解析为 XML。 端口首先读取文档的“交换”和“功能组”部分的所有头部信息，并根据配置的端口设置验证它们（除非测试指示符设置为 Test Data）。 然后，端口解析文档中使用的特定 X12 Schema ，并从磁盘上的 x12_schemas 文件夹加载 Schema （其他 Schema 文件，请联系 support@kasoftware.cn）。 使用该 Schema ，端口生成表示文档的 X12 结构的 XML，使用文档中的值填充 XML，并以 XML 注释或 XML 元素中的属性（基于 * 的值）的形式为每个值提供上下文。 生成描述为）。

要使用一组测试 X12 文档查看此过程，请导航到 X12 端口的“输入”选项卡（将 转换类型 设置为 X12 转换为 XML）并选择 更多 > 创建测试文件。 发票、采购订单、采购订单确认和发货通知的 X12 文档会自动生成并放置在输入目录中。 端口处理这些测试文件后，导航到“输出”选项卡以查看生成的 XML。

一旦 X12 报文被转换成 XML，数据就可以通过多种方式进行转换和操作。通常，X12 数据需要存储在数据库或其它后端应用系统中。因为知行之桥使用 XML 来表示这些后端系统中的插入，所以存储 X12 数据就变成了简单地将一个 XML 结构映射到另一个 XML 的问题。通常是用可视化设计器驱动 XML Map 端口。

XML 转换为 X12

将 转换类型 设置为 XML 转换为 X12 指示端口根据文档的 XML 表示形式生成 X12 文档。 端口根据从 XML 解析的数据构建 X12 消息后，会根据配置的端口设置添加功能组和交换头部。

要使用一组测试 XML 文件查看此过程，请导航到 X12 端口的“输入”选项卡（将 转换类型 设置为 XML 转换为 X12）并选择 更多 > 创建测试文件。 将自动生成发票、采购订单、采购订单确认和发货通知的 XML 文件放置在输入目录中。 端口处理这些测试文件后，导航到“输出”选项卡以查看生成的 X12 文档。

X12 ACK

以下章节详细介绍了三种 X12 ACK，以及知行之桥期待，处理和生成的 ACK。

交换 ACK，997，和 999

TA1 是 交换 ACK 的一种普遍接受的交换确认形式。这表明双方之间已经发生了数据交换，尽管不一定交换了报文。这作为接收方发给发件人的收据，表明接收方已成功收到 EDI 消息，但未指定在处理消息内容时是否存在任何问题。

997（版本 4010）、997（版本 5010）或 999 确认被视为功能性 ACK，即单个消息（例如发票或采购订单）已被接受的确认。 这些是根据双方的双向协议生成的。

期待 ACK、处理 ACK 和生成 ACK

期待 ACK

X12 端口在 XML 到 X12 模式下运行时，可以进行配置，以便可以要求互换和功能确认。 在“设置”选项卡的 ACK 部分中选中 TA1 ACK 或 功能性 ACK 时，端口将保持传输的 ‘Pending ACK’ 状态，直到返回并处理相应的 ACK 。 这意味着端口状态可用于确定收件人是否已确认他们收到了交换。

下图显示了收到发票时创建 ACK 涉及的逻辑流程：

上图中，以 XML 转换为 X12 模式运行的 X12 端口生成要交换的文档 （1）在文档传输到交易伙伴时保持为 Pending ACK 状态。交易伙伴根据其业务逻辑处理传输，并根据配置的转换配置创建 ACK。（2）返回 ACK 后，将根据下一部分 （3）中的信息进行处理。

处理 ACK

在典型的工作流中，X12 ACK 将到达以 X12 到 XML 模式运行的 X12 端口。可以将该 X12 端口配置为自动将所有收到的 ACK 路由到最初生成 ACK 文档的 X12 端口。也可以在一个工作流中直观地配置 X12 端口之间的 ACK 路由，方法是将一个 X12 端口（处于 X12 到 XML 模式）的底部边缘的灰色点拖动到另一个 X12 端口（处于 XML 到 X12 模式）上。

一旦 X12 端口在 XML 转换为 X12 模式下接收到路由的 ACK，会将 ACK 与原始消息进行匹配，并将其状态从 ‘Pending ACK’ 更新为 ‘Sent’。

生成 ACK

当处于 X12 到 XML 模式的 X12 端口收到一条消息并生成相应的 XML 时，它可以自动为收到的消息生成 ACK。为此，请在“设置”选项卡的 ACK 部分中启用 TA1 ACK 或 功能性 ACK。必须将这些 ACK 路由到另一个 X12 端口（处于 XML 到 X12 模式）以最终确定 ACK。ACK 路由到的端口将应用交换头部，并将 ACK 传递到工作流中的下一个端口，就像其它 X12 消息一样。也可以在一个工作流中直观地配置 X12 端口之间的 ACK 路由，方法是将一个 X12 端口（处于 X12 到 XML 模式）的底部边缘的灰色点拖动到另一个 X12 端口（处于 XML 到 X12 模式）上。

下图显示了收到发票时创建 ACK 涉及的逻辑流程：

如上图所示，在交易伙伴发送了一条要求确认的消息后 （1） X12 转换为 XML 模式下的 X12 端口解析文档会自动生成一个 ACK （2） 该 ACK 是一个 XML 文件，其中包含与交易相关的交易信息。然后，此 XML ACK 将以 XML 转换为 X12 模式（3）路由至 X12 端口，以便在将 ACK 发送至交易伙伴之前使用交易头部（和其它 EDI 方协议设置）。

主从层次结构：转换 HLLoop

在 EDI 文档中，大多数层次结构关系由 EDI 段的顺序表示。但一些 EDI 结构，例如 HLLoops （预先装运通知 或 X12 856s中）不遵循此约定，而是将层次结构关系嵌入到 EDI 元素数据本身中， 当将 EDI 数据转换为 XML 时， 保留这些层次关系变得困难。 X12 端口通过“高级”选项卡高级设置 中的 嵌套主从细节循环 设置支持在 HLLoop 中保留层次结构关系。启用后，端口将解析 HLLoop 段中的元素，以确定哪些段“属于”层次关系中的其它段。这些层次结构关系在输出的 XML 中反映为“父子关系”。换句话说，此设置将 EDI 内容隐含的层次结构转换为 XML 结构表示的层次结构。

本节将简要说明如何在 HLLoop 数据中编码层次结构，以及在启用 嵌套主从细节循环 时如何将此层次结构转换为 XML。

HLLoop 层次结构

所有 HL 段均具有两个有助于建立层次结构的值：

• ID 值，它标识当前的 HL 段（此值存储在 HL01 或 HL 段中的第一个元素中）
• 父 ID 值，标识当前 HL 段的层次结构父级（此值存储在 HL02 中或 HL 段中的第二个元素中）

例如，假设 HL 段的 ID 值为 ‘2’。如果下一个 HL 段以分层关系“属于”该段，则下一个 HL 段的父 ID 应为 “2”。

如果 HL 段的父 ID 为 “0”，则表示该段没有父级（即位于层次结构的顶层）。

HLLoop 示例

为了进一步阐明 HLLoop 数据中的层次结构关系，请使用以下 EDI 代码段作为样本输入（仅以 HL 开头的行与确定数据层次结构相关；其余的段被包括在内以更紧密地代表实际的 EDI 数据）：

HL*1*0*S      // 第一个 HL 循环，装运循环
TD3*RR*SEAU*1234567
HL*2*1*O      // 第二个 HL 循环，订单循环
PRF*PO111111
HL*3*2*P      // 第三个 HL 循环，第一个包装循环
MAN*UC*PACKAGE1
HL*4*3*I      // 第四个 HL 循环，第一个物料循环
MAN*UC*ITEM_1
HL*5*3*I      // 第五个 HL 循环，第二个物料循环
MAN*UC*ITEM_2
HL*6*2*P      // 第六个 HL 循环，第二个包装循环
MAN*UC*PACKAGE_2
HL*7*6*I      // 第七个 HL 循环，第三个物料循环
MAN*UC*ITEM_1
HL*8*6*I      // 第八个 HL 循环，第四个物料循环
MAN*UC*ITEM_3

在此数据中，第二个 HL 段以分层关系“属于”第一个 HL 段。可以通过查看以下段的 HL01 和 HL02 的值来确定：

• 第一个 HL 段的 HL01（ID） 的值为 “1”
• 第二个 HL 段的 HL02（父 ID） 的值也为 “1”

将父 ID 值与 ID 值进行匹配相同的过程可用于确定数据中的层次关系。

将 HLLoop 层次结构转换为 XML

启用嵌套主从细节循环时, X12 端口会自动处理 HL 层次结构到 XML 层次结构的转换。端口从 EDI 输入中解析 HL01 和 HL02 元素值，并确保 XML 元素正确嵌套（缩进）在代表其父元素的元素内。

查看 HL 层次结构如何转换为 XML 层次结构，启用嵌套主从细节循环时，将从上面的示例 HL 数据生成以下 XML 输出:

<HLLoop1_S>
  <HL><HL01>1</HL01><HL02>0</HL02><HL03>S</HL03></HL>
  <TD3><TD301>RR</TD301><TD302>SEAU</TD302><TD303>1234567</TD303></TD3>
  <HLLoop1_O>
    <HL><HL01>2</HL01><HL02>1</HL02><HL03>O</HL03></HL>
    <PRF><PRF01>PO111111</PRF01></PRF>
    <HLLoop1_P>
      <HL><HL01>3</HL01><HL02>2</HL02><HL03>P</HL03></HL>
      <MAN><MAN01>UC</MAN01><MAN02>PACKAGE1</MAN02></MAN>
      <HLLoop1_I>
        <HL><HL01>4</HL01><HL02>3</HL02><HL03>I</HL03></HL>
        <MAN><MAN01>UC</MAN01><MAN02>ITEM_1</MAN02></MAN>
      </HLLoop1_I>
      <HLLoop1_I>
        <HL><HL01>5</HL01><HL02>3</HL02><HL03>I</HL03></HL>
        <MAN><MAN01>UC</MAN01><MAN02>ITEM_2</MAN02></MAN>
      </HLLoop1_I>
    </HLLoop1_P>
    <HLLoop1_P>
      <HL><HL01>6</HL01><HL02>2</HL02><HL03>P</HL03></HL>
      <MAN><MAN01>UC</MAN01><MAN02>PACKAGE2</MAN02></MAN>
      <HLLoop1_I>
        <HL><HL01>7</HL01><HL02>6</HL02><HL03>I</HL03></HL>
        <MAN><MAN01>UC</MAN01><MAN02>ITEM_1</MAN02></MAN>
      </HLLoop1_I>
      <HLLoop1_I>
        <HL><HL01>8</HL01><HL02>6</HL02><HL03>I</HL03></HL>
        <MAN><MAN01>UC</MAN01><MAN02>ITEM_3</MAN02></MAN>
      </HLLoop1_I>
    </HLLoop1_P>
  </HLLoop1_O>
</HLLoop1_S>

快速分辨出差异是有一定的困难的，但是要注意的关键是，HLLoop 段不包含在其它段中（即，在 XML 中具有父子关系），这与原始 HL01 和 HL02 的值一致。

宏

在文件命名策略中使用宏可以提高组织效率和对数据的上下文理解。 通过将宏合并到文件名中，可以动态地包含相关信息，例如标识符、时间戳和消息头信息，从而为每个文件提供有价值的上下文。 这有助于确保文件名反映对组织重要的详细信息。

知行之桥 支持这些宏，它们都使用以下语法：%Macro%。

示例

某些宏（例如 %Ext% 和 %ShortDate%）不需要参数，但其他宏则需要。 所有带有参数的宏都使用以下语法：%Macro:argument%

以下是带有参数的宏的一些示例：

• %Header:headername%：其中 headername 是消息上消息头的名称。
• %Header:mycustomheader% 解析为输入消息上设置的 mycustomheader 消息头的值。
• %Header:ponum% 解析为输入消息上设置的 ponum 消息头的值。
• %RegexFilename:pattern%：其中“pattern”是正则表达式模式。 例如，%RegexFilename:^([\w][A-Za-z]+)% 匹配并解析为文件名中的第一个单词，并且不区分大小写（test_file.xml解析为test） 。
• %Vault:vaultitem%：其中 vaultitem 是 vault 中项目的名称。 例如，%Vault:companyname%解析为存储在保管库中的companyname项的值。
• %DateFormat:format%：其中 format 是可接受的日期格式（有关详细信息，请参阅示例日期格式）。 例如，%DateFormat:yyyy-MM-dd-HH-mm-ss-fff%解析为文件上的日期和时间戳。

还可以创建更复杂的宏，如以下示例所示：

• 将多个宏组合在一个文件名中：%DateFormat:yyyy-MM-dd-HH-mm-ss-fff%%EXT%
• 包括宏之外的文本：MyFile_%DateFormat:yyyy-MM-dd-HH-mm-ss-fff%
• 在宏中包含文本： %DateFormat:'DateProcessed-'yyyy-MM-dd_'TimeProcessed-'HH-mm-ss%

X12 操作

除了知行之桥提供的 运算器 之外，端口还可以提供将功能扩展到 ArcScript 的运算器。

这些端口运算器的调用方式与任何其他 ArcScript 运算器一样，但有两个细节除外：

1. 必须通过 connector.rsc 接口调用它们。
2. 它们必须包含身份验证令牌。

例如，使用这两个规则调用端口运算器可能如下所示：

<arc:set attr="in.myInput" value="myvalue" />
<arc:call op="connector.rsc/opName" authtoken="admin:1j9P8v8b9K0x6g5R5t7k" in="in" out="out">
  <!-- 处理此处运算器的输出 -->
</arc:call>

下面列出了 X12 端口特定功能的操作。

x12Scan

从 X12 文档的标题中扫描标题值。

必须的参数

• file: X12 文件的路径。

可选的参数

• format: 文件格式。默认值为 ‘X12’。

输出属性

• InterchangeSenderIdQualifier: 发送方 ID（ISA05）限定符。
• InterchangeSenderId: 发送方 ID（ISA06）。
• InterchangeReceiverIdQualifier: 接收方 ID（ISA07）限定符。
• InterchangeReceiverId: 接收方 ID（ISA08）。
• InterchangeControlNumber: 唯一标识 EDI 交换的值（ISA13）。
• FunctionalGroupSenderId: 功能组配置中发送方 ID（GS02）。
• FunctionalGroupReceiverId: 功能组配置中接收方 ID（GS03）。
• DocumentType: 文件类型或交易集标识符代码（ST01）。
• StandardVersion 此交换中使用的 X12 标准的主要版本（例如 00401、00501）。

常见错误

以下列出了常见错误，以及原因和建议的解决方案。请联系 support@kasoftware.cn 了解更多信息。

错误：

“Schema file not found ([schema major version] [schema document type])”

原因

知行之桥解析 X12 报文时，首先在报文中扫描 EDI 版本和文档类型，以确定在解析过程中使用哪种模式。该应用程序包含一组广泛的 JSON 格式的 X12 模式，存储在根安装目录的 ‘www\app_data’ 文件夹中。（在“数据”文件夹旁边）

此错误表明应用程序找不到与报文的主要版本和文档类型相匹配的 schema 文件。

如果错误消息中缺少 [schema 主要版本] 值或 [schema 文档类型] 值，则表明 EDI 报文不包含主要版本或文档类型。

否则，这表明知行之桥随附的 schema 定义集中未包含相应的 schema。

解决

如果 EDI 文件不包含 Schema 主版本或文档类型，请与交易伙伴（或 EDI 文档的其它来源）联系并告知他们这些值必须包含在消息头部中。

否则，请联系 support@kasoftware.cn 获取合适的 Schema 版本。并将新的 Schema 文件夹放置在以下路径中：

1. 在磁盘上的 Schema 文件夹内（例如 <ConnectorDirectory>/Resources/Schemas/）
2. 如果一个 Schema 被多个端口使用，建议使用如下文件夹结构：<ApplicationDirectory>/schemas/<type>_schemas/<major version>。 在此示例中，<type>应为x12。

错误：

“行 [line number] 中带有标签 [segment name] 的段在指定模式（[schema 主要版本] [schema 文档类型]）中的有效位置无效。这表明输入文件中包含无序的的段。”

原因

知行之桥解析 X12 报文时，将首先在报文中扫描 EDI 版本和文档类型，以确定在解析过程中使用哪种 schema。该应用程序包含一组广泛的 JSON 格式的 X12 schema，存储在根安装目录的 www\app_data 文件夹中。

此错误表明解析器在报文中遇到的 EDI 段与相关文档 schema中定义的段的顺序不匹配。这可能表明一些不同的问题：

• 交易伙伴生成的 EDI 报文错误
• EDI 报文由不同于报文中指示的 schema 版本生成
• EDI 报文由自定义 schema 生成

解决

如果 EDI 报文由自定义 schema 生成，只需将该自定义 schema 文件（以 JSON 格式）放在知行之桥读取 EDI schema 的文件夹中。端口通过按顺序检查以下位置来搜索模式：

1. 在磁盘上的 schema 文件夹内（例如 <ConnectorDirectory>/Resources/Schemas/）
2. 如果一个 schema 被多个端口使用，建议使用如下文件夹结构：<ApplicationDirectory>/schemas/<type>_schemas/<major version>。 在此示例中，<type>应为x12。

如果未使用自定义 schema 生成 EDI 报文，则有两种方法可以解决由交易伙伴生成的 EDI 报文和用于解析该报文的 EDI schema 之间的差异。

1. 手动编辑适当的 EDI schema 文件（在上面的文件路径中找到），以调整段顺序，使其与交易伙伴的 EDI 报文匹配。错误消息指示报文中段与 schema 定义不同的行。跟踪细分顺序的 JSON 定义，直到找到差异为止，然后对 JSON 中的细分重新排序以匹配交易伙伴提供的报文。
2. 有关 EDI 报文，请与交易伙伴联系。确认报文是根据与报文相匹配的主要版本生成的，并说明未识别报文中段的顺序。

使用的方法取决于对特定文档类型的 EDI 段的熟悉程度（根据交易伙伴的文件正确编辑 JSON 模式）和交易伙伴的灵活性（调整 EDI 报文以告知有关错误的信息）。