I meant to cover this in my last entry, but Kamal beat me to posting how to debug the AIF Inbound Processing framework. Please check out his October 23rd blog at http://casperkamal.spaces.live.com/ for more details.
David
Friday, October 27, 2006
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.
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.
Thursday, October 26, 2006
SP1 Enhancements Released to PartnerSource
I just reviewed the SP1 Enhancements that was posted up on PartnerSource. The enhancements won't impact us very much except for the well known fixes in SP1 like AOS Load Balancing issue being resolved. I won't repeat this list here as I don't know if the information is public domain at this point. If you have a partner who is willing to pass the document over to you, then by all means have at it. It's the 'Microsoft Dynamics AX Feature Updates (3.0 to 4.0) with the updated Appendix that lists all of the SP1 Enhancements.
Wednesday, October 25, 2006
Unexpected MODULUS functionality in AX 3.0/4.0
I came across this problem late yesterday afternoon and struggled with it again this morning until I received clarification from Microsoft on its intended functionality. I thought I would pass this along for those who may be struggling also.
I was working towards building functionality to test for the existence of line numbers in the Sales Line table where the line number had a .5 in it. For instance, if the line number was 2.5, I was attempting to perform 2.5 MOD 1 in order to get a result of .5. The only problem was that the system would not give me .5 but instead 0. It turns out that when the original AX developers wrote Axapta, they set the MOD function to only work against integers and not reals, hence the reason why I always got the whole number portion of the line number rather than the decimal part.
My workaround was writing a static method that converts the Line Number into a string, determines where the decimal place is in the string, performs a substring to pull out everything to the right of the decimal and convert it back to a real number and return it. This is essentially doing the same thing as MOD 1 would do to a whole number that has a fractional part.
Hope this bit of info helps!
I was working towards building functionality to test for the existence of line numbers in the Sales Line table where the line number had a .5 in it. For instance, if the line number was 2.5, I was attempting to perform 2.5 MOD 1 in order to get a result of .5. The only problem was that the system would not give me .5 but instead 0. It turns out that when the original AX developers wrote Axapta, they set the MOD function to only work against integers and not reals, hence the reason why I always got the whole number portion of the line number rather than the decimal part.
My workaround was writing a static method that converts the Line Number into a string, determines where the decimal place is in the string, performs a substring to pull out everything to the right of the decimal and convert it back to a real number and return it. This is essentially doing the same thing as MOD 1 would do to a whole number that has a fractional part.
Hope this bit of info helps!
Subscribe to:
Posts (Atom)