EDIFACT 端口
Version 24.2.9039
Version 24.2.9039
EDIFACT 端口
EDIFACT 端口可以将 XML 文档转换为 EDIFACT 文档,也可以将 EDIFACT 文档转换为 XML。
概述
当接收到 EDIFACT 文档时,EDIFACT 端口验证 EDIFACT 交换头,并将 EDIFACT 文档转换成 XML。这在分段步骤中很有用,因为 XML 是知行之桥用于处理工作流中数据的主要格式。EDIFACT 端口自动读取输入文件以确定合适的 EDIFACT schema,然后根据该 schema 解析文档。
生成 EDIFACT 文档时,EDIFACT 端口将 XML 转换为 EDIFACT 格式的文档,并应用适当的 EDIFACT 头。在工作流中完成提取和转换 XML 数据之后,这是创建 EDIFACT 文档的最后一步。
注意 通过启用测试标识符设置,可以免除交换头验证。
EDIFACT 端口还可以自动对传入的 EDIFACT 文档生成 ACK。更多信息,请参见 EDITFACT ACK 部分。
先决条件
开始之前,请确保已为需要处理的文档类型安装了正确的 Schema 。EDIFACT 端口本身支持以下 Schema 定义:4.1、D03A、D04A、D07A、D96A、D96B、D97A、D99A 和 D99B。可以在知行之桥安装的 app_data/edifact_schemas
目录中找到它们。如果需要不同的 Schema ,可以与我们联系免费获取其他 Schema 文件。
下载并解压 zip 存档后,将整个文件夹放入 app_data/edifact_schemas
目录下适当命名的子目录中。
端口配置
本节包含所有可配置的端口属性。
设置
转换配置
与端口核心操作相关的设置。
- 端口 Id 端口的静态、唯一标识符。
- 端口类型 显示端口类型及其用途的描述。
- 端口描述 一个可选字段,用于提供端口及其在流中的角色的自由格式描述。
- 转换类型 设置端口是将 EDIFACT 文档转换为 XML 还是将 XML 数据转换为 EDIFACT 文档。
交换头配置
与 EDIFACT 交换头相关的设置。 从 XML 生成 EDIFACT 文档时,这些设置用于生成文档标题。 解析 EDIFACT 文档时,这些设置用于验证传入文档。
- 语法标识符(UNB1.1) 标识在 EDIFACT 文档中使用的字符集。
- 语法版本(UNB1.2) 与 语法标识符 结合使用,确定 EDIFACT 文档中使用的语法。 根据在此处的选择,其他交换设置选项会在 高级 选项卡上出现或消失。
- 发送方 ID(UNB2.1) 在 EDIFACT 通信中标识发送方的唯一标识(当生成 EDIFACT 文档时,这应该是你的标识)。
- 发送方限定符代码(UNB2.2) 发送方标识符的限定符,提供值的上下文(例如,EAN 位置号)。
- 接收方 ID(UNB3.1) 在 EDIFACT 通信中识别接收方的唯一标识(当生成 EDIFACT 文档时,这应该是你的交易伙伴的标识)。
- 接收方限定符代码 (UNB3.2) 接收方标识符的限定符,提供值的上下文(例如,EAN 位置号)。
- 测试标识符(UNB11) 交换是处于测试环境还是生产环境。如果在接收文档时启用此设置,交换标题将不会被验证。
- 功能组 选中此选项可自动将发件人和收件人标识符添加到 高级 选项卡上的 功能组设置。
ACK
与生成和请求 ACK 相关的设置。
- 请求技术性 ACK(CONTRL) 是否应该返回(接收时)和请求(发送时)技术控制 ACK。技术性 ACK 作为交换的收据。
- 请求功能性 ACK 是否应返回(接收时)和请求(发送时)功能控制 ACK。功能性 ACK 是接收交换的接受或拒绝的表示。
自动化
自动化设置
与端口自动处理文件相关的设置。
- 发送 切换后,端口将在文件准备好时自动发送文件。
- 重发间隔 端口在重新发送收到否定 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 分隔符
指定哪些字符分隔元素、段等的设置。
- 数据元素分隔符 分隔文档中各个数据元素的字符。
- 组件元素分隔符 在文档的复合数据结构中分隔元素的字符。
- 段终止符 指示文档中某一段结束的字符。
- 释放字符 “释放”或“逃脱”下一个字符的字符,覆盖其通常的含义。这允许保留字符在文档中显示为数据,只要它们前面有释放字符。
- 重复字符 表示元素值重复的字符。
- 后缀 附加到段终止符以区分段。
交换头配置
与 EDIFACT 交换头相关的其他设置。 这些选项的显示或消失取决于“设置”选项卡上指定的 语法版本。
- 服务代码列表目录版本号 (UNB1.3) 进一步指定在 EDIFACT 文档中使用的语法。仅适用于 EDIFACT 语法版本 4。
- 字符编码(UNB1.4) 指定字符的编码方式(例如,ASCII、UTF-8)。仅适用于 EDIFACT 语法版本 4。
- 反向路由地址(UNB2.3) 发送方系统中的可选地址,响应交换应发送到该地址。仅适用于版本 4 之前的 EDIFACT 语法版本。
- 发件人内部 ID(UNB2.3) 一个附加的发送方标识符,用于促进响应交换的内部路由。仅适用于 EDIFACT 语法版本 4。
- 发件人内部子标识(UNB2.4) 进一步识别发送者,当需要次级识别时。仅适用于 EDIFACT 语法版本 4。
- 路由地址(UNB3.3) 接收方系统中的可选地址,交换应路由到该地址。仅适用于版本 4 之前的 EDIFACT 语法版本。
- 接收方内部 ID(UNB3.3) 一种附加的接收方标识符,便于接收到的交换的内部路由。仅适用于 EDIFACT 语法版本 4。
- 接收方内部子标识(UNB3.4) 当需要子级别识别时,进一步识别接收者。仅适用于 EDIFACT 语法版本 4。
- 接收方密码(UNB6.1) 获取接收方系统访问权限的参考或密码。
- 接收方密码限定符 (UNB6.2) 为接收方密码(如果适用)提供上下文的限定符。
- 应用参考号(UNB7) 标识交换中的消息所关联的应用程序组。
- 处理优先级代码 (UNB8) 请求交换处理优先级的代码。
- 通信协议(UNB10) 定义控制交换的通信协议类型。
功能组配置
与 EDIFACT 文件的功能组标题相关的设置。这些可选标识符可以帮助将类似的交换组合在一起,或者便于在组织内进行子寻址。
- 应用程序发送方 ID(UNG2.1) 标识发送文档的应用程序(例如部门、分支机构或计算机系统)。
- 应用程序接收方 ID(UNG3.1) 标识文档要用于的应用程序。
高级设置
设置不包括在以前的类别中。
- 批处理 一个交换可以包含多个事务。 如果未选中此选项,端口将为交换中的每个事务创建一个单独的输出文件。 选中后,端口会将所有事务分组到单个输出文件中。 仅当 转换类型 为 EDI 到 XML 时适用。
- 使用标准 ID 命名 选中后,当 EDIFACT 转换为 XML 时,引用 Id 将用于命名 XML 元素。 仅当 转换类型 为 EDI 到 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 转换。 选中此项以使转换后的确认也包含在“输出”选项卡中。 除了新的 EDI 文档之外,这还允许将功能确认集成到目标源中。
- 将描述生成为 将 EDIFACT 转换为 XML 时,可以提供 EDIFACT 段和元素的描述作为 EDIFACT 数据的上下文。 使用此下拉列表可以选择是否将此上下文添加为 XML 注释或 XML 属性。
- 本地文件名格式 用于为端口输出的消息分配文件名的方案。 可以在文件名中动态使用宏来包含标识符和时间戳等信息。 有关详细信息,请参阅宏。
- 嵌套循环 选中时,端口会检测 EDI 数据中嵌入了层次关系的 EDI 结构,并生成 XML,其中这些层次关系表示为父子关系。 有关详细信息,请参阅主-明细层级:转换 CPS 和 HYN 循环。
- 延迟处理 放置在输入文件夹中的文件的处理延迟的时间量(以秒为单位)。 这是一个遗留设置。 最佳实践是使用 File 端口 来管理本地文件系统,而不是此设置。
- 严格模式验证 当检测到以下情况时,端口是否应忽略、警告或失败:重复计数超过允许的数量、缺少必需的元素或段、无效的限定符和代码值、不允许的元素长度以及无效元素 价值观。 选择“禁用”会关闭 scheme 验证检查。
- 跟踪 UNB2.1 是否将 UNB2.1 值作为跟踪头添加到已处理的消息中。 运行 EDI 报告 时需要这些头。
- 跟踪 UNB3.1 是否将 UNB3.1 值作为跟踪头添加到已处理的消息中。 运行 EDI 报告 时需要这些头。
- 跟踪事务类型 是否将事务类型作为跟踪头添加到已处理的消息中。 运行 EDI 报告 时需要这些头。
- 验证标识符 检查此项以确保翻译文档中的标识符与端口配置中的标识符匹配。
- 上传 Schema 使用此选项可上传架构并将其安装在端口的架构文件夹中。如果架构已存在,系统会询问您是否要覆盖它。
- 重置状态 EDI 端口会跟踪已使用的控制编号并增加该编号以确保将来的运行不会重复数据。使用此按钮可将计数器重置为其初始状态,而无需更改任何配置的设置。
消息
- 保存至 Sent 文件夹 选中此选项可将端口处理的文件复制到端口的已发送文件夹中。
- 已发送文件夹方案 指示端口根据选定的时间间隔对已发送文件夹中的消息进行分组。 例如,Weekly 选项指示端口每周创建一个新的子文件夹,并将该周的所有消息存储在该文件夹中。 空白设置告诉端口将所有消息直接保存在“已发送”文件夹中。 对于处理许多消息的端口,使用子文件夹有助于保持消息的组织性并提高性能。
日志
- 日志级别 端口生成的日志的详细程度。 当请求支持时,请将其设置为 Debug。
- 日志子文件夹方案 指端口根据选定的时间间隔对日志文件夹中的文件进行分组。 例如,Weekly 选项表示端口每周创建一个新子文件夹并将该周的所有日志存储在该文件夹中。 空白设置告诉端口将所有日志直接保存在 Logs 文件夹中。 对于处理大量事务的端口,使用子文件夹有助于保持日志井井有条并提高性能。
- 保留消息副本 检查此项以使已处理文件的日志条目包含文件本身的副本。 如果禁用此功能,可能无法从 输入 或 输出 选项卡下载文件的副本。
特殊设置
特殊设置 适用于特定用例。
- 其他设置 允许在以分号分隔的列表中配置隐藏的端口设置,例如
setting1=value1;setting2=value2
。 正常的端口用例和功能不需要使用这些设置。
转换类型
以下各节详细介绍了将 EDIFACT 转换为 XML 的过程,以及将 XML 转换为 EDIFACT 的过程。
EDI 转换为 XML
将转换类型设置为 EDI 转换为 XML 表示端口将输入的 EDIFACT 报文解析为 XML 文件。首先,端口读取交换和功能组中的所有头部信息,并根据配置的端口设置验证它们(除非测试标识符已启用)。然后,端口解析出报文中使用的特定 EDITFACT schema,并从磁盘上的 ‘edifact_schemas’ 文件夹加载该 schema。使用该 schema,端口生成表示 EDIFACT 报文结构的 XML,并以 XML 注释或 XML 元素中属性的形式为每个值提供上下文(取决于将描述生成为)。
要使用一组测试 EDIFACT 报文来查看此过程,请选择 EDIFACT 端口的的输入页面(将转换类型设置为 EDI 转换为 XML),然后点击更多选项 > 创建测试文件。将自动生成发票、采购订单、采购订单确认和发货通知的 EDIFACT 报文放置在输入目录中。端口处理完这些测试文件后,选择输出页面以查看结果。
一旦 EDIFACT 报文被转换成 XML,数据就可以通过多种方式进行转换和操作。通常,EDIFACT 数据需要存储在数据库或其它后端应用系统中。由于知行之桥使用 XML 来表示这些后端系统中的插入,存储 EDIFACT 数据就变成了简单地将一个 XML 结构映射到另一个 XML 的问题。通常是用可视化设计器驱动的 XML Map 端口。
XML 转换为 EDI
将 转换类型 设置为 XML 转换为 EDI 将指示端口从文档的 XML 表示中生成一个 EDIFACT 文档。端口从 XML 解析的数据中构造出 EDIFACT 消息后,将根据配置的端口设置添加功能组和交换头。
要查看带有一组测试 XML 文件的此过程,请进入到 EDIFACT 端口的输入页面(将转换类型设置为 XML 转换为 EDI)并选择更多 > 建测试文件 。代表发票、采购订单、采购订单确认和发货通知的 XML 文件将自动生成并放置在输入目录中。端口处理完这些测试文件后,导航至“输出”页面,查看最终的 EDI 文档。
EDIFACT ACK
以下各节详细介绍了两种类型的 EDIFACT ACK,以及知行之桥期望、处理和生成的ACK。
技术性 ACK 与功能性 ACK
技术性 ACK,有时称为交换 ACK,是双方之间已经发生交换的一种表示,尽管不一定表示已经交换了任何单独的消息。这些作为发送者的收据,指示成功接收到 EDIFACT 消息,但是它没有指定在处理消息内容时是否存在任何问题。
功能性 ACK 是接收方已经处理了交换的指示。它可以报告接受、有问题的接受或拒绝接收的文件。这些既可以作为交换成功接收的收据,也可以作为交换被完全处理的收据。
期待 ACK、处理 ACK 和生成 ACK
期待 ACK
可以配置以 XML 到 EDI 模式运行的 EDIFACT 端口,以便消息需要技术和/或功能 ACK。 在“设置”选项卡的 ACK 部分中选中 请求技术性 ACK(CONTRL) 和 请求功能性 ACK(CONTRL) 之一或两者时,端口将保持传输的 ‘Pending ACK’ 状态 直到返回并处理了适当的 ACK。 这意味着端口状态可用于确定收件人是否已确认他们收到了交换。
下图显示了知行之桥期望从发票文档时创建 ACK 涉及的逻辑流程:
在上图中,以 XML 转换为 EDI 类型运行的 EDIFACT 端口生成要交换的文档 (1) 在文档传输到交易伙伴时将其保持为 ‘Pending ACK’ 状态。交易伙伴根据其业务逻辑处理传输,并根据配置的转换配置创建 ACK。(2) 当返回 ACK 后,将根据下一部分 (3) 中的信息进行处理。
处理 ACK
在典型流程中,EDIFACT ACK 将到达以 EDI 转换为 XML 类型的 EDIFACT 端口。此 EDIFACT 端口可以配置为自动将收到的任何 ACK 路由到最初生成 ACK 文档的 EDIFACT 端口。通过将一个 EDIFACT 端口(EDI 转换为 XML)底部边缘的灰点拖到另一个 EDIFACT 端口(EDI 转换为 XML)上,可以在工作流中直观地配置 EDIFACT 端口之间的路由 ACK。
一旦处于 XML 转换为 EDI 类型下的 EDIFACT 端口接收到路由的 ACK,会将 ACK 原始消息进行配对,并将其状态从 ‘Pending ACK’ 更新为 ‘Sent’。
生成 ACK
当 EDI 转换为 XML 类型中的 EDIFACT 端口接收到消息并生成相应的 XML 时,它可以自动为接收到的消息生成 CONTRL ACK。为此,在“设置”选项卡的 ACK 部分中选中请求技术性 ACK(CONTRL)/请求功能性 ACK(CONTRL)功能。这些 ACK 必须路由到另一个 EDIFACT 端口(XML 转换为 EDI),以完成确认。ACK 路由到的端口将应用交换头,并将 ACK 像 EDIFACT 消息一样传递到工作流中的下一个端口。要正确发送 ACK,请在 EDI 转换为 XML 类型下,将 EDIFACT 端口边缘底部的灰点拖到另一个 EDIFACT 端口(XML 转换为 EDI)上。
下图显示了收到发票文档时创建 ACK 所涉及的逻辑流程:
如上图所示,在一个交易伙伴发送了一条请求 ACK 的消息后 (1) EDI 转换到 XML 类型下的 EDIFACT 端口将自动生成一个 ACK (2)。该 ACK 是一个包含与交易相关的交易信息的 XML 文件。然后,该 XML ACK 以 XML 转换到 EDI 类型 (3) 被路由回 EDIFACT 端口,以便在将 ACK 发送回交易伙伴之前应用交换报头(和任何其它 EDI 方协议设置)。
主-明细层级:转换 CPS 和 HYN 循环
在 EDI 文档中,大多数层次关系由 EDI 段的顺序表示。有些 EDI 结构,如 CPS 循环(可在 DESADV 文档中找到)和 HYN 循环(可在 PRICAT 文档中找到),不遵循这一惯例,而是在 EDI 元素数据本身中嵌入了层次关系。这使得在将 EDI 数据转换为 XML 时,很难保持这些层次关系。
EDIFACT 端口支持通过高级设置页面中的嵌套主-明细循环设置来保留 CPS 段中的层次关系。启用后,端口将解析 CPS 段中的元素,以确定哪些段“属于”层次关系中的其它段。这些层次关系在输出的 XML 中反映为父子关系;换句话说,该设置将 EDI 内容所隐含的层次结构转换为由 XML 结构表示的层次结构。
本节将简要说明在 CPS/HYN 数据中如何对层次结构进行编码,以及在启用嵌套主-明细循环时,如何将该层次结构转换为 XML。
CPS 和 HYN 层级
所有 CPS 和 HYN 段都有两个有助于建立层级结构的值:
- 当前 CPS 段的标识值(该值存储在 CPS01,HYN01,或 CPS 或 HYN 段中的第一个元素中)
- 一个父标识值,标识了当前 CPS 段的分层父段(该值存储在 CPS02, HYN02,或 CPS 或 HYN 段的第二个元素中)
例如,假设一个 CPS 段的标识值是 ‘2’。如果下一个 CPS 段应该“属于”层次关系中的前一个段,那么下一个 CPS 段的父标识也应该是 ‘2’。
如果 CPS 段的父代标识为 “0”,这意味着该段没有父代(即它位于层次结构的顶层)。
将 CPS 和 HYN 层级转换为 XML
当嵌套主-明细循环被启用时, EDI 端口自动处理 CPS/HYN 层次结构到 XML 层次结构的转换。端口解析来自 CPS/HYN 段的标识和父标识值,并确保生成的 XML 元素适当地嵌套(缩进)在表示其父元素的元素中。
换句话说,如果 segmentA 的父标识值等于 segmentB 的标识值,则生成的 XML 将具有 segmentA 作为 segmentB 的子节点。这样,在翻译 EDI 数据时,层级关系保留在 XML 结构中。
宏
在文件命名策略中使用宏可以提高组织效率和对数据的上下文理解。 通过将宏合并到文件名中,可以动态地包含相关信息,例如标识符、时间戳和消息头信息,从而为每个文件提供有价值的上下文。 这有助于确保文件名反映对组织重要的详细信息。
知行之桥 支持这些宏,它们都使用以下语法:%Macro%
。
宏 | 描述 |
---|---|
ConnectorID | 替换为端口的 ConnectorID。 |
Ext | 替换为端口当前正在处理的文件的文件扩展名。 |
Filename | 替换为端口当前正在处理的文件的文件名(包括扩展名)。 |
FilenameNoExt | 替换为端口当前正在处理的文件的文件名(不带扩展名)。 |
MessageId | 计算端口输出的消息的 MessageId。 |
RegexFilename:pattern | 将正则表达式模式应用于端口当前正在处理的文件的文件名。 |
Header:headername | 替换为端口正在处理的当前消息的目标消息头 (headername ) 的值。 |
LongDate | 以常规格式计算系统的当前日期时间(例如,2024 年 1 月 24 日星期三)。 |
ShortDate | 以 yyyy-MM-dd 格式计算系统的当前日期时间(例如 2024-01-24)。 |
DateFormat:format | 以指定格式(format )计算系统的当前日期时间。 有关可用的日期时间格式,请参阅示例日期格式 |
Vault:vaultitem | 计算指定保管库项目的值。 |
示例
某些宏(例如 %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%
EDIFACT 操作
除了知行之桥提供的 运算器 之外,端口还可以提供将功能扩展到 ArcScript 的运算器。
这些端口运算器的调用方式与任何其他 ArcScript 运算器一样,但有两个细节除外:
- 必须通过
connector.rsc
接口调用它们。 - 它们必须包含身份验证令牌。
例如,使用这两个规则调用端口运算器可能如下所示:
<arc:set attr="in.myInput" value="myvalue" />
<arc:call op="connector.rsc/opName" authtoken="admin:1j9P8v8b9K0x6g5R5t7k" in="in" out="out">
<!-- 处理此处运算器的输出 -->
</arc:call>
下面列出了 EDIFACT 端口特定功能的具体操作。
edifactScan
从 EDIFACT 文档的标题中扫描标题值。
必须的参数
- file:EDIFACT 文件的路径。
可选的参数
- format:文件格式。默认是 EDIFACT。
输出属性
- InterchangeSenderIdQualifier:发送方标识限定符(UNB2.2)。
- InterchangeSenderId:发送方唯一标识(UNB2.1)。
- InterchangeReceiverIdQualifier:接收方标识限定符(UNB3.2)。
- InterchangeReceiverId:接收方唯一标识(UNB3.1)。
- DocumentType:文件类型或交易集识别码(UNH2.1)。
常见错误
下面列出了常见错误、原因以及建议的解决方案。请联系 support@kasoftware.cn 了解更多信息。
错误:
“Schema file not found ([schema major version] [schema document type])”
原因
当知行之桥解析一个 EDIFACT 文件时,它首先扫描文件的 EDI 版本和文档类型,以确定在解析过程中使用哪个 schema。该应用程序包括一组 JSON 格式的 EDIFACT schema。它们存储在应用程序数据目录的 ‘schemas’ 文件夹中(在 ‘data’ 路径旁)。
此错误表示应用程序找不到与文件报告的主要版本和文档类型匹配的 schema 文件。
如果错误消息中缺少 [schema major version] 值或 [schema document type] 值,则表明 EDI 文档不包含主要版本或文档类型。
否则,这表示适当的文档 schema 没有包含在自动包含在知行之桥中的 schema 定义集中。
解决
如果 EDI 文件不包含方案主要版本或文档类型,请联系交易伙伴(或 EDI 文档的其它来源),并通知他们这些值必须包含在消息标题中。
找到合适的 schema 版本,下载并将其放在以下路径中:
[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 版本和文档类型,以确定在解析过程中使用哪个 schema。该应用程序包括一组 JSON 格式的 EDIFACT schema,存储在根安装目录的 www\app_data
文件夹中。
此错误表示解析器在文件中遇到了与相关文档 schema 中定义的段顺序不匹配的 EDI 段。这可能表明几个不同的问题:
- EDI 文件是由交易伙伴错误生成的
- EDI 文件是使用与文件中所示不同的 schema 版本生成的
- EDI 文件是使用自定义 schema 生成的
解决
如果 EDI 文件是使用自定义 schema 生成的,只需将该自定义 schema 文件(JSON 格式)放在知行之桥读取 EDI schema 文件夹中。端口通过按顺序检查以下位置来搜索模式:
- 在磁盘上的 schema 文件夹内(例如
<ConnectorDirectory>/Resources/Schemas/
) - 如果一个 schema 被多个端口使用,建议使用如下文件夹结构:
<ApplicationDirectory>/schemas/<type>_schemas/<major version>
。 在此示例中,<type>
应为x12
。
如果 EDI 文件不是使用自定义 schema 生成的,则有两种方法可以解决交易伙伴生成的 EDI 文件和用于解析该文件的 EDI schema 之间的差异。
- 手动编辑适当的 EDI schema 文件(在上面的文件路径中找到),以调整段顺序,使其与交易伙伴的 EDI 文件相匹配。错误消息指出了文件中段偏离 schema 定义的那一行。通过 JSON 对段的顺序定义进行跟踪,直到发现差异,然后在 JSON 中对段进行重新排序,以匹配交易伙伴提供的文件。
- 关于 EDI 文件,请联系交易伙伴。确认文件是根据文件报告的主要版本生成的,并解释文件中的段顺序未被识别。
使用方法取决于对特定文档类型的 EDI 段的熟悉程度(根据交易伙伴的文件正确编辑 JSON schema)和交易伙伴的灵活性(根据错误通知调整 EDI 文件)。