2016-01-21 42 views
0

我有两台BizTalk开发机器,其中一台我试图与另一台进行一致的状态。我的一个测试检查从编排接收到的SOAP错误响应的内容 - 这是设计。问题在于,据我所知,两台机器配置完全相同,并且安装有相同配置的应用程序具有相同的配置,因此可以按照编排中捕获的异常的堆栈跟踪的不同来处理错误。BizTalk业务流程错误处理在不同的机器上有所不同 - 为什么?

预期的输入故障是从配置了SOAP 1.1 Fault操作的稍后指定请求 - 响应端口接收到的。这被catch块捕获,该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[]&outputs, IAsyncResult result) 
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeEnd(MessageRpc&rpc) 
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage7(MessageRpc&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[]&outputs, IAsyncResult result) 
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeEnd(MessageRpc&rpc) 
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage7(MessageRpc&rpc) 
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet) 

这是行为,我注意到的唯一区别。为什么相同业务流程的两个实例处理同一个错误的方式不同?

+2

您已验证两台计算机是否具有相同的修补程序级别? .Net和BizTalk CU尤其如此。 –

回答

1

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

我实际上自己设置了这个,忘记了它,但是这样做的理由是,一个完全不相关的应用程序已经将全局模块添加到我的IIS配置中,该配置是在64位模式下编译的,这导致应用程序池反复出错,然后在32位模式下运行时关闭。这个模块是UxCertAuthModule.dll,我相信它是由Windows Azure Pack的其中一个组件安装的。我相信这是一个错误,并且删除这个全局模块修复了32位应用程序池和我的测试。

编辑:

我提出这是在Azure Pack forums一个可能的错误。

相关问题