AIF Integration Differences: .NET BC vs XML integration to AX 2009 web service

I've received a question from a customer: 'We have two vendors who are integrating into AX using the same AIF web service except that one integration has the failed XMLs in the AX Queue Manager (Basic -> Periodic -> Application Integration Framework -> 'Queue Manager') but the other doesn't have a record in there. Both integrations, when they have transaction errors, show up in the Exceptions form (Basic -> Periodic -> Application Integration Framework -> 'Exceptions'). What gives?'

Good question! Here are two ways to integrate into AX's AIF: 1) .NET BC or 2) XML (eg SOAP, WSDL). From the scenario above, it sounds like the vendors are each using a different integration type. The one with failed XMLs in the AX Queue Manager is using the XML hitting the web service method while the other that is just showing errors in the Exceptions form is using the .NET BC.

When using the .NET BC integration method, the AX Queue Manager is not used as this feature is used for XMLs and parsing the data from them into the AIF web service AX components.  The .NET BC way is not using XMLs, but instead, writes the data directly to the AIF web service AX components completely bypassing the XML step (hence no record in the Queue).

Both methods are using the AIF framework objects which is why the errors relating to AX data are all showing up in the Exceptions form.

The XML integration way handles resubmitting failed data through the AX Queue Manager. Without AX modifications, the .NET BC will need to have an external way of resubmitting failed data to the web service.

With this in mind, depending on the application, both ways have their pros and cons. Hope this helps explain the issue my customer saw above.

For an example of the XML Consumption of the Inventory On Hand service in C#, check my other blog posts on here somewhere with some name (descriptive right??).