AX 2012 – Model dependencies and Install Order – Part 1-ww12345678 的部落格

Models in AX 2012 are a brilliant way to separate code between solutions in the same applications. They reduce merge time, allow code segregation and a lot more benefits.

Although, we do come to a point when code can start to depend on one another and even though it may look like it all works, at the time on installing those models into another application can cause an issue.

You say how?

Lets consider we are making changes to the VAR and the USR layer.

VAR Layer changes:

The VAR layer has the model, VAR_1 which has a class called: MyVar1Class, and this has methods method1, method2

At this stage we can export this model out and know that when installing this, it will not error out as this is not dependant on anything else.

USR Layer changes:

The USR layer has a model USR_1 which has a class MyUsr1Class with methods usr1Method1, usr1method2

At this stage, if we only take USR_1 model and put it into another application, we will not get an error. However, we add a method in class MyVar1Class called usr1MethodInVar1Class

Ok, we just complicated it. USR_1 model requires VAR_1 model.

Some more USR Layer changes:

Lets add a new model USR_2, with a class MyUsr2Class and some more methods in this. At this stage USR_2 is not dependant on the models VAR_1 or USR_1.

But if we add a method usr2MethodInUsr1Class in the class MyUsr1Class, now USR_2 is dependant on USR_1 which is dependant on the VAR_1 model.

Round robin change:

Switching back to the USR_1 model, we add a method to the class MyUsr2Class called usr1MethodInUsr2Class. This just means USR_2 is dependant on USR_1 which is dependant on USR_1 as well. The application compiles, its still a perfectly valid scenario.

So the Problem: With the above example when we export our models, and import it to another application, we will put in VAR_1 model first. Now while putting in USR_1 model, we will need the createparents switch which will create a virtual model, then we import the USR_2 model overwriting the existing model. This is a Giant mess. Not as giant as VAR code using USR layer code.

Save my day:

So I embarked on a mission to find out

How could I figure out what models are dependant on what?
How do i find from that, the sequence in which the models should be installed. (Some of the applications i deal with can have over 10 models in the same layer)

The answer: 42

Ummmmm, well, in some ways. There are other intergalactic species finding the ultimate question to that answer. But our answer lies in a few tables. Some of the tables conveniently hidden away from our sight, somewhere in the model database.

The model database has 2 tables I rely on for the dependency, ModelElement and ModelElementData.

ModelElement Table : This Table is a collection of all the elements in the AOT, down to every node. from tables, fields, relations, enums, EDT’s, classes methods.

ModelElementData Table : This holds the actual content of the element, be it properties for elements like Tables, fields, EDTs or method definitions for classes. This links back to the ModelElement table. So the ModelElementData can be many records for a single ModelElementRecord. In our example, if we were to overwrite the method ClassesMyVar1Classmethod1 in USR_1 model, then we would end up having 2 records in the ModelElementDataTable for method1. The ModelElementData table also holds the information to what model and layer the element belongs to.

So from the information of these 2 tables, along with helper tables like ElementTypes, Model, ModelManifest and Layer I was able to find out what elements are common between models. I could then use this to map all the dependencies and find out the ordering in which to set the models to be imported in.

More to be continued ..

In the next post I will discuss the workings of the tool that will take the database, analyse the models and output a couple of CSV files, for the dependencies and the model order.

Filed under: Ax 2012, Dynamics Ax Tagged: AX2012, Dynamics Ax