BizTalk 编排故障处理在不同机器上不同 - 为什么？答案

【问题标题】：BizTalk orchestration fault handling different on different machines - why?BizTalk 编排故障处理在不同机器上不同 - 为什么？
【发布时间】：2016-01-21 10:56:42
【问题描述】：

我有两台 BizTalk 开发机器，其中一台正在尝试与另一台保持一致。我的一项测试检查从编排收到的 SOAP 错误响应的内容 - 这是设计使然。问题在于，据我所知，两台机器的配置相同，并且安装了相同配置的相同应用程序，它们处理故障的方式不同，如业务流程中捕获的异常的堆栈跟踪所示。

预期的传入故障是从配置了 SOAP 1.1 故障操作的“稍后指定”请求-响应端口接收的。这被一个 catch 块捕获，该块简单地将异常详细信息序列化为另一个错误消息并将其返回给调用者。我可以看到两台机器上的相同 catch 块以相同的方式捕获了故障。

基线机器堆栈跟踪：

at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkAsyncResult.End()
at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance.EndOperation(IAsyncResult result)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance.Microsoft.BizTalk.Adapter.Wcf.Runtime.ITwoWayAsync.EndTwoWayMethod(IAsyncResult result)
at AsyncInvokeEndEndTwoWayMethod(Object , Object[], IAsyncResult )
at System.ServiceModel.Dispatcher.AsyncMethodInvoker.InvokeEnd(Object instance, Object[]&amp;outputs, IAsyncResult result)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeEnd(MessageRpc&amp;rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage7(MessageRpc&amp;rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

其他机器的堆栈跟踪：

at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance.EndOperation(IAsyncResult result)
at AsyncInvokeEndEndTwoWayMethod(Object , Object[], IAsyncResult )
at System.ServiceModel.Dispatcher.AsyncMethodInvoker.InvokeEnd(Object instance, Object[]&amp;outputs, IAsyncResult result)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeEnd(MessageRpc&amp;rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage7(MessageRpc&amp;rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

这是我注意到的唯一行为差异。为什么同一个编排的两个实例处理同一个故障的方式不同？

【问题讨论】：

您已验证两台计算机的补丁级别相同？ .Net 和 BizTalk CU 尤其如此。

标签： wcf soap biztalk

【解决方案1】：

这是由于在进程外隔离主机中托管编排时托管环境的位数。当IIS应用程序池设置为Enable 32-bit Applications = False时，BizTalk适配器的故障处理逻辑略有不同，或者堆栈跟踪的表达方式不同，导致测试失败。

这个其实是我自己设置的，忘记了，但是这样做的原因是一个完全不相关的应用程序在我以64位模式编译的IIS配置中添加了一个全局模块，导致应用程序池重复错误然后在它以 32 位模式运行时关闭。这个模块是UxCertAuthModule.dll，我相信它是由Windows Azure Pack 的组件之一安装的。我相信这是一个错误，删除这个全局模块修复了 32 位应用程序池和我的测试。

编辑：

我在Azure Pack forums 上将此作为一个可能的错误提出。

【讨论】：