Biztalk 生成999文件的catch 22

嗯，我不得不说，当我遇到这种情况时，这有点可笑：

我在绑定HIPPA 837文件，我想在收到837文件后创建999个ACK文件。如果我设置了贸易伙伴协议，BizTalk将生成999消息。到目前为止效果还不错

今天，我收到一个837文件，其中有一些结构错误：元素中有一些前导空格字符。然后创建了999，但当我的发送端口订阅此999消息尝试将其保存为文件时，我收到一个验证错误，投诉999消息本身无效，因为其元素具有前导空格字符

错误：3（字段级错误）
分段ID:IK4
TS中的位置：18
数据元素ID:IK44
段中的位置：4
数据值：
6:找到前导或尾随空格

对我来说，这就像第二十二条军规：假设您的999文件报告入站文件的结构错误，它将包含错误的元素值作为报告的一部分（在我的情况下，它位于IK4段），但错误的元素值本身也会使999文件无效。

---

我只是想知道是否有人遇到过同样的情况？关于这个问题，你有什么建议？

我还没有看到这个，真的，我有点惊讶它以前没有出现过，如果这是一个真正的第22条军规：）

尝试这样做，在协议的You->Theme选项卡中，将Validation部分中的默认行设置为前导空格和尾随空格=Allowed

---

由于999不在交易类型列表中，您可能必须明确地将所有其他发送设置为不允许。我会尝试@Johns-305的建议，但我知道在协议中使用允许前导/尾随空格之前我遇到过问题（即使启用了它，一些字段似乎也会因此而爆炸）

我将尝试在999消息到达EDI发送之前捕获它，并在相关节点上使用

normalize-space（）

（在XSLT中）或

.Trim（）

（在C#中）。您可以通过创建一个发送端口在999

BTS.MessageType

上进行过滤来实现这一点

但是，这可能无法完全满足您的贸易伙伴的期望，因为该段可能在没有空格的情况下是有效的（这导致了对为什么拒绝一个本来可能有效的段的混淆）

---

您也可以向Microsoft提出这个问题，尽管使用XML（前导空格可能被视为无关紧要）来表示EDI（前导空格是个坏消息）可能有局限性。

可能重复@mahematd:您错了。完全不同的问题我问的两个问题。“我敢肯定！”Mathemats，如果是你否决了我的问题并将其标记为“可能”，那么你就可以认同另一个问题（这也是我的问题）。我想看到你改正你的错误。它们是完全不同的问题。这有用吗？我在尝试使用此功能时经常遇到问题-如果某些字段中有前导空格，即使这些设置在其中，EDI运行时也会发出条形码。默认行有点敏感，很容易“混淆”它。但是，既然你提到了这一点，我想起来了一些问题，领导/培训空间并不总是有效的，所以可能在某个地方有一个bug。