AX 2012 Development – Layering in AX and Why We Have Code Conflicts
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()”
Modified method checkDateOk
We can easily take a look at only the cus layer changes by exporting the 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.
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.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.