BizTalk生成了错误的999文件? [英] BizTalk generated wrong 999 file?
问题描述
我正在研究一个BizTalk入站流程，以从不同的贸易伙伴处入站837-p文件.将文件入库处理后，我还将BizTalk自动生成的999文件转发给贸易伙伴，以作为确认.
I am working on a BizTalk inbound process to inbound 837-p files from different trading partners. After the file is processed inbound, I am also forwarding the BizTalk auto-generated 999 file to trading partners as an acknowledgement.
对于特殊的贸易伙伴，BizTalk入站837文件并生成999文件，声称该文件中的所有记录在其AK9段中均被接受".
For a special trading partner, BizTalk inbound the 837 file and generated a 999 file claim all records in this file are "Accepted" in its AK9 segment.
但是文件中这些记录的继续过程表明它实际上有一些记录失败.
But the continue process of these records from the file shows it have some records actually failed.
我将一条失败的消息另存为XML，并使用BizTalk附带的837-p模式对其进行了验证，实际上它在验证中失败，并出现以下错误:
I saved one of the failed message as XML and validated it with the 837-p schema shipped with BizTalk, it actually failed in validation with following error:
错误BEC2004:元素"PRV_BillingProviderSpecialtyInformation" 在名称空间' http://schemas.microsoft.com/BizTalk/EDI/X12/2006 有 内容不完整.预期的可能元素列表: "PRV03_ProviderTaxonomyCode".
error BEC2004: The element 'PRV_BillingProviderSpecialtyInformation' in namespace 'http://schemas.microsoft.com/BizTalk/EDI/X12/2006' has incomplete content. List of possible elements expected: 'PRV03_ProviderTaxonomyCode'.
问题是，如果记录实际上在模式验证中失败，为什么生成的所有记录都为接受"的999?
The question is, if the record actually failed in schema validation, why was the 999 generated with all records as "Accept"?
其他一些信息:
-
该贸易伙伴的协议中已启用EDI验证.
The EDI Validation is turned on in that trading partner's agreement.
我已经双重验证了协议中的所有设置都与 传入文件.
I've double verified that all the setting in agreement are matching the incoming file.
此验证实际上是HIPPA 2级验证.但是根据BizTalk文档，它应该支持2级验证.
This validation is actually a HIPPA level 2 validation. But per BizTalk document, it should support level 2 validation.
BizTalk版本是带有CU3更新的BizTalk 2013.
The BizTalk version is BizTalk 2013 with CU3 update.
推荐答案
最后找出答案. BizTalk抱怨缺少的元素实际上是持有一个空格字符.因此，它通过了入站验证，但是稍后在业务流程中对空格字符进行了修剪.然后引发错误.
Finally figure it out. The missing element BizTalk complains is actually holds a single space character. So it passes the inbound validation, but the space char is trimmed later on in an orchestration. Then the error is raised.
这篇关于BizTalk生成了错误的999文件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
