CODEWITHSUNDEEP
wcfsoapbiztalk
Tom W
Tom W

Reputation: 5422

BizTalk orchestration fault handling different on different machines - why?

I have two BizTalk development machines, one of which I am trying to get into a consistent state with the other. One of my tests checks the content of a SOAP fault response received from an orchestration - this is by design. The problem is that between the two machines, which as far as I know are configured identically and have the same application with the same configuration installed on them, handle faults differently as indicated by the stack trace of the caught exception within the orchestration.

The incoming fault expected is received from a Specify Later, request-response port with a SOAP 1.1 Fault operation configured. This is caught by a catch block which simply serializes the exception detail into another fault message and returns it to the caller. I can see that the fault is caught in the same way by the same catch block on both machines.

Baseline machine stack trace:

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)

Other machine's stack trace:

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)

This is the only difference in behaviour that I have noticed. Why are two instances of the same orchestration handling the same fault differently?

Upvotes: 0

Views: 210

Answers (1)

Tom W
Tom W

Reputation: 5422

This is due to the bitness of the hosting environment when hosting an orchestration in the out-of-process Isolated Host. When the IIS application pool is set to Enable 32-bit Applications = False, the BizTalk adapter's fault processing logic is slightly different, or expressed differently in terms of stack trace, and this causes the test to fail.

I actually set this myself and forgot about it, but the reason for doing it was that a completely unrelated application had added a global module to my IIS configuration that was compiled in 64-bit mode, which caused the application pool to repeatedly error then shut down whenever it ran in 32-bit mode. This module was UxCertAuthModule.dll and it is installed, I believe, by one of the components of Windows Azure Pack. I believe this is a bug, and removing this global module fixes 32-bit application pools, and my test.

edit:

I have raised this as a possible bug on the Azure Pack forums.

Upvotes: 1

Related Questions