Axapta

Since writing about how I monitor Dynamics AX batch processes from a more technical perspective, I have been asked how to set up monitoring for a complete Dynamics AX system.

Many years ago, Scott introduced me to Nagios, an open-source product designed to be able to monitor anything. At the office, we use it to monitor practically everything, and to fulfil Sarbanes-Oxley requirements, such as monitoring temperature or backup reliability. If we could, we'd monitor the coffee machine with Nagios.

Naturally since we've built our monitoring around this system, we use this to monitor our Dynamics AX environment too. Much of the information here could be adapted for monitoring other systems too, but the focus of this article will be simple monitoring for Dynamics AX.

Just under a month ago, we completed an upgrade of our Axapta 3.0 SP5 KR3 system to Dynamics AX 4.0 SP1. For those who don't know, Microsoft Dynamics AX is the new name for Microsoft Business Solutions Axapta.

During the upgrade, we ran into many problems, so I thought I'd write up the highlights so others in the same position could benefit. I don't seek to condemn the product, in fact I think the product in general is very good, however I believe this information should be available to help others out. All of these problems have been presented to Microsoft, at least a month ago, and I've also provided my solutions where applicable.

Our company was the first to use the European Commission's VIES system via SOAP to validate VAT numbers automatically. We used to have a custom hack to perform this operation within Axapta 3.0, waiting for what was then a rumour that Dynamics Ax 4.0 would be able to call .NET assemblies via CLR interoperability.

In my previous article, I touched on calling code within Ax from C#, but now I want to explain how this works the other way around.

I'm currently in the process of migrating our Axapta 3.0 system over to Dynamics Ax 4.0. This is a difficult process due to the number of customisations we have made in the system, and many changes between the two standard code-beds. In light of this, we've been conscious of new developments on the horizon, so some of our customisations had temporary snippets of code in them, waiting for enhancements such as .NET interoperability.

One of these temporary snippets of code is responsible for monitoring recurring batch job execution, and ultimately the use of a monitoring system completely outside of Dynamics Ax is preferable. This is where the .NET Business Connector steps in, and since a small number of licenses come with the base Dynamics Ax product, it can be a really useful development tool. Most of what's written here will also apply to the old COM Connector, in principle.

It seems that calling Windows API functions from Axapta is viewed as some sort of mysterious magic by most Axapta developers. Unfortunately, there are times when you need to do something that requires tight integration with functionality that exists outside of the system. While there are other methods of interfacing between bits of code, including COM, XML-RPC, or even .NET, using the Windows API can sometimes be very efficient, and powerful.

For beginner WinAPI coders who are also Axapta programmers, with at least some programming experience in C or C++, I felt it might be better to answer a question from my colleagues about calling WinAPI calls from Axapta, outside of those already wrapped by the WinAPI:: or WinGDI:: classes.

Axapta inherently begs community involvement from X++ developers due to its horrible lack of documentation. Dynamics Ax 4.0 (the erp system formerly known as..) certainly solves this to great lengths, but there are still grey-areas here and there which need to be filled in.

I often get asked about tips and tricks in Axapta, and today I was asked (again) about the nofetch keyword in X++ select statements. Why is it there? What's the point?