BizTalk 2009“数据元素中的无效字符”错误
在我们的一些 BizTalk 2009 开发环境中，当尝试处理 HIPPA X12 文件（4010 270 文件类型）时，架构中定义为类型 X12_AN 的任何元素都会抛出“数据元素中的无效字符”错误；例如，NM103__InformationReceiverLastOrOrganizationName。它所抱怨的无效字符是字母“U”。它只是大写字母“U”，而不是小写字母“u”。
此错误仅出现在运行 Windows Server 2003 R2 Enterprise X64 Edition 的 Citrix VDI 中的开发环境中。 VDI 上安装的 BizTalk Server 2009 实例已使用最新的修补程序进行更新。
到目前为止，我尝试了所有我能想到的方法，从转换输入文件编码到手动重新输入整个文件。我重新编译并部署了模式和映射。我什至在参与方级别启用和禁用 EDI 验证。似乎什么都不起作用。
以前有人见过这种类型的错误吗？有没有办法修改或覆盖 BizTalk 中用于元素验证的字符集？
您能提供的任何信息将不胜感激！
In some of our BizTalk 2009 development environments, when attempting to process a HIPPA X12 file, 4010 270 file type, any element defined in the schema to be type X12_AN is throwing an "Invalid character in data element" error; e.g. NM103__InformationReceiverLastOrOrganizationName. The invalid character that it is complaining about is the letter "U". It's only the capital letter "U" and not a lowercase "u".
This error only presents in our development environments that exist in Citrix VDIs running Windows Server 2003 R2 Enterprise X64 Edition. The instance of BizTalk Server 2009 installed on the VDIs has been updated with the most recent hotfix.
So far, I tried everything I can think of from converting the input file encoding, to retyping the entire file manually. I recompiled and deployed both the schemas and maps. I even enabling and disabling EDI validation at the party level. Nothing seems to be working.
Has anyone seen this type of error before? Is there any way to modify or override the character set that is used for element validation in BizTalk?
Any information that you can offer would be greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看来您这里有几个不同的问题。我无法谈论您的开发环境和生产环境之间的差异（由您的帖子暗示）。
至于其余的：
是的，您可以修改 X12 验证。我面前没有它，但我相信你可以完全关闭它（如果这是你想要的）。否则，您必须（本质上）创建一个允许该角色的自定义 270 架构（您甚至可以这样做以使原本无效的元素变得有效），然后为符合该验证规则的任何合作伙伴使用该自定义架构。
我一直所做的就是修改传入文件：通过正则表达式发送它，该正则表达式将该字段中的字符更改为小写“u”。只要您保留原始（未经编辑）消息的副本，并且不更改任何实际数据值，就不会遇到任何 HIPAA 法规。
我还鼓励您用众所周知的细齿梳子仔细检查有问题的文件。通常（并非总是）有其他原因实际上导致了错误，但它仅在情况 X 中明显表现出来（在您的情况下，NM103 中的大写 U）。
It looks like you have a couple of different issues here. I can't speak to the differences (implied by your post) between your Dev and Production environments.
As to the rest:
Yes, you can modify the X12 Validation. I don't have it in front of me but I believe you can just turn it off completely (if that's what you want). Otherwise, you have to (essentially) create a custom 270 schema that allows the character (you can even do this to make elements that would otherwise be invalid valid), and then use that custom schema for any partner that hits that validation rule.
What I've always done is to modify the incoming file: send it through a regex that will change that character in that field to a lowercase 'u'. As long as you're keeping a copy of the original (unedited) message, and you're not changing any actual data values, you won't run into any HIPAA regs.
I would also encourage you to go through the offending files with the proverbial fine-toothed comb. Usually (not always) there is something else that is actually causing the error, but it only manifests noticeably in circumstance X (in your case, a capital U in your NM103).
几周后重新审视这个问题，我发现这个问题的修复比预期简单得多。
我们从事医疗保健行业，目前支持 HIPAA 4010 应用程序，同时积极升级我们的开发环境中的这些应用程序以满足 HIPAA 5010 要求。因此，当在仅用于 4010 开发的一方的配置中检查了一方属性“使用 ISA11 作为重复分隔符”时，BizTalk 中导致了此问题。由于 4010 的默认 ISA11 值是“U”，因此 BizTalk 在发现该字符的所有地方都会报告该字符无效。
我希望这可以帮其他人省去很多麻烦。时不时地提醒您应该始终首先检查明显、简单的解决方案，即使您知道它们不是问题，这很有趣！
Revisiting this issue after a couple of weeks I found the fix for this issue to be much simpler than expected.
We work in the the healthcare industry and are currently supporting HIPAA 4010 applications while actively upgrading those applications in our development environment to meet the HIPAA 5010 requirements. As such, this issue was caused in BizTalk when the party property "Use ISA11 as repetition separator" was CHECKED within the configuration of a party used only for 4010 development. Since the default ISA11 value for 4010 is "U", BizTalk reported that character as invalid everywhere it was found.
I hope this saves someone else a lot of headaches. It's fun to be reminded every now and then that you should always check the obvious, simple solutions first, even if you KNOW they're not the issue!