Martin "Goshoom" Dráb – Dynamics AX, .NET and Everything

Menu

AX compilation log parser

Dynamics AX allows you to export compilation output to a file (.html). The file can be imported back into AX and then you can work with compilation results in Dynamics AX application in the same way as after a normal compilation. That’s useful for later analysis without a need of recompilation, for automated builds and so on.

Nevertheless, it would be sometimes useful to analyse the results outside Dynamics AX and it’s needed to get data into a suitable format. If you look into the generated .html file, you’ll find that it’s really an XML with an HTML header and a transformation to HTML. Therefore import and export actually work simply with XML.

But… XML suitable for import to and export from Dynamics AX doesn’t have to be good for processing by other means. The generated XML contains just two types of elements – Table a Field, which significantly complicates queries and some values are not represented in any intuitive way:

This is a good solution for its purpose, i.e. for import and export from table TmpCompilerOutput, but it is not very useful for anything else.

If you wonder what additional processing I’m talking about, imagine that I have compilation logs from night builds over several months and I wound like to mine some information from them – where errors occur frequently, how the number of errors is changing with time and so on. And I really didn’t want to work with this structure of XML.

At the end, I didn’t chose the way of direct transformation of XML, instead I’ve written a simple .NET library for parsing compilation output to objects. I’m not going to describe it in detail (the link to the complete project is at the end of this post), it’s really simple – the whole parsing is done by LogParser class and you can get by with just ParseFile() method at the beginning.

That’s a significantly friendlier format for processing, but it’s not necessary to limit yourself to a simple transformation of a single file – you can, for example, filter just the relevant data or to work with multiple files in the same time.

Let’s look at an example with my night builds. At first we will load information about compilation errors (not warnings etc.) in all builds and save them to a single file.

It’s worth mentioning that the implementation is not exactly optimal from performance perspective, but it’s good enough for my needs, so there is no reason to do much optimization. The advantage of saving to a file is that this step doesn’t have to be repeated for further queries using the same data.

We could do a lot of things with the list of errors over a period of time. For example, the code below displays objects based on how many builds their occurred in and it shows the list of those days. It gives you a rough idea about where errors are often made or where errors are fixed slowly.