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:
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:
- When
you select Import project a dialog box opens asking you to select the location of the .AXPP file
- Once
you have selected them .AXPP file at the bottom of the dialog box there is
a details section.
- In
the details section, you can see all the objects to be imported
- When
viewing the objects, right click on one of them and choose the compare
option to bring up the compare window.
Comments
Post a Comment