Friday, July 20, 2012

Deploying Customizations between AX 2012 Environments



Hi there!

I hope everyone is having a good week and that you are ready for another article about AX. In this post, I would like to focus on deployment strategies in AX 2012. I have been getting lots of emails with questions about deploying customizations between two Microsoft Dynamics 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.

In this post I would like to recommend moving customizations by exporting the entire model store file between AX 2012 environments.

To start, I would like to share some definitions that we are going to be using in this post (source: www.microsoft.com)

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)



XPO Files
Model Files
Model Store Files
Imported/exported by using…
MorphX

AXUtil.exe or Windows PowerShell cmdlets
AXUtil.exe or Windows PowerShell cmdlets
Can be uninstalled?
No
Yes
No
Can be signed?
No
Yes
No
Microsoft Dynamics AX Object IDs from source environment preserved?
No



No



Yes



Compile required?
Yes
Yes
No
IL Generation required?
Yes

Yes

No


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.




In conclusion, every implementation should include several separate environments to consistently control what code ends up running on the customer’s production system. There are many methodologies available to us, but some of these can create ID’s conflicts when the system assigns ID’s. To avoid this problem, we should move customizations between environments using the model store file.

That’s all for now, and I hope that this posts clarifies some of the doubts about deploying customizations between environments in AX 2012.

Also, keep checking my blog as I will post a very interesting article on how to setup Items for AX 2012 Retail.


21 comments:

  1. Great post!
    Now I am more concerns about how to resolve if you have id discrepancy in both environments? To minimize the impact of production system.

    ReplyDelete
    Replies
    1. Hi! ... hey thanks for reading my blog and I'm glad that you found this article interesting. If you don't mind the question, What kind of discrepancies are you experiencing? Is it metadata? This is one of the biggest issues that I'm hearing in the past few months and it is a problem as if you have a running AX 2012 instance running and your stage and test are different, then you should make them as per production specs (at least from a model store point of view)

      It would be great if you could share what kind of issues you are experiencing right now.

      Delete
    2. Thanks for replied. I understand your point here and that is what I have recommended to my client but it always take great effort to do refresh dev or test environments exercises. What i expecting was simple tool or program to rename some of the existing id values and make everything synchronize as it suppose.to be...

      Delete
  2. I know that Microsoft says it's best practices to move models, but it you have multiple smaller customizations (e.g. reports) that are in development and you need to move these frequently from DEV to TEST, then this becomes quite the operation. You can still preserve object IDs by using XPO's. Do you know what Microsoft's argument is against using XPO's ?

    ReplyDelete
    Replies
    1. Hi Rob, Microsoft does not have an argument against xpo deployments. I think you said it right, you can still maintain ID values when moving modifications through XPO. However, and this is my personal opinion, xpos bring many challenges when moving modifications. One of them is moving labels files, the other is moving many different versions of many objects at once. I'm sure that you have experienced these at least once :D

      Anyway, Microsoft recommends moving the model store file as this guarantees you a successful deployment. As for your problem, do you have a deployment schedule? Perhaps by having a deployment schedule you can group your customizations into one model store file per week, instead of doing itmany times a day/week.

      Delete
    2. Another thing to consider is that XPO's do no care about models. As far as I know, it is unaware of models. So you would have to keep track on what model you are exporting from in the source system, and make sure you import to the same model in the target system. For smaller customization it might be ok, but more complex XPOs could suffer from having changes from multiple models.

      Delete
    3. Thanks for sharing, Skaue. Yes, we would have that problem on a big implementation, and that's why the model route is much safer in the long term.

      Delete
  3. Thankfulness to my father who informed me on the topic
    of this website, this webpage is in fact remarkable.
    Feel free to visit my weblog - nur

    ReplyDelete
  4. Very interesting post on how to prevent id discrepancier! But others wondered too: how to resolve those discrepancies once you have got them?
    As 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.

    I had to use the -idconflict "overwrite" parameter, but as a result I could not synchronize some tables anymore. After altering some things in SQLDictionary I managed to synchronize again, but I lost all the data in the newly created table fields.

    No real harm done since it was only in the TEST environment, but I wonder if there is a way to correct id conflicts?

    As 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. From staging we can then use a model store move to LIVE. But what if the customer wants a copy of the LIVE on his TEST environment?

    ReplyDelete
    Replies
    1. Hi,

      Great question!

      Then I would suggest considering restoring both the model and AXdb from the prod environment to the test one. It will work the same way as in 2009 when you would just take the application files (aod and ald files between environments along with the DB).

      I hope this answers your question.

      Delete
    2. At least one of them... ;-)
      Still hoping to fix id conflicts one way or another!

      Delete
    3. So based on what you are telling me. and assuming that you want to move stuff from Dev to Test as per your comment

      "As 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."

      I would just restore the AXDB and the AXDevBaseline to Test. This should get rid of any conflict ID. The drawback, however, is that if you had any environment specific configurations, you will have to change them.

      Of course it depends on where you are in your Test env and if this change will impact deliverables.

      I hope this helps!

      Delete
  5. Ok. You rock my world! Great summary, and yet another great post on your blog. Keep it up!

    (yea, I mean it - it's not generic spam - lol)

    ReplyDelete
  6. Hi,
    Iam going to prepare production environment, from test environment i have to delete all transactions and have to make Main Accounts values to zero. I am facing challenge making Main account values to zero, please guide me how to make Accounts value to zero. Even after deleting all the transactions and data still accounts are holding values. Please guide.

    ReplyDelete
    Replies
    1. Hi there!

      Try deleting all transactional data. You have some transactions somewhere that are linked to those main accounts.

      If you write code and/or anyone who does, check the following and just create a job in AX and execute it ***See note before clicking***

      https://community.dynamics.com/product/ax/axtechnical/b/mukeshhirwani_dynamicsax/archive/2012/09/19/delete-transactional-data-ax-2012.aspx

      ***NOTE: this code WILL delete all your transactional data, use at your own risk.

      Delete
  7. Can anyone tell me whether Pre live is needed a production environment
    if so may i know the valid the reason for that????

    ReplyDelete
  8. Can anyone tell me prelive or Staging environment is need in Ax 2012 implementation
    If so may i know the reason for that..

    ReplyDelete

Thank you for your thoughts. Your comment will appear in my blog shortly after review.

Have a great day!