在知行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的摘要,表示脚本验证规则所需的逻辑种类:

<!-- set input parameters of xmlDOMSearch -->

<arc:set attr="input.uri" value="[FilePath]" />

<arc:set attr="input.xpath" value="/Interchange/FunctionalGroup/TransactionSet/TX-00501-837">

 

<!-- loop over the input file at the given xpath -->

<arc:call op="xmlDOMSearch" in="input">

<!-- retrieve specific values from the XML; elementA and elementB -->

<arc:set attr="elementA" value="[xpath('HLLoop1/NM1Loop2/NM1/NM101')]" />

<arc:set attr="elementB" value="[xpath('HLLoop1/NM1Loop2/NM1/NM103')]" />

 

<!-- check elementA against a list of possible values with a 'select' statement -->

<arc:select value="[elementA]">

 

<!-- for each possible elementA value, see if elementB has a valid value -->

<arc:case value="IL">

<arc:if exp="[elementB | notequals(40)] && [elementB | notequals(41)] && [elementB | notequals(42)]">

<!-- invalid value detected, throw an error -->

<arc:throw code=1 desc="ElementB had an invalid value of [elementB]." />

</arc:if>

</arc:case>

<arc:case value="PR">

<arc:if exp="[elementB | notequals(43)] && [elementB | notequals(44)]">

<!-- invalid value detected, throw an error -->

<arc:throw code=1 desc="ElementB had an invalid value of [elementB]." />

</arc:if>

</arc:case>

</arc:select>

</arc:call>

 

  

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技术交流,欢迎私信或评论!

 

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

posted @ 2021-01-14 13:37  EDI电子数据交换  阅读(144)  评论(0编辑  收藏  举报