Application Layer: A single layer of AX 2012 application that exists within a model store (NOTE: The elements in higher layers will override elements in lower layers)
Model Store: A collection of tables in the AX 2012 database that contains the application metadata. (NOTE: The model store can be compared to the AOD file share in AX 2009)
Metadata: Information about the properties or structure of data in the Application Object Tree (AOT) that is not part of the data values. (NOTE: Everything element that exists in the AOT is considered metadata)
Model store file (.axmodelstore): A complete model store that has been exported from the database. The file includes all metadata, compiled artifacts, CIL code, and security artifacts. The file is used for moving consistent metadata between environments with minimum downtime.
Model file (.axmodel): This is a model that has been exported from a model store. (NOTE: This file is the main vehicle of metadata deployment in AX 2012)
Moving right along , when deploying metadata between AX 2012 environments, we can do it using a number of different methods that range from importing/exporting XPO files to moving a whole model store file at once.
The following table shows a comparison between these methods (source:www.microsoft.com)
This might vary from project to project, but I believe that we should adopt a single and concise method that we can apply in our projects to quantify the results over a period of time, and to minimize downtime.
In addition, I think that a crucial step to achieve a consistent deployment methodology is to understand that the environments we are moving data from/to need to have the same metadata structure. For example, in the last six months I have learned that if a customer already has a production AX 2012 instance running, the Test and Staging environments can and should be a replica of it to avoid conflicts on ID’s and model store metadata.
We also need to ensure that any customizations we do, must first be applied to the source environment, then have them thoroughly tested, and then move them to the production environment via our preferable method. Otherwise, we open the door to inconsistency between environments.
So, let’s take a look at how the deployment process should be (source:www.microsoft.com)
Microsoft has outlined a list of common mistakes that arise when importing a single model into a production environment.
1-We start with a customization that we want to move into the target environment.
2-Then we import the model that contains our customizations. Because this is a new object that does not exist in the target system (Stage/Production), AX might give the object an ID that is different from the ID in the source system.
3-Then, someone uses he system and adds transaction records that reference the AXID.
4-Let’s say that the next day we make another customization and want to deploy the entire model store for minimal downtime (which was a different approach from step 2). To do this, we export the entire model store, which includes the IDs.
As you can see, this inconsistency will create conflicts because the ID’s as the two instances have different ID's.
Now, the idea is to choose one methodology and stick with it. However,Microsoft suggests importing the entire model store file from the beginning, so we don’t run into ID conflicts in future deployments. It is essential that the target database (especially in a production environment) is initialized from an exported source database and not individual model files.
The following sequence shows the correct way to move customizations between environments to avoid conflicts.
1-We start by creating a blank AX DB by using Setup. (This will contain the Foundation SYS model).
2-We initialize the model store by importing the model store file from the source to the target system.
3-When this happens, we can start adding data to the target system, and at the same time, customizations can be made to the source system.
4-Now, when we are ready to re-deploy new customizations, the entire model store is once again exported to minimize system downtime and to avoid ID’s conflicts.
Model Store: A collection of tables in the AX 2012 database that contains the application metadata. (NOTE: The model store can be compared to the AOD file share in AX 2009)
Metadata: Information about the properties or structure of data in the Application Object Tree (AOT) that is not part of the data values. (NOTE: Everything element that exists in the AOT is considered metadata)
Model store file (.axmodelstore): A complete model store that has been exported from the database. The file includes all metadata, compiled artifacts, CIL code, and security artifacts. The file is used for moving consistent metadata between environments with minimum downtime.
Model file (.axmodel): This is a model that has been exported from a model store. (NOTE: This file is the main vehicle of metadata deployment in AX 2012)
Moving right along , when deploying metadata between AX 2012 environments, we can do it using a number of different methods that range from importing/exporting XPO files to moving a whole model store file at once.
The following table shows a comparison between these methods (source:www.microsoft.com)
This might vary from project to project, but I believe that we should adopt a single and concise method that we can apply in our projects to quantify the results over a period of time, and to minimize downtime.
In addition, I think that a crucial step to achieve a consistent deployment methodology is to understand that the environments we are moving data from/to need to have the same metadata structure. For example, in the last six months I have learned that if a customer already has a production AX 2012 instance running, the Test and Staging environments can and should be a replica of it to avoid conflicts on ID’s and model store metadata.
We also need to ensure that any customizations we do, must first be applied to the source environment, then have them thoroughly tested, and then move them to the production environment via our preferable method. Otherwise, we open the door to inconsistency between environments.
So, let’s take a look at how the deployment process should be (source:www.microsoft.com)
Microsoft has outlined a list of common mistakes that arise when importing a single model into a production environment.
1-We start with a customization that we want to move into the target environment.
2-Then we import the model that contains our customizations. Because this is a new object that does not exist in the target system (Stage/Production), AX might give the object an ID that is different from the ID in the source system.
3-Then, someone uses he system and adds transaction records that reference the AXID.
4-Let’s say that the next day we make another customization and want to deploy the entire model store for minimal downtime (which was a different approach from step 2). To do this, we export the entire model store, which includes the IDs.
As you can see, this inconsistency will create conflicts because the ID’s as the two instances have different ID's.
Now, the idea is to choose one methodology and stick with it. However,Microsoft suggests importing the entire model store file from the beginning, so we don’t run into ID conflicts in future deployments. It is essential that the target database (especially in a production environment) is initialized from an exported source database and not individual model files.
The following sequence shows the correct way to move customizations between environments to avoid conflicts.
1-We start by creating a blank AX DB by using Setup. (This will contain the Foundation SYS model).
2-We initialize the model store by importing the model store file from the source to the target system.
3-When this happens, we can start adding data to the target system, and at the same time, customizations can be made to the source system.
4-Now, when we are ready to re-deploy new customizations, the entire model store is once again exported to minimize system downtime and to avoid ID’s conflicts.
