I am sure that we all are excited about AX 7.0. I have traveled a long way with AX. My journey began with AX 4.0. At that time, we were totally dependent on X++ and MorphX. Now the situation has changed. Microsoft already made our lives very easy with the new development interface. The biggest advantage being is to play with services. Handshaking between two applications is now possible and you can create your own .NET based application and incorporate it into your rich AX application.
Recently I started exploring AX 7.0. Today I am going to share some of the key excitements I felt related to the AX7.0 within this very small span. Let’s discuss a few areas of AX 7.0 deployment which I found interesting.
In AX 2012 Microsoft introduced a great concept called Model. Model is basically a container for metadata elements. Metadata in AX is basically the objects, like class, form, labels etc. You can import and export a Model very easily. Model is widely used in AX world and especially by ISVs.
In AX 7.0 there is no change in the concept of Model. In AX 7.0 a new deployment concept has been introduced by Microsoft was known as Package.
AX 7.0 key deployment concepts:
Project - simple Visual Studio project that stores AOT elements. A Project always belongs to a particular Model. AX 7 Projects are smaller than AX 7.0 Models in size. Therefore, Projects can be moved easily between development environments. A complete Model compilation is not needed for a simple development activity.
Model is a group of elements (metadata and source files) that typically constitute a distributable software solution (including customization of an existing solution). For example, an Inventory module, Accounts Receivable module with tax and shipping customization.
Package is simply a collection of compiled binary versions of models that can be deployed on the cloud. A package can be created in Visual Studio. Single or multiple AX 7 packages can be incorporated into a big deployment package. Mainly used for a big deployment, like moving an environment from staging to test and then to production cloud.
Packages are folders located in the model store folder of the AX 7.0. Typically the default model store folder is “c:\packages\”. Model folders are sub-folders in their package folder. Every sub-folder represents an element type: a table, a form, an EDT etc. For example, all forms in a model belong to the sub-folder Ax Form.
A sales tax model folder belongs to the Sales Tax add-on package folder.
A sales tax model folder belongs to the Sales Tax add-on package folder.
Let us discuss a scenario over here. In an implementation, there are four ISV add-ons along with some additional customization involved.
Model 1: contains project 1 and project 2.
Project 1 contains all customization related to HR (ISV).
Project 2 contains all customization related to Finance.
Model 2: contains Project 3 that is related to an ISV for sales tax for Accounts Receivable and Project Accounting.
Package 1: model 1 + model 2. A package is basically an association of assembly and associated runtime files.
Model 3: contains two projects related to customization of inventory and CRM module.
Project 3 contains a bunch of custom services related to Microsoft Dynamics CRM real-time integration (ISV).
Project 4 contains customization related to inventory.
Package 2: contains model 3.
There is a dependency of Package 2 on Package 1. In that way, you can deploy multiple packages to Azure establishing a dependency.
