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

Refer Here… for the First Part

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

In order to figure out the warnings from our vertical layer we had to make a dataset of the standard warnings without our layer. After fixing the remaining 100 warnings we sent our application for mock certification test to internal test team. They found more than 50  BP errors in individual components.

This came to us as a surprise as our automated build process indicated only zero vertical warnings. After some exploration  in to the compilation process indicated that the Bp count that comes through standard AOT  compile is not actual.

To achieve a complete Best practice check we must use the sys cmed –BP check and not a  compile on the entire AOT.

ax32 -startupCmd=checkbestpractices

This invokes BP check  component by component. This output is what we need to use to ensure that our application is BP error free.

The proper Bp check almost ran for 9 hours and 30 minutes resulting in a total of 1 lakh and 50 thousand Bp errors, warnings. The huge number of error made it difficult to verify the compiler output directly in Ax. The exported log file was more than 400 MB which failed to open in any browser.

Finally we had to use streaming editor like GREP to scan through and find errors. The scan indicated errors in both our vertical and standard ax(believe me it has).

We fixed all this BP Errors to achieve our first complete error free  build that can be sent to certifications.

This is a quite time consuming and tedious if required to be followed in a regular basis. We used our learnings here to improve the Bp system, make it simpler and easy to follow every day.

Let’s see how we made it simpler in the next part…

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…