在知行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

在知行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验证以实施更具体的验证规则。

了解更多EDI,请您电话 150-0298-3180 / 177-8250-8152 或邮件 edi@kasoftware.cn 联系我们,获取 30 天全功能 免费试用 版本EDI软件。

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

标签: ,
文章分类 edi