Wednesday, March 21, 2012

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.
Description: Description: TipTip
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.
Description: Description: TipTip
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.



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