From staging we can then use a model store move to LIVE.AOT Application Object Tree. No real harm done since it was only in the TEST environment, but I wonder if there is a way to correct id conflicts?Īs I see it now, we are supposed to transfer functionalities with xpo's from DEV to TEST and to a seperate "staging" environment where we collect all stuff that needs to be transfered to LIVE. After altering some things in SQLDictionary I managed to synchronize again, but I lost all the data in the newly created table fields. I had to use the -idconflict "overwrite" parameter, but as a result I could not synchronize some tables anymore.
#Morphx and the application object tree how to#
Very interesting post on how to prevent id discrepancier! But others wondered too: how to resolve those discrepancies once you have got them?Īs soon as you have used an xpo to transfer a table from one environment (DEV) to another (TEST), it seems impossible to update the TEST environment afterwards using a model store transfer. So, let’s take a look at how the deployment process should be (source: ) Otherwise, we open the door to inconsistency between environments. 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. 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. 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. 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. The following table shows a comparison between these methods (source: ) 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. (NOTE: This file is the main vehicle of metadata deployment in AX 2012) Model file (.axmodel): This is a model that has been exported from a model store. The file is used for moving consistent metadata between environments with minimum downtime. The file includes all metadata, compiled artifacts, CIL code, and security artifacts. Model store file (.axmodelstore): A complete model store that has been exported from the database. (NOTE: Everything element that exists in the AOT is considered metadata) Metadata: Information about the properties or structure of data in the Application Object Tree (AOT) that is not part of the data values.
(NOTE: The model store can be compared to the AOD file share in AX 2009) Model Store: A collection of tables in the AX 2012 database that contains the application metadata. To start, I would like to share some definitions that we are going to be using in this post (source: )Īpplication 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) In this post I would like to recommend moving customizations by exporting the entire model store file between AX 2012 environments. There is a good reason for this as many people seem confused about the model store file, and how can it be used to move metadata between two AX 2012 environments. I have been getting lots of emails with questions about deploying customizations between two Microsoft Dynamics AX 2012 environments. In this post, I would like to focus on deployment strategies in AX 2012. I hope everyone is having a good week and that you are ready for another article about AX.
0 kommentar(er)
