核心功能
- EDIFACT 与 XML 格式的双向转换：支持两种格式之间的完整互转。
- 全面的交换头验证与生成：确保报文结构的合规性。
- 支持多个 EDIFACT 版本：具有自动架构检测功能。
- 交换确认与功能性确认支持：实现消息收发的闭环确认。
概览
接收 EDIFACT 文档时，EDIFACT 端口会验证 EDIFACT 交换头并将 EDIFACT 文档转换为 XML。这作为一个暂存步骤非常有用，因为 XML 是 在流程中处理数据的主要格式。EDIFACT 端口会自动读取输入文件以确定合适的 EDIFACT 架构，然后根据该架构解析文档。 生成 EDIFACT 文档时，EDIFACT 端口会将 XML 转换为 EDIFACT 文档语法并应用相应的交换头。在流程的其他位置获取并转换 XML 数据后，这通常是创建 EDIFACT 文档的最后一步。启用 Test Indicator 设置可以避免交换头验证。
先决条件
开始之前，请确保已为需要处理的文档类型安装正确的架构。EDIFACT 端口原生支持以下架构定义：4.1、D03A、D04A、D07A、D96A、D96B、D97A、D99A 和 D99B。你可以在 安装目录的app_data/edifact_schemas 目录中找到它们。如果需要其他架构，可以联系我们免费下载额外的架构文件。
下载并解压 zip 存档后，将整个文件夹放入 app_data/edifact_schemas 目录下命名合适的子目录中。
端口配置
本节包含所有可配置的端口属性。设置
转换配置
与端口核心操作相关的设置。EDI 交易伙伴
交换头配置
与 EDIFACT 交换头相关的设置。从 XML 生成 EDIFACT 文档时，这些设置用于生成文档头。解析 EDIFACT 文档时，这些设置用于验证传入文档。ACK
与生成和请求确认相关的设置。示例文件选项卡
高级页面
EDI 分隔符
指定用于分隔元素、段等内容的字符。交换头配置
与 EDIFACT 交换头相关的其他设置。这些选项会根据“设置”选项卡上指定的 语法版本 显示或隐藏。功能组配置
与 EDIFACT 文档功能组头相关的设置。这些可选标识符可以帮助将相似的交换分组在一起，或促进组织内的子地址。高级设置
前面类别中未包含的设置。消息
日志
杂项
EDI 交易伙伴选项卡
自动化
自动化设置
与端口自动处理文件相关的设置。性能
警报
SLA
转换类型
以下部分详细介绍 EDIFACT 到 XML 以及 XML 到 EDIFACT 的转换过程。EDIFACT 转换为 XML
将 转换类型 设置为 EDI to XML 会指示端口将传入的 EDIFACT 文档解析为 XML。端口首先读取文档中交换和功能组部分的所有头信息，并根据配置的端口设置进行验证（除非勾选 Test Indicator）。然后，端口解析文档中使用的具体 EDIFACT 架构，并从磁盘上的edifact_schemas 文件夹加载架构（可以从联系我们免费下载额外的架构文件）。端口使用该架构生成表示文档 EDIFACT 结构的 XML，用文档中的值填充 XML，并根据 Generate Descriptions As 的值，以 XML 注释或 XML 元素属性的形式为每个值提供上下文。
若要使用一组测试 EDIFACT 文档查看此过程，请导航到 EDIFACT 端口的 交易 选项卡（转换类型 设置为 EDI to XML），然后选择 More > Create Test Files。系统会自动生成发票、采购订单、采购订单确认和发货通知的 EDIFACT 文档，并将其放入 交易 目录。端口处理这些测试文件后，导航到 交易 选项卡即可查看生成的 XML。
EDIFACT 文档转换为 XML 后，可以通过多种方式转换和处理这些数据。通常，EDIFACT 数据需要存储在数据库或其他后端应用系统中。由于 使用 XML 表示对这些后端系统的 inserts，因此存储 EDIFACT 数据就变成了将一个 XML 结构映射到另一个 XML 结构。这通常通过可视化设计器驱动的 XML Map 端口完成。
XML 转换为 EDIFACT
将 转换类型 设置为 XML to EDI 会指示端口从文档的 XML 表示生成 EDIFACT 文档。端口从 XML 解析出的数据构造 EDIFACT 消息后，会根据配置的端口设置添加功能组和交换头。 若要使用一组测试 XML 文件查看此过程，请导航到 EDIFACT 端口的 交易 选项卡（转换类型 设置为 XML to EDI），然后选择 More > Create Test Files。系统会自动生成表示发票、采购订单、采购订单确认和发货通知的 XML 文件，并将其放入 交易 目录。端口处理这些测试文件后，导航到 交易 选项卡即可查看生成的 EDIFACT 文档。打印视图
与 XML Map 端口结合使用
上传测试文件
EDIFACT ACK
以下部分详细介绍两种 EDIFACT 确认（ACK），以及 如何期待、处理和生成 ACK。技术性 ACK 与功能性 ACK
技术性 ACK 有时称为交换 ACK，表示双方之间发生了交换，但不一定表示已交换任何单个消息。它们作为发送方的回执，指示 EDIFACT 消息已成功接收，但不说明处理消息内容时是否存在任何问题。 功能性 ACK 表示接收方已处理交换。它们可以报告已接受、带问题接受或拒绝接收的文档。它们既作为交换已成功接收的回执，也表示该交换已被完整处理。期待 ACK、处理 ACK 和生成 ACK
期待 ACK
在 XML 到 EDI 模式下运行的 EDIFACT 端口可以配置为期望消息返回技术性 ACK 和/或功能性 ACK。当在设置选项卡的 ACK 部分勾选 Technical acknowledgment (CONTRL) 和 Functional acknowledgment (CONTRL) 中的一个或两个时，端口会在适当的 ACK 返回并处理之前，将传输保持为 Pending ACK 状态。这意味着可以使用端口状态来确定接收方是否已确认收到交换。 下图显示了 期望发票文档返回 ACK 时涉及的逻辑流程： ![EDIFACT 接收 ACK(/public/images/edifact-ack-receive.png) 在上图中，XML 到 EDI 模式下的 EDIFACT 端口生成要交换的文档 (1)，并在文档传输给交易伙伴期间将其保持为 Pending ACK 状态。交易伙伴根据其业务逻辑处理传输，并按照配置的交换参数创建确认 (2)。确认返回后，会根据下一节中的信息进行处理 (3)。处理 ACK
在典型流程中，EDIFACT ACK 会到达以 EDI 到 XML 模式运行的 EDIFACT 端口。可以将此 EDIFACT 端口配置为自动将收到的任何确认路由到最初生成被确认文档的 EDIFACT 端口。通过在 Flows 画布上将 EDI 到 XML 模式下 EDIFACT 端口底部的灰点拖到 XML 到 EDI 模式下的 EDIFACT 端口，即可直观配置 EDIFACT 端口之间的 ACK 路由。 XML 到 EDI 模式下的 EDIFACT 端口收到路由的 ACK 后，会将 ACK 与原始消息配对，并将其状态从 Pending ACK 更改为 Sent。生成 ACK
当 EDI 到 XML 模式下的 EDIFACT 端口收到消息并生成相应的 XML 时，可以自动为收到的消息生成 CONTRL 确认。为此，请在设置选项卡的 ACK 部分勾选 Technical acknowledgment (CONTRL) 和/或 Functional acknowledgment (CONTRL)。这些确认必须路由到另一个 EDIFACT 端口（XML 到 EDI 模式）以完成 ACK。ACK 被路由到的端口会应用交换头，并像任何其他 EDIFACT 消息一样将 ACK 传递到流程中的下一个端口。若要正确路由 ACK，请将 EDI 到 XML 模式下 EDIFACT 端口底部的灰点拖到 XML 到 EDI 模式下的 EDIFACT 端口。 下图显示了为收到的发票文档创建 ACK 时涉及的逻辑流程： ![EDIFACT 创建 ACK(/public/images/edifact-ack-create.png) 如上图所示，在交易伙伴发送需要确认的消息后 (1)，解析该文档的 EDI 到 XML 模式 EDIFACT 端口会自动生成 ACK (2)。此 ACK 是一个 XML 文件，包含与该交易相关的事务信息。然后，此 XML 确认会路由回 XML 到 EDI 模式的 EDIFACT 端口 (3)，以便在将 ACK 发送回交易伙伴之前应用交换头（以及任何其他 EDI 方协议设置）。主-明细层级：转换 CPS 和 HYN 循环
在 EDI 文档中，大多数层次关系由 EDI 段的顺序表示。某些 EDI 结构（如 DESADV 文档中的 CPS 循环和 PRICAT 文档中的 HYN 循环）不遵循此约定，而是将层次关系嵌入 EDI 元素数据本身。这会使将 EDI 数据转换为 XML 时保留这些层次关系变得困难。 EDIFACT 端口通过高级页面上的 嵌套循环 设置，支持在 CPS 和 HYN 段中保留层次关系。启用后，端口会解析 CPS 和 HYN 段中的元素，以确定哪些段在层次关系中“属于”其他段。这些层次关系会在输出 XML 中体现为父子关系；换句话说，此设置会将 EDI 内容隐含的层次结构转换为 XML 结构表示的层次结构。 本节说明 CPS 和 HYN 数据中如何编码层次结构，以及勾选 嵌套循环 时如何将此层次结构转换为 XML。CPS 和 HYN 层级
所有 CPS 和 HYN 段都有两个有助于建立层次结构的值：- Id 值，用于标识当前段（此值存储在 CPS01 或 HYN01，即 CPS 或 HYN 段中的第一个元素）
- 父 Id 值，用于标识当前段的层次父级（此值存储在 CPS02 或 HYN02，即 CPS 或 HYN 段中的第二个元素）
将 CPS 和 HYN 层级转换为 XML
勾选 嵌套循环 时，EDIFACT 端口会自动处理 CPS 和 HYN 层次结构到 XML 层次结构的转换。端口解析 CPS 和 HYN 段中的 Id 和父 Id 值，并确保生成的 XML 元素适当地嵌套在表示其父元素的元素中。 换句话说，如果segmentA 的父 Id 值等于 segmentB，则生成的 XML 会将 segmentA 作为 segmentB 的子级。这样，在转换 EDI 数据时，层次关系会保留在 XML 结构中。
宏
示例
EDIFACT 操作
除了 提供的操作之外，端口还可以提供将功能扩展到 Script 的操作。这些端口操作可以像任何其他 Script 操作一样调用，但必须通过connector.rsc 端点调用并包含身份验证令牌。
以下操作特定于 EDIFACT 端口的功能。
edifactScan
从 EDIFACT 文档的头中扫描头值。必需参数
- file：EDIFACT 文件的路径。
可选参数
- format：文件格式。默认值为 EDIFACT。
输出属性
- InterchangeSyntaxIdentifier：所使用语法版本的 Id（UNB1.1）。
- InterchangeSyntaxVersion：所使用语法规则的版本。值范围为 1 到 5，数字越大支持越高级的字符集（UNB1.2）。
- InterchangeSenderIdQualifier：发送方 Id 的交换限定符（UNB2.2）。
- InterchangeSenderId：交换发送方 Id（UNB2.1）。
- InterchangeReceiverIdQualifier：接收方 Id 的交换限定符（UNB3.2）。
- InterchangeReceiverId：交换接收方 Id（UNB3.1）。
- DocumentType：文档类型或交易集标识符代码（UNH2.1）。
常见错误
以下是常见错误、原因以及建议的解决方案列表。错误：Schema file not found ([schema major version] [schema document type])
原因 解析 EDIFACT 文件时，首先会扫描文件以获取 EDI 版本和文档类型，从而确定解析时使用的架构。应用程序包含大量 JSON 格式的 EDIFACT 架构。它们存储在应用程序目录中的schemas 文件夹（位于 data 文件夹旁）。
此错误表示应用程序找不到与文件报告的主版本和文档类型匹配的架构文件。
如果错误消息中缺少 [schema major version] 或 [schema document type] 值，则 EDI 文档不包含主版本或文档类型。
否则，此错误表示合适的文档架构未包含在 自动包含的架构定义集中。
解决方案
如果 EDI 文件不包含架构主版本或文档类型，请联系交易伙伴（或 EDI 文档的其他来源），并告知他们必须在消息头中包含这些值。
否则，请从我们的免费下载页面找到合适的架构版本。下载架构文件夹并将其放在以下路径：
[application_directory]\schemas\edifact_schemas\[major_version]\
错误：The segment at line [line number] with tag [segment name] is not in a valid position in the specified schema ([schema major version] [schema document type]). This may indicate that the input file contains segments that are out of order.
原因 解析 EDIFACT 文件时，首先会扫描文件以获取 EDI 版本和文档类型，从而确定解析时使用的架构。应用程序包含大量 JSON 格式的 EDIFACT 架构，存储在根安装目录的www\app_data 文件夹中。
此错误表示解析器在文件中遇到了一个 EDI 段，该段与相关文档架构中定义的段顺序不匹配。这可能表示以下几种问题：
- 交易伙伴生成的 EDI 文件不正确
- EDI 文件使用的架构版本与文件中指示的版本不同
- EDI 文件使用自定义架构生成
- 位于磁盘上的端口文件夹内（例如，
<ConnectorDirectory>/Resources/Schemas/） - 如果一个架构由多个端口使用，知行软件建议使用如下文件夹结构：
<ApplicationDirectory>/schemas/<type>_schemas/<major version>。在此示例中，<type>应为edifact。
- 手动编辑相应的 EDI 架构文件（位于上述文件路径）以调整段顺序，使其与合作伙伴的 EDI 文件匹配。错误消息会指示文件中段与架构定义发生分歧的行。沿着 JSON 中的段顺序定义追踪，直到找到分歧点，然后重新排列 JSON 中的段，使其与合作伙伴提供的文件匹配。
- 联系交易伙伴了解 EDI 文件。确认该文件是根据文件报告的主版本生成的，并说明文件中段的顺序无法识别。