AX 2012 Development – Layering in AX and Why We Have Code Conflicts

By Laura Lake | May 21, 2015

The Layer concept is unique to Microsoft Dynamics AX Development and can cause some confusion for developers who are new to the AX development environment. In Dynamics AX we have 8 standard layers, plus 8 patch layers. The layers are fully described and documented elsewhere, so this article will not rehash that information. However, it is helpful to keep in mind the order of layers from highest to lowest, described here.

The important thing to understand is that when an object/element is modified, some or all of that element is copied from a lower level (the next highest layer where it exists) to the current layer. Note: For classes and tables, only the modified field or method is copied to the current layer.

AX will always use the version of the element on the highest (outermost) layer.

To illustrate, let us assume the current layer is cus and we added a new method and modified an existing method on class CustVendCheque.

New method “some_method()”

Some Method

Modified method checkDateOk

Classes CustVendCheque

We can easily take a look at only the cus layer changes by exporting the Application Object Layer.

Application Object Layer

The xpo file will contain only the method we modified and the new one created, since those are the cus layer changes. (Note: Code lines replaced with … below for brevity)

CLASS #CustVendCheque
    PROPERTIES
      Name                #CustVendCheque
      Origin              #{2D0E1482-0000-1000-54A9-07DDFFFCED73}
      LegacyId            #5250
    ENDPROPERTIES
    
    METHODS
      SOURCE #checkDataOk
…
      ENDSOURCE
      SOURCE #some_method
        …
      ENDSOURCE
    ENDMETHODS
  ENDCLASS

***Element: END

Taking this example one step further, let us look at what might happen if someone makes a change to the checkDateOk method on the var layer. Assume that this developer was working in another environment where your cus layer changes do not exist.

He adds the following code…

if (!accountId)
 {
//return checkFailed("@SYS24651");
return checkFailed("@NEW2");  //chg on var layer
 }

Remember, this class existed on the syp layer initially, so you and the other developer pulled the same version of the class to make your changes but on different layers. Because cus is the higher layer, those changes will “overlayer” the var layer changes unless you do something to intervene. This is a code conflict, and a decision must be made about what code to keep.

Comparison in Dynamics AX

The above code is oversimplified, of course, but this is exactly what happens when you install a CU or hotfix. Changes in the syp (patch) layer may be overlayered by customizations of those same elements in higher layers.

Start the Conversation

It’s our mission to help clients win. We’d love to talk to you about the right business solutions to help you achieve your goals.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!

X