Today we will highlight an important architectural change in Dynamics AX 365. In AX 2012, the only option we had was over-layering for any sort of customization/modification in the out of box functionality. We had models/projects as set of elements, as the part of a given layer. Each layer can have one or more models/projects. Models can be exported to files that have the .axmodel extension and projects can be exported to xpo file. In Ax 2012, models files and XPO's are used for deployment purpose.
How do we customize or modify any element in DAX365?
In DAX365, we have same elements reside in Application Explorer and these elements are objects such as tables, forms and classes, menu items etc. Customization of any object is done once it is added into a project and a project is linked or associated with a model.
Model:
Unlike AX2012, In DAX365, creating a model is mandatory thing for any sort of customization. A particular model can contain multiple Visual Studio projects. Therefore you can say it is a collection of projects and a single project can have all or subset of elements from originating model. However, association of a project is only with a single model. It is basically a unit of development/customization. Metadata for models is stored locally on an XML file called a descriptor XML.
Package:
As it is already mentioned that previously in AX 2012, we used XPO's and model as deployment unit. However in DAX365, we have packages for deployment purpose. A package may contain one or more models. In addition to elements of the model, this also includes model metadata which is the description data that define the properties and behavior of the model. Also a package can be exported to a file which can then be deployed into a staging or production environment. In other words, you can say package is an independent set of layers and models. It's also a set of folders that consists of XML files representing the elements in the system. In this way, a package can be viewed as a mini model store. Physically package translates directly to unit of compilation which is an assembly or DLL file. Packages can reference other packages that is similar to how .NET assemblies can reference each other.
Packages References:
Referencing a packages is useful, when it is required to reuse a functionality that exists in to another package. In this way, one or more packages can be combined to create a deployable package. And lastly, XML files are stored in the model directory that sit inside the package directory.
Layers:
Layers are the traditional AX concept but in D365, there is a new process where we extend layers as shown below.
Also when you create your model, you specify which layer the model is going to live in. However the importance of layer is quite minimal for instance, you are not required to provide a key for your model to live in that layer. Previously layers were single stack of code that over-layered upon each other. This new process uses layers but they are located in independent stacks.
This was only an architectural overview of Dynamics AX 365, I would further elaborate how do we customize the elements with some examples.
Go through links for further explanation and understanding and share your feedback on the post in comments section.
Thanks for sharing information. Nice blog
ReplyDeleteMicrosoft Dynamics AX Technical Training
D365 Ax Technical online training