The models required depend on your organization's requirements, and these were discussed in the previous chapter. In this section, we will create the models based on our Fleet Management System, from a customer or end user perspective.
Models should also include your prefix. In this case, we will use the Con prefix for Contoso. We will create our models in the USR layer, as explained later in this section.
ISVs will normally have a base model that contains shared code between all models, and a model per add-on or vertical solution. Some care is required in ensuring that there isn't a circular dependency chain between models; that is, both reference each other's models, requiring the installation to have special instructions.
Following the naming convention discussed in the previous chapter of prefixing elements—an ISV with the Axp prefix and an add-on named Documental—they can name the model AxpDocumental.
If we are a VAR building a solution to customer-specific requirements, we will have three models: one for the actual modifications, another for changes to security, and the third for the labels. For example, if our prefix is Bcl and the customer is Contoso, we will have BclContoso, BclContosoLabels, and BclContosoSecurity.
Creating security in a separate model is not mandatory, but helps when implementing projects with the Sure Step methodology because it allows security to be worked on in separate streams.
If we are a global organization, with separate Dynamics AX installations, we may decide to develop a central application, which is then installed on each site. In this case, we will have three models placed in the CUS layer. For the Contoso example, we have ConGlobalApplication, ConGlobalLabels, and ConGlobalSecurity.
The most common scenario is to host Dynamics AX centrally, therefore having one application. The same three models are required, but this time in the USR layer: ConApplication, ConLabels, and ConSecurity.
It may make sense to place distinct sets of functionality in separate models, and this would certainly help in managing separate development streams. Over time, the models tend to develop cyclic dependencies, which require them to be merged in order to ensure that a complete set of code is deployed.
In our example, we will create a model for a specific functionality—our Fleet Management System—and it will make sense to hold it in a separate stream. However, it would be a particularly bad idea to hold each module's modifications in its own model.
Before we create the models, we must be in the correct layer; the USR layer in this case. The model creation is done by following these steps:
Open the Dynamics AX Client, and open the development environment (Ctrl + D).
From the main menu, go to Tools | Model management | Create model.
Complete the Create model form as shown here:
Field
Description
Model name
This is the name of the model. It can contain spaces, but it is normally the same as the display name.
Model Publisher
Your organization or department.
Layer
The layer the model should be created in. This should be the current layer.
Version
The version of the model. This becomes part of the strong name of the model during signing.
Model description
Long description of the model. It is a good idea to link this to a functional or technical design document.
Leave Set as current model checked and press OK.
An example of a completed Create model form is shown in the following screenshot:
If we have version control enabled for TFS, we will also ask for the Model repository folder. It will suggest, in our example C:\Projects\VCS\AX\6015GettingStarted\<Model folder>. Replace <Model folder> with the model name, as shown in the following screenshot:
Using the preceding instructions as a guide, we will need to create the following models. Usefully, AX will remember the previous information, so we only need to populate Model name and Model display name:
ConFleetManagementConLabelsConFleetManagementSecurity