在知行EDI系统中实施SNIP验证

此前的文章介绍了SNIP验证EDI文件，本文主要介绍如何在知行EDI系统中实施SNIP验证。知行EDI系统的EDI处理功能包括对较低SNIP验证级别的内置支持。更高的SNIP验证级别可能需要配置验证端口作为数据处理的附加步骤，而最高级别的SNIP验证可能需要编写脚本来实现验证逻辑。

在文章SNIP验证EDI文件 中介绍了SNIP的7种类型，本节将描述如何在知行EDI系统中实现每个级别的SNIP验证。但是，在描述所有这些级别之前，对于知行EDI系统的新手来说，描述应用程序如何处理EDI处理可能会有很大帮助。

知行EDI系统的EDI端口

知行EDI系统包含许多EDI端口，这些端口可将各种EDI格式转换为XML或从XML生成EDI文档。将EDI数据转换为XML的过程，遵循知行EDI系统在集成流程中使用XML作为中间数据格式的一般方法。使用XML作为通用数据格式，不仅可以简化通过XML Map Connector进行的数据转换，还可以确保知行EDI系统可以集成来自不同数据源和格式的数据。因此，数据通常在流程的早期转换为XML，在流程的中间传输，然后在流程结束时从XML转换为某种目标格式。

当EDI端口将EDI数据转换为XML时，知行EDI系统还将根据适当的EDI文档架构对EDI结构进行验证。默认情况下，此验证仅包括确保EDI可以正确转换为XML所必需的内容：段顺序，段的打开和关闭等。EDI端口还在“高级设置”选项卡中有一个名为SNIP Validation的设置，启用后会加强对EDI数据的验证要求。知行EDI系统中，启用SNIP Validation的页面如下图所示：

在知行EDI系统中的FLOWS页面下，任选一个EDI端口。以EDIFACT端口为例，点击名为EDIFACT1的端口，在Advanced页面下勾选Enable SNIP validation即可。

如以下小节所述，要确保SNIP验证的前三个级别，只需在EDI端口中启用SNIP Validation设置即可。

要实现更高级别的SNIP验证，可能需要额外的验证端口或自定义Script。这些端口将在EDI端口之后添加到Flow中，因此要验证的数据将是XML（EDI端口已经将EDI转换为XML）。下面提供了此附加验证的详细信息。

实施SNIP类型1

知行EDI系统通过其内置的EDI处理自动实现SNIP类型1。无需启用任何设置，也无需采取任何其他步骤。

实施SNIP类型2和3

为了确保SNIP类型2或3验证，应在负责将EDI转换为XML的EDI端口的“高级”选项卡中启用SNIP验证设置。无需其他步骤。

实施SNIP类型4

SNIP类型4验证要求将“验证端口”添加到处理输入EDI数据的流中。为实现类型4逻辑,可以验证端口配置：元素A 包含值“X”，然后,元素B必须是一组值之一，例如“Y”或“Z”。请注意，验证端口需要XML输入，因此应将输入EDI文件转换为XML的EDI端口之后添加。

在验证端口中正确实现此逻辑需要对所涉及的EDI数据有一定的了解。用户必须熟悉具有这种“if A，then B”关系的特定EDI元素，并能够在转换的XML中追踪到这些元素的xpath。

一旦知道了EDI元素之间的xpath和关系，就可以使用在知行EDI系统工作流中实现这些要求的规则来配置验证端口。这些规则检查两个xpath的值是否都在期望的集合内，并使用运算符“不等于”，“正则表达式匹配”和布尔值“OR”来完成“if-then”逻辑。下面提供了实现此逻辑的示例。

以一个简单的Type 4要求为例：如果elementA的值为“IL”，则elementB必须为“40”，“41”或“42”。

在验证端口中实现此步骤时，需要考虑两个步骤：

• 找到保留相关值的xpath
• 使用“等于”，“正则表达式匹配”和“或”实现if-then关系

为了这个示例，想象一个简单的xpath到我们的两个相关元素：

• /Items/path/elementA
• /Items/path/elementB

这些将在“验证端口”规则的“xpath”字段中使用。

接下来，考虑这些元素之间的逻辑关系：如果elementA具有特定值（“IL”），则elementB必须具有特定值（范围为40-42的数字）。表达这种关系的另一种方法是下面的：要么elementA是不特定的值（“IL”），或elementB 必须具有特定值（40-42）。关系的这种表述可以在验证端口中通过“OR”连接的两个规则来表示：

elementA notequals ‘IL’ OR elementB regex matches (40|41|42)

可以为需要具有“类型4”验证关系的每对元素实施这种验证规则方法。

实施SNIP类型5-7

更高级别的SNIP验证要求编写自定义Script来实现要求。本节将概述开始为每个验证级别编写脚本所必需的概念。

与验证相关的通用脚本概念

将EDI文件转换为XML后，最好应用Script。它包括xmlDOMSearch之类的操作，用于在指定的xpath上循环XML数据。因此，建议的工作流设计是将脚本端口直接放置在EDI端口之后，以负责将EDI文档转换为XML，并使用适当的验证脚本配置该脚本端口。

在xmlDOMSearch中，xpath格式化程序可以检索指定xpath处的值（相对于xmlDOMSearch调用中提供的xpath ）。本小节的底部提供了使用此格式化程序的示例。

arc:set关键字用于在一个属性（即变量）中存储一个值。arc:if关键字可以用来实现条件逻辑。arc:select关键字可以用来检查一个值是否在指定的情况集内。

当验证脚本遇到验证失败的EDI数据时，它需要引发错误。Script中的错误使用arc:throw关键字引发。

以下是示例Script的摘要，表示脚本验证规则所需的逻辑种类：

SNIP类型5

SNIP类型5需要读取外部资源以检查可能的值范围。用户负责获取这些外部资源的过程。

一旦获得，就可以使用一系列Script功能从这些资源中读取值，具体取决于资源的特定类型：

可以使用dbQuery操作查询数据库 文本文件可以通过fileRead操作读取 可以使用csvListRecords操作读取CSV文件

读取到来自外部授权的值后，实现这些限制的过程将遵循与上一小节中提供的代码段相似的语法。

SNIP类型6

SNIP类型6需要根据EDI文件中列出的服务来验证特定的值关系。用于此验证的脚本方法遵循与其他数据验证脚本相同的原则，另外还有一个步骤，即首先在验证每个单独的数据元素时检索要使用的医疗服务价值。

这些脚本应遵循上述相同的“arc:select”和“arc:if”方法，尽管实际的逻辑中可能包含更多级别和元素。

SNIP类型7

SNIP类型7需要来自外部EDI交易伙伴的直接输入。因此，实施这些规则的细节取决于合作伙伴，但是应使用相同的条件逻辑工具（“arc:select”，“arc:if”）来实施这些检查。

知行EDI系统包括对SNIP验证的基线级别的简单一键式支持，并提供了端口和Script验证以实施更具体的验证规则。

注：文案部分内容来源于网络，版权归原创作者所有，如有侵犯到您的权益，请您联系我们进行删除，给您带来困扰，我们深感抱歉。