EDI 组装器的工做原理数据库
BizTalk Server 执行大多数将发送到 EDI 发送管道的 EDI 编码交换处理(Microsoft.BizTalk.DefaultPipelines.EDISendPipeline)。此管道包括用于执行下列处理的 EDI 组装器管道组件:架构
序列化 EDI 交换,并将 XML 编码的消息转换成交换中的 EDI 事务集。ide
执行 EDI 架构验证、X12 编码消息的跨字段验证(若是已配置)、EDI 结构验证和扩展架构验证(若是此架构是使用具备非 EDI 数据类型的节点自定义的)。编码
将信封应用于 EDI 消息。url
处理为响应 EDI 消息而收到的技术和功能确认,若是配置了解除批处理,则会对这些确认执行解除批处理操做。spa
将信封应用于传出 EDI 消息事件
当 EDI 发送管道使用中间 XML 文件生成传出 EDI 消息时,它会根据为接收方协议创建的 EDI 属性将包含交换和组标头的信封应用于该消息。若是发送管道没法根据发送端口肯定接收协议,它将使用回退协议来应用信封。事务
若是EdiOverride.OverrideEdiHeader上下文属性设置为 True,则 EDI 发送管道将使用 EdiOverride 属性集中指定的值来构造信封。若是值还没有出如今集中,则将使用协议属性中的相关 EDI 值。若是值不存在于 EdiOverride 集或协议属性中,则将使用回退 EDI 协议中的属性。ip
若是中间 XML 文件具备保留标记或 ReuseEnvelope 上下文属性,则该消息是保留批,将不会对其应用信封应用程序逻辑。路由
X12 信封值的来源
下表显示了 EDI 发送管道在何处为 X12 信封的每一部分获取其所需的信息:
标头 |
来源 |
||
交换控制标头 (ISA) |
|
||
功能组标头 (GS) |
若是定义了协议,则 GS 数据元素的值是根据事务集标识符 (ST1)、版本和目标命名空间的组合肯定的。这些值将与协议属性(若是已定义协议)或回退协议属性(若是未定义协议)“信封”页(“事务集设置”部分下)中的网格进行比较:
若是未定义协议,则从回退协议属性中填充 GS 数据元素。 |
EDIFACT 信封值的来源
下表显示了 EDI 发送管道在何处为 EDIFACT 信封的每一部分获取其所需的信息:
标头 |
源 |
||
服务字符串建议 (UNA) |
|
||
交换控制标头 (UNB) |
|
||
功能组标头 (UNG) |
若是定义了协议,则 UNG 数据元素的值是根据消息类型 (UNH2.1)、消息发行版号 (UNH2.3)、分配的代码 (UNH2.5)、版本和目标命名空间的组合肯定的。
|
应用事务集标头和尾部段
要序列化到传出 EDI 交换中的 XML 事务集应当具备事务集标头和尾部。可是,若是没有事务集标头或尾部,EDI 组装器将处理相应消息。X12 和 EDIFACT 架构中的事务集标头和尾部段对 XML 事务集而言是可选的。若是事务没有标头或尾部,则 EDISend 或 AS2EDISend 发送管道中的 EDI 组装器将会向其添加事务集标头和尾部值。这些值将基于映射或计算。EDI 组装器将会为交换 XML(保留批)、批处理的事务集 XML 和事务集 XML 执行此操做。
若是映射形成验证错误,则 XML 事务集或交换 XML 将会被挂起,而且在事件查看器中会显示相应的错误,例如长度或数据类型无效,或者控制机构代码无效。
X12 事务集标头和尾部段
对于没有标头和尾部段的 X12 编码的事务集,EDI 组装器会将 ST 和 SE 段设置为如下值:
标头/尾部段 |
值 |
||
ST01(事务集标识代码) |
映射到传入 XML 事务集中的 RootNode 名称的最后三个字符。例如,映射到“X12_00401_855”中的“855”。对于具备 TS 标识代码 837P、837D 或 837I 的 HIPAA 声明,使用“837”。 |
||
ST02(事务集控制编号) |
EdiOverride.ST02的值(若是EdiOveride.OverrideEdiHeader为 True,)或映射到 “协议属性”对话框单向协议选项卡“本地主机设置”页(“交换设置”下)中“事务集控制编号(ST02)”的值。 不论“应用新 ID”属性的设置如何,都会应用新的或递增的控制编号。 |
||
ST03(版本标识符) |
映射到来自传入 XML 事务集的 ST03 值。例如,适用于 5010 HIPAA 820 文档的“005010 X 218”(工资扣缴)。ST03 对用于验证事务集的架构进行验证。
|
||
SE01(包含的段数) |
设置为事务集中的总段数,其中包括 ST 和 SE 段。 |
||
SE02(事务集控制编号) |
映射到事务集中 ST02 的值。 |
事务集标头中的其余数据元素(如 ST03)是可选的,于是在生成的段中未赋值。
EDIFACT 事务集标头和尾部段
对于没有标头和尾部段的 EDIFACT 编码的事务集,EDI 组装器会将 UNH 和 UNT 段设置为如下值:
标头/尾部段 |
值 |
UNH01(消息引用控制编号) |
EdiOverride.UNH1的值(若是EdiOverride.OverrideEdiHeader为 True,)或映射到 “协议属性”对话框单向协议选项卡“本地主机设置”页(“交换设置”下)中“参考编号(UNH1)”的值。不论“应用新 ID”属性的设置如何,都会应用新的或递增的控制编号。 |
UNH2.1(消息类型) |
映射到传入 XML 事务集中的 RootNode 名称的最后六个字符。例如,映射到“EFACT_D96A_INVOIC”中的“INVOIC”。 |
UNH2.2(消息版本号) |
映射到传入 XML 事务集中的 RootNode 名称的第七个字符。例如,映射到“EFACT_D96A_INVOIC”中的“D”。 |
UNH2.3(消息发行版号) |
映射到传入 XML 事务集中的 RootNode 名称的第8、第九和第十个字符。例如,映射到“EFACT_D96A_INVOIC”中的“96A”。 |
UNH2.4(控制机构代码) |
始终映射到字符串“UN”。 |
UNT01(包含的段数) |
设置为事务集中的总段数,其中包括 UNH 和 UNT 段。 |
UNT02(消息引用控制编号) |
映射到 “协议属性”对话框单向协议选项卡“本地主机设置”页(“交换设置”下)中“参考编号(UNH1)”的值。 |
UNH 事务集标头中的其余数据元素(如 UNH3 到 UNH6)是可选的,于是在生成的段中未赋值。若是这些字段中有任何字段是必需的,则必须将它们设置为传入 XML 事务集中的值。
对传出消息信封的其余处理
EDI 发送管道对传出消息的信封执行如下处理。
控制编号
EDI 发送管道会将交换控制编号、组控制编号和事务集控制(或参考)编号输入到每一个传出交换的信封段中。下表显示了这些编号:
控制编号 |
X12 字段 |
EDIFACT 字段 |
交换控制编号 |
ISA13 |
UNB5 |
组控制编号 |
GS6 |
UNG5 |
事务集控制编号 (X12) 事务集参考编号 (EDIFACT) |
ST2 |
UNH1 |
根据“协议属性”对话框单向协议选项卡“本地主机设置”页(“交换设置”下)“交换控制编号(ISA13)”属性上输入的范围值,BizTalk Server 将设置下一个发送交换的交换控制编号。它将会为每一个后续交换递增此编号,直到达到最大值。
若是使用 EdiOverride 上下文属性指定交换控制编号,则指定的值将用于此交换,而且不会影响在协议中指定的交换控制编号。
|
只有选中 EDIFACT 协议属性“信封”页中的“应用 UNG 分段”属性,EDIFACT 中组控制编号才会递增。第二个字段(参考编号)会递增;前缀和后缀字段不会递增。仅在选择了“应用新 ID”属性的状况下,事务集控制编号才会递增。 |
|
在保留批交换中,您可使用消息收集示例建立自定义交换控制编号。有关详细信息,请参阅消息收集示例(BizTalk Server 示例)。 |
若是未定义协议,则会从回退协议中的相同页获取编号。发送管道存储了上次使用的控制编号,而后为下一个交换、组和事务集输入递增编号。
|
若是任何控制编号达到指定范围的最大值,则 BizTalk Server 将会引起错误,并挂起交换。您能够在“协议属性”对话框中“本地主机设置”页为 X12 和 EDIFACT 消息手动重置控制编号,或配置 BizTalk Server 以自动重置下限值。 |
|
控制编号保存在 BizTalk MessageBox 数据库的 dbo.EdiSequenceNumbers 表中。您应根据须要经过从表中清除控制编号或存档控制编号来管理此数据库表。 |
在 EDIFACT 中,控制编号由字母数字值构成。支持如下格式:
数字(例如“1”)
前缀数字后缀(例如“WA1A”)
前缀数字(例如“AA1”)
数字后缀(例如“1AA”)
在这些格式中,数字字符能够为“0”到“9”,前缀和后缀字符能够是数字之外的任何字符。只有编号递增才能够达到最大值。
段计数
对于交换中的每一个事务集,EDI 发送管道都将验证事务集中的段计数,对于 X12,事务集中的段计数在 SE01 数据元素中指示,对于 EDIFACT,则在 UNT01 数据元素中指示。若是相应数据元素的值与实际计数不符,则发送管道将更新此计数以反映实际段数。不会由于计数错误而拒绝事务集。计数的更新将记录在事件查看器中的警告中。这不适用于对保留批的处理。
序列化 EDI 交换过程当中的其余步骤
在序列化过程当中,EDI 发送管道还执行如下步骤。
序列化转义指示器
在 EDIFACT 消息的序列化过程当中,EDI 发送管道会将任何须要的转义指示器插入到 EDI 交换中。假定路由到发送管道的中间 XML 不包含转义的数据。例如,若是路由到发送管道的 XML 数据中存在转义指示器,则发送管道将在现有转义指示器前添加另外一转义指示器以便对它进行转义。
进行 EDI 验证时,不会验证转义指示器。EDI 发送管道在计算长度限制时也不会将转义指示器归入到计算范围内。
添加尾随零以便知足隐式小数要求
若是 EDI 组装器遇到在小数点后的位数不足的数字,它会在小数点后添加尾随零以便知足隐式小数要求。例如,当数字应采用 N2 格式时,若是 EDI 组装器遇到数字“4.5”,则组装器会将此数字更改成“4.50”。
替换负载数据中的分隔符
若是出站消息中的数据还包含配置为数据、分段或复合元素分隔符的字符,则 EDI 发送管道能够替换这些字符。例如,若是消息包含“test*data” 值,而且数据元素分隔符配置为‘*’,则这将可能在接收系统上引发解析问题。
经过启用“替换负载中的分隔符”属性和指定替换字符,EDI 发送管道能够配置来替换此字符。此属性位于“协议属性”对话框单向协议选项卡“字符集和分隔符”页中。
基于触发器字段转换 HIPAA 记录
若是出站文档是 HIPAA 事务集,则 EDI 程序集将包含触发器字段的任何惟一 XML 记录转换为匹配的普通 EDI 分段(请参见HIPAA 架构触发器字段批注)。经过删除“_” 字符以后 XML 记录名称的后缀,能够完成该操做。
例如,元素 <N1_PayerIdentification_TS835W1_1000A> 和 <N1_PayeeIdentification_TS835W1_1000B> 都将变为 N1 段。