此前的文章介紹了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的摘要，表示腳本驗證規則所需的邏輯種類：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
<
!
--
Code
goes
here
--
>
<
!
--
set
input
parameters
of
xmlDOMSearch
--
>
&
lt
;
arc
:
set
attr
=
"input.uri"
value
=
"[FilePath]"
/
>
&
lt
;
arc
:
set
attr
=
"input.xpath"
value
=
"/Interchange/FunctionalGroup/TransactionSet/TX-00501-837"
>
<
!
--
loop
over
the
input
file
at
the
given
xpath
--
>
&
lt
;
arc
:
call
op
=
"xmlDOMSearch"
in
=
"input"
>
<
!
--
retrieve
specific
values
from
the
XML
;
elementA
and
elementB
--
>
&
lt
;
arc
:
set
attr
=
"elementA"
value
=
"[xpath('HLLoop1/NM1Loop2/NM1/NM101')]"
/
>
&
lt
;
arc
:
set
attr
=
"elementB"
value
=
"[xpath('HLLoop1/NM1Loop2/NM1/NM103')]"
/
>
<
!
--
check
elementA
against
a
list
of
possible
values
with
a
'select'
statement
--
>
&
lt
;
arc
:
select
value
=
"[elementA]"
>
<
!
--
for
each
possible
elementA
value
,
see
if
elementB
has
a
valid
value
--
>
&
lt
;
arc
:
case
value
=
"IL"
>
&
lt
;
arc
:
if
exp
=
"[elementB | notequals(40)] && [elementB | notequals(41)] && [elementB | notequals(42)]"
>
<
!
--
invalid
value
detected
,
throw
an
error
--
>
&
lt
;
arc
:
throw
code
=
1
desc
=
"ElementB had an invalid value of [elementB]."
/
>
&
lt
;
/
arc
:
if
>
&
lt
;
/
arc
:
case
>
&
lt
;
arc
:
case
value
=
"PR"
>
&
lt
;
arc
:
if
exp
=
"[elementB | notequals(43)] && [elementB | notequals(44)]"
>
<
!
--
invalid
value
detected
,
throw
an
error
--
>
&
lt
;
arc
:
throw
code
=
1
desc
=
"ElementB had an invalid value of [elementB]."
/
>
&
lt
;
/
arc
:
if
>
&
lt
;
/
arc
:
case
>
&
lt
;
/
arc
:
select
>
&
lt
;
/
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驗證以實施更具體的驗證規則。
注：文案部分內容來源於網絡，版權歸原創作者所有，如有侵犯到您的權益，請您聯繫我們進行刪除，給您帶來困擾，我們深感抱歉。