In this chapter, we will cover the following topics:
- Transferring an XPO
- Installing an AX model
- Managing conflicts
- Uninstalling a model
- Exporting or importing a model store
- Refreshing an environment from live
- Applying a hotfix from Microsoft
- Clearing application user caches and usage data
Models are created by grouping application elements within a specific AOT layer. They could be new elements (a new field on a table) or modified from a lower layer (for example, modifying a method on a class in order to extend or change it).
Some examples of models are as follows:
- ISV-supplied document-routing add-on
- Partner supplied modifications for your implementation
Note
Refer to Appendix, Further Reading for further information on Models.
The layer files (AOD files) have been moved into the Model Store database in AX 2012, so we can no longer move an individual layer. From the R2 version, the Model Store is stored in a separate database suffixed with _Model.
Prior to models, code was transferred either into layers or as an export of a project (a group of objects created or modified to provide a piece of functionality). This is referred to as an XPO as it is the extension of the file it creates. You can also export individual AOT elements such as forms, tables, and so on in this way.
Transferring a model store is similar to transferring a layer prior to AX 2012, except that all the layers are contained in the model store and can't be sent individually. As these files are very large, this method locks you into strict and restrictive cycles such as development of UAT on code completion and UAT to live when the whole layer passed testing.
XPOs have to be exported and imported while in the desired layer. They don't have any knowledge of the layer or model that they were exported from. So this means that the Partner-developed functionality in the VAR layer has to be transferred by the Partner, as only the Partner has the access code for the VAR layer.
XPOs have been described by many as obsolete by comparing models to DLLs and XPOs to source code (the C# code in a .cs file). The argument follows that in a classic Windows development, you would not send a C# file; you would send a DLL.
This is not strictly true; XPOs still have a place and can be more appropriate than transferring model files as stated in the following points:
- If you are the author of the code and you are moving from your layer and model in one environment to the same layer and model in the target environment, importing and exporting an XPO will be faster and less disruptive.
- The model may contain a functionality that is not code-complete, and this update (for example, a fix to a report) cannot wait for the whole model to be ready for release.
- You wish to move code from one layer to another; models can only be installed into their original layer.
- You need to compare the code while importing the code, in order to merge the code as you import it.
What is important here is that a development and deployment procedure is adhered to by all parties. The advanced technology in AX should be used as intended, not just because it is available.