Writing sustainable Code in AX Part I

I have long wanted to post something on this subject as it is the most often repeated question from customers.

There are two main schools of thought :

1. Do as little development as possible, and stick to the standard functionality.

2. Start adapting Dynamics Ax as needed.

The first options seems to be the most intuitively correct option, there is only one issue with this option, that is that Ax in it's standard inception is not well suited to almost any business that is contemplating implementing Ax.

I have participated in a large number of implementations of Ax and have only ever seen one succesfully toe the line, and that is the reference customer that Damgaard used to use in Denmark that is situated in very close proximity to the development center. Where the management had decided to follow the line in order to be beta customer all along the line, and have done so AFAIK to this day.

Aside from this one customer I have not met any that have really toed the line in this respect though most actually profess wanting to do so, but as the product is designed to be built on rather than be followed it is hard to do so.

If you want to use an analogy that is easy to understand both Dynamics Nav and Dynamics Ax are a bit like another famous Danish product which some of us have played with in our infancy, Lego. Both systems have been built to be modified, they provide the basic building blocks and trace a map of what the business processes could be like, a set of building instructions if you like and thereafter you are given the opportunity to adapt this map to your business.

If you take most other systems they are more built along the lines of a prefabricated model train track set, you can choose at each intersection which way to send the train but you cannot change easily where the interchanges are nor what they govern. I will name no names ;-). And if you want to change your track layout you have to start major civil works in order to adapt the wanted layout to the landscape, and in most cases that has consequences further down the line.

In my view after having worked with both Dynamics Ax, Dynamics Nav, XAL, and other predecessors for over 20 years, it is best not to do either.

Option 1 of doing no dev negates the competitive advantage provided by the fact of choosing a flexible ERP system designed to be flexible, option 2 of doing all kinds of development as required usually winds up in excessive upgrade costs.

The art of being a good implementer of this product lies then in balancing the two options just right in order to acheive an implementation that is as I called it in the title sustainable.

I have been trying to establish a set of guidelines in this regard the problem is of course that as with any good compromise it should be flexible and adapted to the situation.

As an example, in general terms it is not good to change the central data model in the application as those kind of changes may necessitate extensive work in the future during upgrades. However take the case of a medicinal company that needs extensive tracking and needs to use its inventory in a very specific sequence and to transfer Use by date information throughout. In their case not making changes to the central data model is stupid as the changes necessary can be handled much more easily by doing so than by not doing so.

There are off course many such examples, anyhow I have to get back to my day job I will detail more in my next posting on the subject. And look forward to any comments.


/Sven

V4 Second look

Now that the real V4 has come out, in the form of SP1 or 4.01 depending upon when you asked the question :-), what is it like ?

What has changed compared to the buggy version brought out in June ?

Well certainly most of the bugs that I have discussed here seem to have been dealt with but some have not and some new ones have appeared, in my estimation SP1 was rushed out the door. The proof of the pudding is often in the tasting as they say concerning food :-) in this case SP1 was supposed to have been release in early november for a limited number of countries and in early december for the rest.

In actual fact the november version was brought out on the 5 of december after a gargantuan effort by everyone to get most things ready, and thereafter on the 22 of december we got the rest. Not a huge delay by any means in software terms especially considering all the teams that had to co-ordinate and deliver in order to meet the deadlines that were originally set.

However the problem was and is that a large number of issues still exist even after the cutoff and as work was being carried out untill the cutoff date it is fairly obvious that there are and will be a large number of issues in what has been released, not on the tools side but on the functional side where there has not been enough time consecrated to tesing the application.

Hopefully we will see an SP2 in the plans soon in order to correct this, or alternatively the 4.1 release being brought forward.

On the technical side we have probably one of the best AOS implementations ever, fortunately as we now no longer have the option of not using the AOS. I have had the opportunity of testing with a farm of AOS servers and a large number of clients and in many instances even shutting down several AOS's many of the client sessions survived. Which given the parallel execution streams that are ongoing is pretty damn impressive, just as a reminder in version 3 and before if an AOS was taken off line all it's sessions died automatically.

On the dev side I have not really used the CLR functionality extensively yet but it looks good.

I will have to continue later, interrupted by an issue with KR2.

/Sven

Layers News

Well MS have recently announced that they are doing the country localisations in the GLS layer, so where does that leave things ?

I am sure that unless someone is very very carefull we will see some strange issues regarding field numbers, for those who know skip my explanation.

In Dynamics Ax all objects (Tables, Fields, Classes, Methods, Reports etc) aside from their names receive a number which is used to reference them in the code, the P Code or run time code that the Ax compiler creates uses the numbers to reference items not the name as this would take up to much space and would also significantly slow down execution.

The numbers in question are alloted based on the layer in which the elements are created, that is 0 upwards is SYS etc, what will now happen with elements that have been migrated from the old setup where the SYS code was in SYS, GLS, LOS and DIS to no being only in SYS and GLS. One can only hope that they have kept the numbers from Verson 3 when building but also we could have phantom numbers apppearing because of certain localisations having been present when add-ons or code was made and now thos numbers could be re-used by other code.

Fortunately the compiler is pretty good at at least enforcing type casting, but well this could be an interesting issue to follow in the future.

/Sven