AX models – Part 3 – Multiple models per layer

In my first two posts on models in AX (Part 1 and Part 2) I covered the deployment specific behaviors of .axmodel files – it should be apparent we introduced .axmodel files as a deployment replacement for AOD files. In the process we added some nice capabilities like a manifest and signing. The real benefit of models, and the ultimate reason we are adding this level of abstraction is because:

You can have as many models per layer as you want.

Let us examine this statement. In AX2009 a layer is the confinement unit of model elements. The layer is the unit of which you can export, deploy and delete model elements. (Here I’m deliberately ignoring the capabilities provided by XPO files, as these are suitable for development purposes only, and not deployment.) In AX6 this limitation has been removed, that means you can segment your layer into as many models as you like.

Here are a few examples where this could be useful in development scenarios: 

  • If you deliver more than one solution:
    You can have a model for each of the solutions you are working on. This enables you to work on them simultaneously while having visibility into which model you are working on.
  • If your solution is getting too big:
    You can segment your solution into several models – and have teams/team members work on their own model. The models can be either self-contained or have dependencies to other models. This enables you to clearly define ownership between the models, clearly define the APIs between the models, build the models individually, etc.
  • If you write unit test:
    You can have a model for your production code and a model for your unit tests. This enables you to easily import all your unit tests, run them, and remove them again from the system.

Let’s examine the statement a bit deeper. There are two ways of getting a model: Either you create one on your own, or you receive it from someone else. If you can have as many models as you want per layer, it also means:

You can deploy models from several sources into the same layer.

Here is an example: You are a customer and would like to install two ISV solutions that both are available in the BUS layer. In AX2009 you would have a tough choice to make: Either you picked your favorite solution and learned to live without the other one, or you invested in having the two solutions merged into one layer. This merge is technical challenging, and a costly affair once updates to either solution are being released. In AX6, however, you download the two models, and use AxUtil to import them. When a new version of either model is released, you simply use AxUtil to update the model.

The catch

This all sounds too good to be true, what is the downside? There is one limitation to what a model can contain:

An element can only be defined once per layer.

This means that two models containing a definition of the same element cannot be installed in the same layer. For example; if the two models both contain a class named: “MyClass” they will not be able to install side-by-side in the same layer. Model elements have two alternate keys, they are: [Type, Parent, ID] and [Type, Parent, Name]. Each layer can only contain elements that can uniquely be identified via the two alternate keys. In less technical terms, this means that two elements of same type under same parent (or without a parent) cannot co-exist if they have same name or same ID. For example: A table cannot have two fields with same name, or two fields with same ID. Another example: You cannot have two display menu items with the same name.

There are three ways you can be hit by this limitation:

  1. You create an element, and give it a name that accidentally also has been chosen for another element by someone else in their model. A good way to avoid this to prefix your new elements with short string that uniquely identify you or your company. So instead of me naming my class “MyClass” I should name it “MfpMyClass”. You can think of this as poor-man’s namespaces. This is a practice that is already widely used.
  2. You create an element that will be assigned an ID by the system, which already has been assigned to another element created by someone else in their model. Our plan is that this cannot occur once we ship AX6 – we are close to a full implementation of this, but we are not there yet. I’ll return with more details on this at a later point.
  3. You customize an existing element that also has been customized by someone else in their model. There is really nothing you can do to avoid this collision, except to avoid customizing – which is not desirable nor possible. To alleviate this problem we are investing in changing the granularity of elements. In AX2009 tables and classes are stored with a fine granularity. This means that there is no collision if two models change two different methods on the same class or table. In AX6 all new concepts introduced in the model will also use a fine granularity – further we are breaking down some of the existing concepts, so far we have completed this work for Menus.

So apparently we cannot guarantee that models can co-exist in the same layer – so what are the options when two models are in conflict? When you import a model that conflicts with an already imported model, you get three options:

  • Push-up (default)
    This option creates a new model in layer above containing the conflicting elements. This enables you to log into this layer and resolve the conflicts using the MorphX tools you are used to. Please notice that only the few elements in-conflict will be moved into this model, so the resolutions required are limited, and the original models will co-exist in the model store – but not only in the same layer.  

    For example; if two models (“ModelA” and “ModelB”) are imported into the BUS layer, then “ModelA” is imported without any problems, and “ModelB” will be imported into two models: “ModelB” in the BUS layer, and “ModelB_Conflicts” in the BUP layer.

  • Overwrite
    This option will overwrite any existing definitions with the definitions in the new model. Any model containing element definitions that get overwritten will be logically grouped with new model. The grouping ensure that an eventual uninstall of a model doesn’t leave the system in an in-complete state. This option is primary useful for patches that are accumulative in nature.

    For example; If a model “ModelA” containing PatchA is already installed, and a new model “ModelB” containing PatchA+B is being installed then this is the right option. Later; if “ModelB” is being uninstalled, then “ModelA” is also automatically uninstalled.

  • Abort
    This option aborts the operation and leaves the model store untouched – perhaps you specified the wrong model file, perhaps you want to investigate the models before continuing. 


Models enable a lot of highly desirable scenarios, one of the most important scenarios being that models from different sources – for example, two ISVs – can be installed in the same layer side-by-side.  There are a few technical limitations; but the risk of conflicts is much reduced in AX6 and even when conflicts occur there is a less-expensive way to make the models co-exist.  

More on models…

This post is a part of a series on models:

  1. Deploying models
  2. Manifest and signing
  3. Multiple models per layer
  4. Working with models inside MorphX

This posting is provided “AS IS” with no warranties, and confers no rights.

Comments (15)

  1. Dali says:

    Hi, a few words to more models in same layer. Gustavo example – if there are changes in code made in model B in method which belongs Model A, these changes actually  always belong Model A although they are made in different model. From our experience is very difficult to work on two models in same layer if they have cross dependencies. If there are more developers working on both models and you have to export only parts of models from dev to tst and not whole models, it s really big troubleshooting to deploy only parts of solutions with changed objects which can have mixed model elements. I think there is missing partial model deployment from project for example.

  2. msmfp says:

    @Gustavo: When you customize a table, the changes will end up in a model. You can have multiple customizations to the same table in different models. E.g. two models adding a field each.  When exporting and importing the models only the customizations as part of the model is included.

  3. msmfp says:

    @Mempheus: AxUtil offers ways to upgrade existing models without impacting business data. That would be my recommended approach. Learn more here:…/hh335181.aspx

    @Patrick: This is spot on, and I'm happy to say we solved this issue as well. Please have a look here:…/the-solution-to-the-element-id-problem.aspx

  4. Patrick says:

    There is one huge glaring weakness here.  The configuration keys and license keys cannot be pushed up.  And since everyone created keys that are 20002 or 10001 they all conflict.  This means that ISV's have to then either (a) create a bunch of keys to increment the number and then reset the child objects to the new item, or (b) remove these items from the model, which is the reason we have it in the first place.  

  5. Hi mfp,

    Model is sounds like a really promising deployment vehicle.

    But as any innovation it naturally brings some unclear situations apart from profit.

    Imagine situation:

    – you have working AX2012 prerelease instance

    – db is populated with valuable data

    – release is issued

    – you can update AOS (kernel) to release version

    – but models live side by side with data and still had prerelease version

    What's the most elegant way to update models' (application) version and leave data untouched in db?

    Replace models by those distributed with release?

    Replace by means of AxUtil? or with help of db installer?


    thank you for such exciting articles

  6. Gustavo says:


    I read all your posts about models and they are great.

    I still cant figure out what would be the best "way out" in this scenario:

    If you create two models (ModelA and ModelB) and in BOTH you customise the Table "SalesTable", is there a way to export ModelB ONLY WITH the code that's been added within ModelB?

    Or exporting ModelB will also carry ModelA's code?

    When importing *.axmodel you could put an option "Merge Code" so we could automaticaly merge the conflicting code, without needing to logon a "higher" layer and doing it.

    Could you answer that for me, if you have the time? =D.

    I'm from Brazil and I'd be veeery appreciated with your answer.

    Thanks in advance.


  7. msmfp says:

    HS: You are right – if two solutions both touch the same element then a conflict occurs. (e.g. we cannot automically resolve a color property if one ISV sets it to red, and another to blue). We have added several features to make it less likely these conflicts will occur. These features includes eventing and fine grained meta data (primarily for forms). Further; we have added features to allow the partner/customer to manully resolve eventual conflicts occuring.

  8. HS says:

    It is great to have solved the ID limitation issue. But the issue with code merging is still present. Most of the time as an ISV or Customer we have to modify base classes and tables, forms then upgrade and code merge is still an issue. When two solutions are modifying same base object it code merge becomes ugly.

  9. Fiona says:

    I just accidently got on this page and it is an interesting article. We've just recently made a website for an Microsoft solution provider. Anyway, thanks for sharing the article.

  10. Ariff Damji says:

    This sounds very good.

    Is it to much to ask for a History of changes?  Considering the AOD "files" will be in the database, and that elements within a model would be stored in the database, it would be nice to be able to do diff’s on elements.  

    For example, just like most source repositories, we could go back in time to say the 4th change in a class (out of perhaps 6), and do a diff between the 4th version and the 3rd version.

  11. msmfp says:

    Hi Rob,

    Releasing code via XPO files is not a good solution, in AX2009 there are scenarios where it is the only option.  In my previous 2 posts on the topic I explained the benefit of using models as a shipment vehicle; primarily having a manifest and being able to sign the models.

    In the scenario where code is in conflict, you would still have to solve the conflict, regardless if the code comes in via a XPO or via a model. With models we are able to point you to the conflicting elements – with XPO you need to find them yourself.

    The main benefit with models when having multiple solutions in the same layer, is that the solutions can be upgraded independently just using models. In AX2009 you typically have to convert the AOD file to an XPO file and then import it – and deal with ID issues in the process.

    I hope this make it clearer.

  12. Erlend Dalen says:

    I’m really starting to like the idea of models. It sounds like this is going to be a great feature in AX6. I’m however cutious to hear if you have considered integrating the model creation from the morphX and/or TFS version control.

  13. Rob says:


    regarding this statement:

    "This merge is technical challenging, and a costly affair once updates to either solution are being released. In AX6, however, you download the two models, and use AxUtil to import them. When a new version of either model is released, you simply use AxUtil to update the model."

    I don’t see what the advantage of a model is over a project exported to an XPO ?

    If the same component is modified in the 2 ISV solutions you want to use, you still are looking at merging the code, correct ?

    If I have both ISV solutions in Project/xpo form and they do not overlap, I can still import them both without problems. Or is the key point here that you do not have to do the manual compare, but just can import the models and have the utility show you the conflicts ?

    Thanks for the great write ups.


  14. Hello,

    I was wondering: can you really see a constrained model as a component? This is probably a discussion around definitions… Although, I can understand that an Ax design can have a focus on modularity starting from its specification and followed by its implementation and its modular deployment. But to call something a component I should think it also needs to have an instantiation. As I understand Ax has not something as an instantiated model with specific resources? An Ax model helps to better manage modular design and deployment, but will not support component instantiation and Ax will not become a component platform?

  15. Until now the only penalty for choosing a component based architecture for AX code has been that deployment and installation has had to rely on XPO files, which brings a fairly high risk of mistakes both at export and import time.

    With the introduction of models, AX finally supports a component based design and development approach with a very robust deployment model. Good job guys!