Home > Ax General Info > Towards Dynamics Ax Product Certification – Best Practices (Part III)

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

Recommended Reading:

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

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

Part – III

Though certification was our goal, the outcome of the certification exercise interested us in sticking to it more devotedly. In fact we went a step more than what it was demanded by the certification rules.  But to ensure all this we had to make the BP check process something that can be regularly used.

Below are few procedures we created/adopted to make the BP check something that can be regularly used…

> AIF BP Check is quite time consuming. So when every  you modify an table(adding or removing fields) which has corresponding AxBC class ensure that you regenerate all the service class that are used by the AxBC class. To regenerate use the following form

Tools -> Applications Tools -> Development Tools -> Application Integration Framework -> Update document service

This will update all the AIF Dataobjects like Classes, Macros related to the AxBc and prevent resulting BP’ Errors

>During Development don’t use the TODO command to store future requirements/clarifications. Use a separate requirement sheet/Quality backlog to record this. If you are using a Version control it is quiet easy. You can set it up in the “System Settings” form under version control.

>When you run BP for the entire application it results in a huge file(more than 500 MB) so it is better to reduce the log file size. There are two ways through which we can reduce the log files.

1. Enusre that only the checks that you required are verified. Go to the Best Practice form and clear all irrelevant check box. Like “XML Documentation” which are not required for certification. In our case we still got a larger file. So next we went in to the SysBPCheck_*** classes and tried controlling every individual validation. To do this we made a  entire list of BP check’s and decided what we want to follow or not follow. Then what ever we thought we wouldn’t follow we stopped their execution using #if directive macro. This exercise helped us bring down the log file size considerably. [Ref: Excel with all best practice: http://tinyurl.com/3ymz9pk]

2. The next target was the log file that was generated[We didn’t use syscompiler output window since the log was huge]. Looking in to the log file we found that there were lot of unused fields being exported[To identify the unused fields refer to the CSS in \Classes\SysCompilerOutput\xmlExport]. So we decided to export only the  fields that were necessary to view the log. You can do this by overriding the Xml() method of TmpCompilerOutput table.This considerably reduced the size of our log file, I  think it was some were around 4 times less. 🙂

By getting these procedures in place we have built a BP check system that regularly runs with our automated nightly builds. We made quality development a continuous process.

With this I conclude the series on Best Practices. In a next series of article i will explain how we automated form documentation, builds and Release notes for our vertical. Keep reading.


  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: