This is the fourth in a series of eight articles reviewing my experiences with the Dynamics AX 4.0 Adapter for BizTalk Server 2006. In the second article, I reviewed an issue with IPC Ports. While the IPC Port issue referred to in the second article prevents the Dynamics AX adapter from working at all, the issue described in this article seems to suggests that the adapter tends to destabilizes over time. The failure that is encountered reads “IPC Port cannot be opened”. My observations suggests that this failure is related to how exceptions are managed by the Dynamics AX adapter.
If an exception occurs when importing a message in Dynamics AX, the exception is converted into a Soap exception, which can be caught as a DeliveryFailureException within an orchestration. The actual failure is buried in the inner exception.
When a failure occurs in Dynamics AX in my current implementation, the orchestration issues a compensating transaction back to the source system. At a later time, the transaction is attempted again. Ideally, the issue that caused the exception is resolved prior to the transaction being resubmitted to Dynamics AX. At times, especially In a test system, the issue may not resolved for days.
What I have observed is that over time, the Dynamics AX adapter appears to destabilize. A series of exceptions occur, usually in a predictable order. Eventually, the Dynamics AX adapter stops processing either inbound or outbound messages.
The error sequence typically starts with a random “Requested Service Not Found” failure. This failure may occur several times. Eventually, the dreaded “IPC Port cannot be opened” failure occurs. Once this happens, the Dynamics AX adapter running in the BizTalk Server host instance is toast. All subsequent inbound and outbound message will fail with the “IPC Port cannot be opened” exception. The only resolution is to restart the BizTalk Server Host Instance that the adapter is running in.
One thing to note is that on occasion the IPC port failure may occur on the return message back to BizTalk Server. In this scenario, the transaction may have succeeded in Dynamics AX, but BizTalk Server will view the transaction as a failure. In my implementation, the orchestration may encounter the “Duplicate Message” error when the offending message is resubmitted to Dynamics AX.
I am continuing to track this issue. As I gather more definitive information, I will update my blog.