New Layers in Ax-2009

4 layers have been renamed in Dynamics AX 2009 . DIS / DIP / LOS / LOP have become HFX / SL1 / SL2 / SL3 respectively. HFX is reserved for releasing hot fixes, and the 3 new solution layers (SL1/SL2/SL3) will be used to release Microsoft Dynamics Industry Solutions.



The purpose of having 3 solution layers is to enable side-by-side install of Industry Solutions. At deployment time any SL1 layer can be renamed to SL2, SL3, BUS or BUP through a regular file rename. The AOS will recognize the layer, and honor its position in the layer stack. This will enable installing up to 3 Industry Solutions on the same system (or up to 5 Industry Solutions if the BUS and BUP layers are vacant.)

Another aspect of side-by-side installation is conflicting names and IDs in the model. The AX platform requires unique names and IDs of all model elements, we will ensure uniqueness across Industry Solutions through our engineering processes. Naturally there will be logically overlayering conflicts for certain elements; but as the Industry Solutions by nature are verticals we anticipate very few of these. These conflicts will need to be resolved; one way is to reclaim one of the SLx layers as an adaptation layer. More information on this will be available as the Industry Solutions become available.

Why not just support an unlimited numbers of layers?

Frequent feedback we get is to add more layers; and open them up for consumption by the partners. And heck, why we are at it why not have an unlimited number of layers?

Currently; there is an upper limit on the number of layers the kernel can support. This number is 16. The technical explanation has to do with referencing of the elements in the model. Each model element is stored in a record in the AOD file. The RecId for model elements is a 32 bit integer. 4 of these bits denote the layer; the remaining 28 bits are used to calculate the offset into the AOD file where the record is located. In version 3.0 (and previously) the block size was 1 byte. This basically mean the maximum size of an AOD file is about 256MB (2^28). In version 4.0 we moved this limit by denoting one of the 28 bits to control the block size. When the bit is not set, the 27 bits is the direct offset in to the file. When the bit is set, a block size of 48 bytes is used to calculate the offset in the file. This enables AOD files with sizes up to about 6.5 GB (2^27 * 48), while enabling binary backwards compatibility with 3.0 AOD files (with sizes less than 128MB (2^27)).

If we decide to use one bit more to denote the layer (giving us 32 layers); it means we are only backwards compatible with AOD files with sizes less than 64MB (2^26). As that is not acceptable; tools to align the contents in AOD files would be needed. For 6.0 we are investigating options to tear down these limitations once and for all.