Followup to AIF Configuration Entry

I noticed an additional comment onto my AIF Configuration entry today and decided I would answer and inject some new findings that I have since last discussed. The comment asked how to add an additional field to an existing XML transaction such as the Purchase Order transaction which works off of the AxdPurchaseRequisition document.

First of all the documentation up on MSDN is getting a lot better. The documentation team has added many different articles on explanations of AIF, detailed explanations of the different transactions, and how the AxTable classes work compared to the Axd classes. Check out Dynamics MSDN at http://msdn.microsoft.com/mbs/

Generally, to add a field to any AIF transaction you must first determine the underlying tables to that transaction and add the appropriate fields. In the case of Purchase Orders, the main underlying table to it is the PurchTable/PurchLines or for Sales Orders is SalesTable/SalesLines. This is where you need to add the fields that you would like to appear in the AIF Transaction. Also, if you want these fields to be editable by your users, of course you need to add these to the front end GUIs to these tables. After you have made these additions, run the Axd Class Wizard to make these additional fields appear in the respective action's schema.

Axd Class Wizard Walkthrough
1.) Choose what Query is being used for the Axd Document Creation and click 'Next'.
(If the AIF transaction is one that came with the base AX installation, the query will be named Axd..., i.e. AxdPurchaseRequisition. You should also strive to name all of your custom AIF action queries with the 'Axd' prefix for standardization.)

2.) Leave the Class Name as-is and enter a label for the for the Axd class. Choose what actions can be performed for this AIF document transaction and click 'Next'. For a list of the actions' meanings, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/AxDeveloperDocs/html/89e37bf6-3dda-4485-b123-d091f46cc2ed.asp. You will notice that the 'Supported Actions' names on the Wizard correspond to the Axd Document Method column.

3.) On this final screen, if this is an existing Axd Document, you should see the 'Generate AxBC Classes' checkbox is grayed out. Check the 'Regenerate existing AxBC Classes' checkbox and click 'Generate'. If the Axd Document is new, check 'Generate AxBC Classes' and click 'Generate'.

4.) Open the Actions form in Basic -> Setup -> AIF -> Action. If the Axd Document you were working on already existed, you can simply highlight the action and click the 'Re-register' button. If the Axd Document was new, click the 'Scan and Register' button to reread all Axd Document classes, which will find your newly created class.

5.) Either way, after the scan and/or register process finishes, you should be able to highlight the appropriate action, click 'View Schema' and see the new field that has been added to the XML schema associated with the action.

Finally, just a quick overview of what the AxTable classes are compared to the Axd classes:

Axd classes extend the AxdBase class which contains the logic for developing the XML Schema and implementing the six Actions referenced above Create, CreateList, Send, SendList, findList, and findEntityKeyList. There is also logic for validating the XML documents for compliance to the XML Schema associated with the Action.

AxTable classes extend the AxInternalBase class and contain the logic for validating and writing data retrieved from the XML documents to their respective tables in AX. This class contains data validation logic. This logic is contain in each parmFieldName method within the respective AxTable class.

Currently, I am working to write my own custom AIF validation logic, particularly in the createListSalesOrder action and particularly with the AxSalesLine.parmItemId() method. Out of the box, AX kicks out any inbound XML SalesOrder that has a SalesLine that contains an ItemId that is not present within the InventTable. I am working to write additional validations to check for the existence of ItemId in the InventTable and if it does not exist, assigning a 'catch-all' ItemId to ItemId such as 'InvalidItem', and writing the original invalid item to the Name field. Ultimately the order will be halted and an alert will be sent to an Order Analyst who will try to determine what is invalid with the Item Id, but the order will still post in the SalesTable/SalesLine tables and won't be kicked out as with the current functionality. My current modifications have yielded failure on the processing part of the AIF but I'm confident I will have success within the next week. Once I determine how to add my validations without breaking the AIFInboundProcessing process, I will post my findings.

I see AIF as have the potential of being extremely powerful and extendable to incorporate custom business logic, but the documentation so far is nonexistent of how to do so in a standardized way in which you won't systematically blow up the existing processes (like I have in my tinkering).

I hope this helps. If you have any questions, I'll try to answer them as best as I can in subsequent entries.