具有单独TimeOutException处理的BizTalk并行护送无法生成错误消息“0”；致命错误X1001：未知系统异常；

考虑BizTalk 2016中并行护航模式的以下基本结构。这是一个具有2个活动接收形状的并行操作。与由两个活动接收初始化的单个相关集组合

现在，当我希望有单独的异常处理时，出现了我的问题，一个用于左接收，一个用于右接收。因此，我在左接收（scope_1）周围放置了一个作用域，并有一个超时。我将该作用域包装在另一个作用域（scope_3）中，以捕获超时异常

现在由于某些原因，这是不允许的，我在构建时返回“致命错误X1001:未知系统异常”

但是，如果我将作用域_3包裹在两个活动接收周围，则它将成功构建：

在这种情况下，BizTalk不允许单独的超时异常处理有什么显著区别

顺便说一下：

无论我试图捕获哪种类型的异常，或者我的所有作用域是否都是长时间运行的事务，错误的发生都是一样的

如果我为每个接收设置一个单独的相关集，则不会发生错误，但这当然不是我想要的，因为它不会使它成为并行护航

将作用域设置为“已同步”不会影响行为

---

首先，我能够复制您的问题

尽管visual studio报告这是一个

未知系统异常

，但对我来说，它看起来是基于范围

（范围3）

内的接收形状检测到的

无法访问的代码，该范围试图初始化您的关联。因此，如果主作用域
（作用域1）
存在一些异常，则有可能无法像左作用域
（作用域2）
那样初始化相关性

我能想到的唯一方法是使用不同的相关集，您可以设置发送端口以遵循这些相关集


在不使用相关集的情况下，在构建期间不会出现错误。对我来说，这被认为是一个MS错误，VS应该能够指出检测到的
无法到达的代码，而不是
致命错误：
重要的区别是，业务流程将在收到第一条消息时启动，这可能不是范围1。因此，在这种情况下，计时器不会启动。如果是scope_1，那么它不会像您收到的那样超时，但它不会为scope_2超时

在这两种情况下，计时器都在这两种情况下设置超时

您可以做的是按照第二个示例设置超时范围，并设置一个标志来指示接收到的超时范围，然后在异常块中使用该标志

其他选项是初始化关联集的第一个接收形状，然后在它之后的第二个接收形状具有以下关联并具有超时。
此论坛帖子有帮助吗？它描述了一个使用顺序护航的解决方案，所以不是真的。谢谢你的回答。关于你的第一部分，我真的不明白。在这两种场景中，scope_1和scope_2都设置了一个单独的超时，区别在于scope_3，它只捕获异常。所以它仍然可以为其中的任何一个超时，这与您描述的不同。至于设置标志，这在某种程度上是不可能的，因为它会抱怨没有初始化。我已经尝试了很多方法，我想让你想出一个有效的旗帜方案。至于你的最后建议，你描述的是一个连续的车队，在我的例子中，这是一个幸运的事情，我可以处理，所以我去了，但这仍然是一个解决办法。重点是，激活接收形状怎么会有超时？不同的相关集意味着它不再是并行护航。但是谢谢你的建议。您对无法访问的代码的描述听起来很可能。@r3verse，是的，我同意，因此并行护航需要相同的相关集