D365 Basics (Architeture, Models, Packages, Files)


Models Projects and Packages in D365

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 a 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 a 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 the originating model. However, the 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 everyone already knows that previously in AX 2012, we used XPO's and model as the 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 the 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 a unit of compilation which is an assembly or DLL file. Packages can reference other packages that are similar to how .NET assemblies can reference each other.

Key Points for package:
  • It includes all of the models, binaries and additional pieces needed to deploy code.
  • Similar concept to an AX2012 model store or in VS a solution.
  • You can have multiple packages per installation.
  • AX ships with several packages including :
     Application Suite: This is the package containing most of the application code and is the most likely to be overridden
    Application Suite Form Adaptor
             Application Foundation
             Application Foundation Form Adaptor
             Application Platform
             Application Platform Form Adaptor


Packages References:

Referencing packages is useful when it is required to reuse functionality that exists into 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 sits inside the package directory.

AXPP Files

Files ending with AXPP is the replacement for XPO files.

Import and Export Projects in D365

In AX2012 we use the .XPO files to move the projects from one environment to another but in D365 we don't have the concept .XPO, everything is now .AXPP was similar to .Xpo.

1. In the Solution Explorer, right-click on a project and choose Export Project <ProjectName>
2. The project gets saved as a file with an extension of .axpp
  • The model created is saved in the.AXPP file
  • The model contains the layer info
  • The .AXPP file cannot be read with notepad
To import the project into the D365 we have to do this using the VS. The .AXPP the file contains the Project with modes.
  • Open the VS
  • Go to DynamicsAX menu and choose the import option
  • Choose the .AXPP that you want to import
  • The project is created in the model (and layer) and saved in the .AXPP file
  • If the model doesn't exist in the imported environment, it will be generated.
In AX2012 when you want to import the .XPO file we compare the .XPO with the existing layer changes in the current environment. A similar thing we can do in the D365 you can do a compare between the contents of the .AXPP file and the model existing in the environment.

Steps to compare:
  1. When you select Import project a dialog box opens asking you to select the location of the .AXPP file
  2. Once you have selected them .AXPP file at the bottom of the dialog box there is a details section.
  3. In the details section, you can see all the objects to be imported
  4. When viewing the objects, right click on one of them and choose the compare option to bring up the compare window.





Comments

Popular posts from this blog

Create New customer address and update customer address using x++ code

Create or Update Product attributes using X++ in D365 F&O

Increasing the EDT string size in D365 F&O