嗯，当我遇到这种情况时，我不得不说这很有趣：
我正在收集HIPPA 837文件，我想在收到837文件后创建999个ACK文件。如果我设置贸易伙伴协议，BizTalk将生成999消息。它到目前为止工作正常。
今天，我收到了一个带有一些结构错误的837文件：元素中有一些前导空格字符。然后创建了999，但是当我的发送端口订阅此999消息时尝试将其保存为文件时，我得到了验证错误，抱怨999消息本身无效，因为其元素具有前导空格字符.....
错误：3（字段级错误）
SegmentID：IK4
在TS中的位置：18
数据元素ID：IK44
细分中的位置：4
数据值：
6：找到前导或尾随空间
它看起来就像一个问题22：您的999文件假设报告入站文件的结构错误，它将包含错误的元素值作为报告的一部分（在我的情况下，它在IK4段中） ），但错误的元素值本身也使999文件无效。
我只是想知道是否有人遇到过同样的情况？你对这个问题的建议是什么？
答案 0 :(得分：2)
我还没有看到这个，真的，我有点惊讶它以前没有出现过，如果这是一个真正的捕获22：）
尝试此操作，在协议的You-＆gt; Them标签中，将验证部分中的默认行设置为具有前导和尾随空格=允许。
由于999不在“交易类型”列表中，您可能必须将所有其他tx明确设置为“不允许”。
答案 1 :(得分：1)
我会尝试@ Johns-305的建议，但我知道我在协议之前使用允许前导/尾随空格存在问题（某些字段似乎对我来说有点夸大其词即便如此。
我会尝试捕获999消息，然后才能进入EDI发送并在相关节点上使用normalize-space()（在XSLT中）或.Trim()（在C＃中）。您可以通过创建一个过滤999 BTS.MessageType的发送端口来完成此操作。
这可能无法完全满足您的贸易伙伴的期望，因为该段可能在没有空格的情况下有效（导致混淆为什么可能存在其他有效的段被拒绝）。
你也可能会对微软采取这种做法，尽管使用XML（其中领先的空白可能被视为无关紧要）来表示EDI（领先的空白是坏消息）可能是一种限制。