Towards Dynamics Ax Product Certification – Best Practices (Part I)

At Innovites the last couple of months have been a challenging period. We prepared our product for Dynamic Ax Certification along with two live implementations. In this multi post article, I will try to detail the derailing issues that we tackled to keep us in track. I thought this would be an interesting source of input for people who are planning be certified like us.

In order to get the product certified there are quite some criteria’s but as a product manager my whole responsibility was on ensuring the quality of the application in par with the Ax ceritification requirements.

On a very high level following is what we aimed at.

• Application should have “0” errors and warnings
• Best practice errors should be Zero
• No “To Do” tasks should be in the application
• Well documented help system

We planned to prepare for certification almost one year after commencing our product development. We felt it is a quite a late decision after seeing the number of BP errors, warnings and Todo tasks crossing the 500 mark.

Since our development environment was entirely on TFS it was easy to make the start even with such large number of violations. The options of “reject check in” with Bperror warning and Tasks  in Source controlled helped us implement this. The following article from the X++ team was highly helpful in resolving our warnings.

X++ team link – http://blogs.msdn.com/x/archive/2007/08/21/correction-guide-compiler-warnings.aspx

http://blogs.msdn.com/x/archive/2007/07/11/getting-rid-of-the-loss-of-precision-warning-message.aspx

Once we started this practice we found a steep increase not just in quality but also in terms of reliability in the code.

By the mean time we had slowly built strong Development infrastructure on top of TFS includes an automated build system that publishes Aod, Patches along with their release notes automatically to an PTP ( will details this in a article later). This automated system helped us keeping in track of our development quality every day.

After a month long practice we realized that the total number came down below the 100 mark , we reached “Ground Zero”(a internal project code) in the next couple of days.

The quality improvement in the application through this exercise interested us to get more disciplined. So this time we dived to fix the BP warnings as next step which is not a pre-condition forcertification. There were too many warnings from which it became difficult for us to identify the ones that we wanted to fix.

To our surprise we unraveled so many interesting things when we tried to fix these warnings. It even further delayed our certification process. …

Let’s look at them in my next article….

see you for now…