Entries in AIF (2)


Microsoft Dynamics AIF Error, missing class attribute

Came across a rather annoying issue that caused a few people to scratch their heads. We were integrating with AX using BizTalk and sending in a standard SalesOrder message but it kept failing with the following error:

Error:    The class AxSalesTableInterface does not support or does not have a parmSalesLineInterface method.
Error: Data source SalesPrice not in query AxdSalesOrderInterface.

After some sole searching we remembered that within the BizTalk map we had to use some custom XSLT to deal with some aggregation.

<xsl:template name="f_GiftLineItems">
<xsl:param name="totalLines" />
<xsl:param name="index" />

<xsl:if test="1 = ($index)">
<xsl:element name="ns0:SalesLineInterface">
<xsl:element name="ns0:ItemId">GIFT1</xsl:element>

<xsl:element name="ns0:SalesPrice">
<xsl:value-of select="userCSharp:MathRound(sum(//*[local-name()='Detail']/@GiftWrapPrice),'2')"/>

<xsl:element name="ns0:QtyReserved">1</xsl:element>

<xsl:element name="ns0:SalesLineInterface">
<xsl:element name="ns0:ItemId">SHIP6</xsl:element>

<xsl:element name="ns0:SalesPrice">
<xsl:value-of select="userCSharp:MathRound(sum(//*[local-name()='Detail']/@ShippingPrice),'2')"/>

<xsl:element name="ns0:QtyReserved">1</xsl:element>


The SalesLineInterface has an attribute called class that is required and must contain the string “entity”. The BizTalk mapper will normally add the attribute for us but as we’d used the Script Functoid we have to explicitly add it.  Easy to miss and can take a while to work out what’s going on. The class attribute is present on all “table” records in the AIF message and needs to be there.


<xsl:element name="ns0:SalesLineInterface">
<xsl:attribute name="class"><xsl:text>entity</xsl:text></xsl:attribute>

Configuring BizTalk Server for Dynamics AX Integration

Have been working on a Microsoft AX integration lately. When I first arrived the BizTalk environments weren't really setup that well and it was one of the first times I had worked with AX.

The main issue was around security, specifically the BizTalk AX adapter authenticating against AX through the .NET Business Connector Proxy.

There are three areas to keep in mind.

  1. AX .NET Business Connector Proxy
  2. AX itself
  3. BizTalk

.NET Business Connector Proxy

As per the Microsoft documentation this:

  • Must be a Windows domain account

  • Must be a dedicated account (used only by Business Connector)

  • Must have a password that does not expire

  • Must not have interactive logon rights

  • Must not be a Microsoft Dynamics AX user.

This link has instructions for configuring the business connector proxy user in AX.



The BizTalk service account needs to be setup as an AX user usually with admin rights although I'm sure you can be more specific if you need to be. You must give this user access to the EndPoint that BizTalk will hit or at least the group.



For BizTalk you must also enter this account in either the send port or handler settings as the proxy user:


The Gateway user is the BizTalk service account, there are a few different ways to do this. I've seen the service account setup as the proxy user and as the AX user. It seems to work but Microsoft's documentation mentions that the proxy user should not be made an AX user so I wouldn't go down this route if you don't have too.

I would recommend setting this up in the handler settings (Adapters/Microsoft Dynamics AX 2009...) so you don't wipe out the password every time you import bindings if you don't a deployment framework. if you're dev and prod environments are in the same domain BizTalk has a nasty habit of locking accounts especially with receive adapters. You might want to use different accounts so a developer doesn't accidentally bring down production by keying in the wrong password.

If you're using multiple BizTalk hosts (and you should be) then you need to make sure all the hosts are using the same service account (or that they are all AX users). AX will know which service account "created" the message and if it isn't an authorized AX user the AIF will reject it. It's frustrating because you look at the message in the AIF queue and the users are correct but somewhere the adapter is passing the other account. The error is some thing like "user not an authorized endpoint user".

This configuration will work, if you keep getting errors check the action policies on the endpoint in AX and make sure all that works. Might be worth submitting a message through the AX file adapter to check all that side is setup correctly.

Keep in mind this is for AX 2009, apparently a lot changes with the next version of Dynamics AX.