We came across an issue where you are using Microsoft Dynamics AX 2009 Asynchronous BizTalk Adapter to receive response messages from AX 2009. After just having sent an AIF UPDATE or DELETE Action message to AX, the BizTalk Server fails to consume the response message that is generated by AX. You get the following error logged in the Application Event log on the BizTalk Server:
Source: BizTalk Server 2006
Event ID: 5740
Task Category: BizTalk Server 2006
The adapter “Microsoft Dynamics AX 2009” raised an error message. Details “The message does not contain a body part.”.
This error is generated because the Response message generated after a successful UPDATE and DELETE AIF actions does not contain a message part. Here is a sample response message:
<MessageParts xmlns=”http://schemas.microsoft.com/dynamics/2008/01/documents/Message” />
The AX adapter will strip out the message envelope when the pass through property is set to false within the adapter, and xml receive pipeline will try to parse the empty message body. BizTalk cannot deal with empty messages and hence raises a warning.
Furthermore, because of the above error, the response message never gets consumed from the AIF Gateway Queue, keeping a permanent lock on the resource channel. Any other messages that are queued in the AIF Gateway Queue will failed to be consumed and you get the following errors logged on the BizTalk server:
“An X++ exception has occurred. Unable to lock resource channel ‘<ax channel name>’.”. The source of the message is Microsoft Dynamics AX Business Connector.
There is a kernel hotfix available to resolve this issue, which updates the AX BizTalk Adapter and Schema assemblies.
If you are running Microsoft Dynamics AX 2009 RTM (Build v5.0.593.x), the fix is included in AX 2009 RTM Hotfix Rollup 4 Kernel
If you are running Microsoft Dynamics AX 2009 Service Pack 1 (Build v5.0.1000.52 or v5.0.1500.x), the fix is included in AX 2009 SP1 Hotfix Rollup 6 Kernel
NOTE: To check the version of the AX server version in use, find AX32SERV.EXE on your AOS servers, and chek the file properties.
Instead of installing the hotfix you can workaround the issue as detailed in this blog post