AX models – Part 1 – Deploying models

About a milestone ago I announced SQL AOD. Since then it has been quite quiet on my blog – for two reasons 1) I’ve been heads down in new features and 2) I’ve been on paternity leave. Now the completion of M2, the next milestone of AX “6”, is within reach and I’ve returned to my office. This means I can share some more exciting news.

Since the days of AOD files are numbered we need a new vehicle for deploying metadata elements to an AX installation. To address this need we introduce Models. A model is a containment of metadata elements.

To create a model you use the new command line utility AxUtil:

AxUtil create /model:”My Model” /Layer:USR

This will create a new model with the name “My Model” in the USR layer. This new model can be selected in the AX client configuration utility as the default model. When you start AX the status bar will tell you which model you are currently working in – just next to where the current layer is shown. When you make changes in the AOT, like overlayering elements, creating new elements, changing X++ code etc., the resulting elements will automaticaly be contained in your model.

When you have completed all your changes, then your model is complete. In other words it is time to move the model from your developer box to a production system. In AX2009 you would copy your AOD files – with models you need to export it to a physical file. Again you will use AxUtil:

AxUtil export /model:”My Model” /file:MyModel.axmodel

Now you can copy this file to the production system and import it there:

AxUtil import /file:MyModel.axmodel

You can even uninstall it again – if that is what you want. This is semantically the same as deleting an AOD file in AX2009:

AxUtil delete /model:”My Model”

So far I have described the model capabilities that gives parity with AOD files: We have a file based container that can be xcopy deployed and we can delete models again.

From what I’ve described so far models aren’t much different than layers and AOD files. They are; and provide some highly desirable capabilities – which will be the topic of a near-future post – so stay tuned.

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 (19)

  1. NIlotpal says:


    I want to know, how we can import a user layer model into var layer?

  2. msmfp says:

    In the top right corner of my blog is a "Contact" link. You can use that to communicate with me.

  3. ABC says:

    Hi ,

    Thanks to your blog, that i understood the models in ax 2012.

    But can i get you mail id or skype id so that we can discuss some more on that.


  4. kalyan says:

    can u explain this more effective than this if you do"nt mine

  5. Alex.K says:

    It is good to know how a model can be exported and imported. But what possibilities do i have with exporting and importing the data from an productive-system to a qs-system? The dumpfiles that axapta can create is dead slow. E.g. i have databases with 10 or even a lot more gibibytes.

  6. msmfp says:

    You can view the elements in a model file using the AxUtil view /verbose /file:myfile.axmodel command, but you cannot see the actual source code and properties before it has been imported. For that you will still need to use XPO files.

  7. Dan James says:

    Hi Michael – In terms of code migration, does this allow comparison and selective import between different environments? eg If several developers have made changes to SalesFormLetter, and one of those dev's changes need to be moved to a new environment, would we still be using XPOs and the comparison/merge tool, or is this somehow handled using the new models?



  8. Patrick Bovens says:

    Hi Michael, thanks for sharing this with us. If I understand this correctly models can be considered to be sublayers. What about any dependencies between models, are they detected and handled in any way?



  9. Ferit says:

    Thats perfect !!! now we have more layers and import/export will so nice

    i am looking forward to see AX 6


  10. Jagjeet Singh says:

    Can’t wait to see this happening.

  11. msmfp says:

    Hi Arijit,

    The AxUtil also has parameters to specify which database you want to operate on.

    You can only sign the .axmodel files. With this you achieve the files can be trusted eventhough they have been transmitted over an untrusted media.

    Once the .axmodel file is verified and installed into the model database, the signing has no significance anymore. The content is now stored within a trusted environment.  This means that you can change the installed bits; but you will not be able to produce a new .axmodel file with the same signature.



  12. Arijit says:

    If I have multiple instances of AX 2011 loaded on my PC, using AXUtil how to export & import these model elements? Could you please give some more information about this? Say a partner has developed some code on BUS Layer (Signed Model) and as a developer I get into the BUS Layer and modify some code? How will it impact the authenticode sign of the solution?

    But this sounds very exciting. Waiting for the M2 build.

  13. msmfp says:

    XPOs and AOT projects remain more or less unchanged in AX6.

    Element IDs are a different story. They are going to change – for the better to break the 16 bit barrier and avoid the uniqueness constraints we have in AX2009.

    I already posted a blog on element IDs here:

    I’ll be more detailed when I have more to share on IDs; that is, when it has been implemented.

    BTW; thanks for the encouragement. I can’t wait to release AX6 – the feedback we get on the new developer capabilities is amazing.

  14. Jason says:

    Hello mfp,

    I’m a bit curious: is the idea of projects, element ids and xpo’s going to change in the next Ax release or a following release, if you know? Currently we made a module in Ax that supports developers and managers with development activitiets in Ax and that module uses intensively these capabilities of Ax.

    The future of Ax is definetly going in an amazing direction! Great Job.

  15. j.a.estevan says:

    it would be nice if you can do the same with the anoying label files 😉

  16. j.a.estevan says:

    nice! this will be way more useful that closed layers that need to be shared without partners or clients.

    awaiting for the new features! 😀

  17. msmfp says:

    Aman – yes, that is correct. Models provide those capabilities.

  18. Aman says:

    Hi mfp,

    Does this mean that a model is like a developer’s layer in which he can keep his modified/new objects and import/export/delete in different AX environments just like we do in layers.

    This seems to be very exciting and very helpful.