Wednesday, April 27, 2011

AX 2012 Events

With the introduction of events in AX2012, a slew of possibilities has opened up. At the technical conference in January 2011, Peter Villadsen first unveiled the power of the new functionality. In conjunction with that, I had prepared a lab exercise which was available at the conference. I am working on preparing a new lab document, which I will post here on my blog, which is largely based on the original tech conference document, but with more detail and showing every possibility (the tech conference lab was limited to 1 hour of work, so some features were not explicitly shown).

Before I start posting these labs here, I would like to point out a few VERY important things that I feel the AX developer community should be aware of.

1) The pre/post handlers are a powerful concept, but one needs to be aware of its limitations. The power lies mostly in the ability to add behavior without modifying, and the power to apply/install multiple solutions together without the need to merge (think AxModels, or even traditional XPOs).
However:
- when subscribing a handler, the subscription has a "name" property, which should ALWAYS be changed to a meaningful yet unique name. Failure to do so immediately eliminates the power of installing models without merging, since now you have two subscriptions titled "EventHandler1" and one will overwrite the other.
- when changing return values in a post-handler, be aware you may not be the last handler to do so. When changing the value of a validateField(), only change it to FALSE if you have a reason to do so, otherwise, leave the return value alone. In other less obvious cases, be aware of the limitations and potential other code impacting the return value.
- same goes for pre-handlers and changing arguments to the original method!

2) Managed handlers are powerful, but have their limitations. I will go into this in my lab posts, but there are limitations in what you can and cannot do, and what you should and should not do. Remember any data manipulation you do from managed code will have to cross the boundary again and could impact your code's performance.

3) When creating delegates, look at best practices for C# delegates. Arguments should be the sender object, and a class, Extending XppEventArgs base class, containing all the variables you wish to pass. This will ensure that the API your delegate provides will never get broken. If you ever wish to add more data, you would add it to the class, without breaking any delegate subscriptions depending on your delegate method's signature.


As far as delegates and events go, please review C# best practices for naming conventions (eg "InvoicePosting", "InvoicePosted" as delegates, and the subscribers should be "InvoicePostingEventHandler" and "InvoicePostedEventHandler").

Wednesday, April 13, 2011

New, Changed and Deprecated Features for Microsoft Dynamics AX 2012

Microsoft has a released a comprehensive 207-page document entitled "New, Changed and Deprecated Features for Dynamics AX 2012".

You can download XPS and PDF versions on the Microsoft Download Center.

Tuesday, April 12, 2011

Dynamics AX 2012 Public Beta

The opening keynote by Steve Ballmer at Convergence 2011 marked the public availability of the beta of AX 2012.

Check out Dynamics AX on MSDN, which now has an AX 2012 beta page.

You will need CustomerSource or PartnerSource access to download the betas. Remember the virtual image is Hyper-V, for which you will need a Hyper-V server, OR you can also try the unofficial non-supported way and try to run it using OracleBox.