Model Management in AX 2012 & Differences between XPO & Models

Working with Models in AOT

To create a new model

1.       Open the Development Workspace.

2.        Choose Tools > Model management > Create model.

3.       Specify the parameters of the new model. The following table lists the parameters you have to supply values for.

Parameter	Description
Model name	The name that identifies the model.
Model publisher	The name of the organization that is creating the model.
Layer	The layer in which the model is created.
Version	The initial version number for the model. The number must have the form x.x.x.x, with the segments representing the major, minor, build, and revision for the model.
Model description	A description of the contents of the model.
Model display name	The friendly name that is displayed for the model.

4.       Select Set as current model to have the new model become the active model in the Development Environment.

5.       Click OK to create the new model.

To specify the current model

1.       Open the Development Workspace.

2.       Choose Tools > Model management > Change current model.

3.       From the models in the current layer, select the model that you want to be the current model. Any changes you make to AOT resources will be stored in this model.

4.       Click OK. The display name of the current model is displayed in the status bar in the Development Workspace.

To set the default model

1.       Open the Development Workspace.

2.       Choose Tools > Options.

3.       Click Development to display the options for the Development Workspace.

4.       Expand the General group.

5.       Set the Startup model to the model that you want to be active when you start the Development Workspace.

6.       Click Close.

To move AOT elements between models

1.       In the AOT, right-click the element that is in the incorrect model.

2.       Click Move to model.

3.       Select the model that you want to move the element to. You can select models only in the current AOS layer.

4.       Click OK.

To view installed models

1.       Open the Development Workspace.

2.       Choose Tools > Model management > Models installed. The Models installed window opens.

3.       View the details about the models that are installed.

4.       Click Close.

To list model elements

1.       Open the Development Workspace.

2.       Choose Tools > Model management > Models elements. The Model elements window opens. This window lists all elements of the models that are installed for Microsoft Dynamics AX.

Tip

The Page Up and Page Down keys are helpful when you browse this large list.

3.       Click Close.

To display model information in AOT nodes

1.       Open the Development Workspace.

2.       Choose Tools > Options.

3.       Click Development to display the options for the Development Workspace.

4.       Expand the Application object tree group.

5.       Set the Application object model. Choose one of the following values:

·         Show no models

·         Show on all elements

·         Show on elements in current layer only

·         Show on elements in current model only

6.       Click Close.

To create a project from a model

1.       Open the Development Workspace.

2.       Choose Tools > Model management > Create project from model.

3.       Select the model that will be used as the source of the project content.

4.       Supply the name of the new project to be created.

5.       Click OK. The project will be created that has the elements from the model.

Resolve Conflicts after model import

When you import a model into the model store, the resources in the model may have conflicts with resources in other models that are already part of that layer. If you use thepush option when importing the model, the conflicting resources will be put into a new conflict model that is located in the patch layer for the current layer in the AOS. This new model will have a name that indicates it contains resources that have caused a conflict. For example the model named Facility Management (Conflict 1) contains the resources that caused a conflict when the Facility Management model was being imported.

Often, it is a developer responsibility to help resolve conflicts that occur when a model is imported. Use the following procedure as a general guideline to help you through this process.

To resolve conflicts after importing a model

1.       Determine whether any conflicts occurred during the model import process.

·         If you imported a model from the command line, the results returned from the command will indicate whether conflicts occurred during the import process.

·         If you do not know the results of the import process, use the Models installed command as described in How to: View Model Information to view the list of models that are installed. If you see any conflict models in a patch layer, they will contain the resources that caused the conflict.

2.       Retrieve the list of resources that caused conflicts. Use the view command to see the list of resources in the conflict model. These are the conflicts that you have to resolve. For detailed information about how to list resources in a model, see How to: View and Verify Contents of a Model. For example, the following command uses axutil.exe to list resources in the Facility Management (Conflict 1) model:

axutil.exe view /model:"Facility Management (Conflict 1)" /verbose

3.       In the AOT, select a resource that has a conflict. Right-click the resource and choose Compare. In the Comparison window, click Compare to see the differences between the resource in the patch layer and the resource in the main layer.

4.       Resolve the conflict. There are many ways to resolve the conflict, depending on the resource type and the actual conflict. Some of the ways to resolve the conflict include the following:

·         Use the information and the available actions from the Comparison window to merge changes from the conflict model into an existing layer.

·         Make a change in the resource in an existing model in the current layer. For example, if two different models in the layer have modified the same resource, you could consider creating a new “shared” model in the layer that contains a single version of the resource that can be used by both of the other models.

·         Switch to the patch layer and modify the resource there. In some cases, this is the easiest way to resolve the conflict.

Tip

You can switch to the patch layer by creating a new configuration with the Microsoft Dynamics AX 2012 Configuration tool. You can also switch to a specific patch layer by using the following command to start Microsoft Dynamics AX: Ax32.exe –AOL=USP

5.       Repeat the conflict resolution process for each resource in the conflict model.

After you have resolved all of the conflicts, consider removing the conflict model from the patch layer. That way, somebody looking at the system will not assume that there are model conflicts that have to been resolved. If you are leaving a resource in the patch layer, move the resource out of the conflict model into another model in the patch layer. Then delete the conflict model.

Difference between XPO Files, Model Files & Model Store Files

A model is a set of elements in a given layer. Each layer consists of one or more models. Each layer contains one system-generated model that is specific to that layer. Every element in a layer belongs to only one model. In other words, no element can belong to two models in the same layer, and every element must belong to a model.

A model is permanently associated with the layer that is created in. If you need to move one of your models from one layer to another, you must create a project from the model in the AOT, export the project as an xpo file, create a target model in the desired layer, delete the original model to avoid having to resolve layer conflicts, and import the xpo file to the target model. If you are moving elements between models in the same layer, you can use the Move to model command in the AOT.

Models are stored in the model store. The model store is the part of the Microsoft Dynamics AX database in which all application elements for Microsoft Dynamics AX are stored. Customizations are also stored in the model store. The model store replaces the Application Object Data (AOD) files that were used in earlier versions of Microsoft Dynamics AX. Models that have been installed in the model store are used at run time.

Models can be exported to files that have the .axmodel extension. These files are called model files. Model files are deployment artifacts. Model files can be signed with strong name signing and Microsoft Authenticode signing.

Models and label files

In Microsoft Dynamics AX 2012, label files, or ALD files, are part of models. A label file must be added to a model before the model can be installed. After a model has been installed, ALD files are pulled from the model store to the local of Application Object Server (AOS) instance when the AOS is started. When the AOS is shut down, the ALD files are pushed back to the model store.

ALD files from earlier versions of Microsoft Dynamics AX are not part of a model file. However, you can import these files into the model store from the Label Files section of the Application Object Tree (AOT). Use the Create from file shortcut command.

How models improve the installation and maintenance of side-by-side customizations

In earlier versions of Microsoft Dynamics AX, multiple partner solutions could not exist side by side in the same layer. However, models now enable side-by-side customizations. Additionally, the following improvements help you work with side-by-side customizations:

·         The development environment for Microsoft Dynamics AX lets you create a project for each model that is installed. Therefore, you can quickly see all the installed customizations in a layer for a given model.

·         When you import a model, elements in the model that you are importing may conflict with another model in the same layer. You can now create a conflict model in the patch layer that is associated with the layer that you are working in. You can then resolve the conflicts in the conflict model. In earlier versions, no warnings about conflicts were displayed. Instead, elements were just replaced.

·         You can now leave the rest of the layer intact when you uninstall a model. In earlier versions, if you wanted to uninstall customizations, you had to either remove the customizations manually from the AOT or remove the layer.

How models improve the installation and maintenance of side-by-side customizations

In earlier versions of Microsoft Dynamics AX, multiple partner solutions could not exist side by side in the same layer. However, models now enable side-by-side customizations. Additionally, the following improvements help you work with side-by-side customizations:

·         The development environment for Microsoft Dynamics AX lets you create a project for each model that is installed. Therefore, you can quickly see all the installed customizations in a layer for a given model.

·         When you import a model, elements in the model that you are importing may conflict with another model in the same layer. You can now create a conflict model in the patch layer that is associated with the layer that you are working in. You can then resolve the conflicts in the conflict model. In earlier versions, no warnings about conflicts were displayed. Instead, elements were just replaced.

·         You can now leave the rest of the layer intact when you uninstall a model. In earlier versions, if you wanted to uninstall customizations, you had to either remove the customizations manually from the AOT or remove the layer.

Installing metadata

---

Metadata can be installed in various ways. The following table describes each installation method that is available.

	XPO files	Model files	Model store files
Installation tool	MorphX	AXUtil.exe or Windows PowerShell cmdlets	AXUtil.exe or Windows PowerShell cmdlets
The files can be uninstalled.	No	Yes	No
The files can be signed.	No	Yes	No
Microsoft Dynamics AX element IDs are preserved.	Yes, because there are no IDs in XPO files	Yes, if IDs have already been assigned	Yes
Compilation is required after installation.	Yes	Yes	No
CIL generation is required after installation.	Yes	Yes	No

The following table describes the scenarios in which we recommend you use each installation method.

Scenario	Recommended installation method
Distributing a solution to customers	Model files
Deploying a solution in a development or test environment	Model files or XPO files
Deploying a solution to a production environment	Model store files

Regards,

Kuldeep Singh