New features In AX 2012
AX6 sneak preview - SQL AOD (AxSYS.axmodel)
A model is like a developer's layer in which he can keep his modified/new objects and import/export/delete in different AX environments just like we do in layers
Dynamics Ax’s model database is stored in a Microsoft SQL Server database.
The speed is back. Navigating the AOT is suddenly a pleasure again. Meta data heavy operations, like searching, completes an order of magnitude faster. For example; searching all methods on forms for any text completes in 2 seconds
Dynamics AX supports a new file format: ax model-files. (extension: "ax model", example: "AxSYS.axmodel"). These are binary files, and provides the same deployment capabilities as AOD files did - and yet they are less than half size. Using a new tool you can import/export ax model files to/from SQL. You can also import AOD files into SQL.
The compiled source is also stored in the database (as a blob)
The labels are now also stored in SQL. We still support export and import of ALD files to support localization - but at deployment you don't need to worry about ALD files, as the labels are also contained in the .axmodel files
To create a model you use the new command line utility AxUtil:
AxUtil create /model:"My Model" /Layer:USR
This will create a new model with the name "My Model" in the USR layer. This new model can be selected in the AX client configuration utility as the default model. When you start AX the status bar will tell you which model you are currently working in - just next to where the current layer is shown. When you make changes in the AOT, like over layering elements, creating new elements, changing X++ code etc., the resulting elements will automatically be contained in your model.
When you have completed all your changes, then your model is complete. In other words it is time to move the model from your developer box to a production system. In AX2009 you would copy your AOD files - with models you need to export it to a physical file. Again you will use AxUtil:
AxUtil export /model:"My Model" /file:MyModel.axmodel
Now you can copy this file to the production system and import it there:
AxUtil import /file:MyModel.axmodel
You can even uninstall it again - if that is what you want. This is semantically the same as deleting an AOD file in AX2009:
AxUtil delete /model:"My Model"
So far I have described the model capabilities that give parity with AOD files: We have a file based container that can be copy deployed and we can delete models again.
From what I've described so far models aren't much different than layers and AOD files. They are; and provide some highly desirable capabilities - which will be the topic of a near-future post - so stay tuned
Here are a few examples where this could be useful in development scenarios:
• If you deliver more than one solution:
You can have a model for each of the solutions you are working on. This enables you to work on them simultaneously while having visibility into which model you are working on.
• If your solution is getting too big:
You can segment your solution into several models - and have teams/team members work on their own model. The models can be either self-contained or have dependencies to other models. This enables you to clearly define ownership between the models, clearly define the APIs between the models, build the models individually, etc.
• If you write unit test:
You can have a model for your production code and a model for your unit tests. These enable you to easily import all your unit tests, run them, and remove them again from the system.
Apparently we cannot guarantee that models can co-exist in the same layer - so what are the options when two models are in conflict? When you import a model that conflicts with an already imported model, you get three options:
• Push-up (default)
This option creates a new model in layer above containing the conflicting elements. This enables you to log into this layer and resolve the conflicts using the MorphX tools you are used to. Please notice that only the few elements in-conflict will be moved into this model, so the resolutions required are limited, and the original models will co-exist in the model store - but not only in the same layer.
For example; if two models ("Model A" and "Model B") are imported into the BUS layer, then "Model A" is imported without any problems, and "Model B" will be imported into two models: "ModelB" in the BUS layer, and "Model B Conflicts" in the BUP layer.
• Overwrite
This option will overwrite any existing definitions with the definitions in the new model. Any model containing element definitions that get overwritten will be logically grouped with new model. The grouping ensure that an eventual uninstall of a model doesn't leave the system in an in-complete state. This option is primary useful for patches that are accumulative in nature.
For example; If a model "ModelA" containing PatchA is already installed, and a new model "ModelB" containing PatchA+B is being installed then this is the right option. Later; if "ModelB" is being uninstalled, then "ModelA" is also automatically uninstalled.
• Abort
This option aborts the operation and leaves the model store untouched - perhaps you specified the wrong model file, perhaps you want to investigate the models before continuing.
A model is like a developer's layer in which he can keep his modified/new objects and import/export/delete in different AX environments just like we do in layers
Dynamics Ax’s model database is stored in a Microsoft SQL Server database.
The speed is back. Navigating the AOT is suddenly a pleasure again. Meta data heavy operations, like searching, completes an order of magnitude faster. For example; searching all methods on forms for any text completes in 2 seconds
Dynamics AX supports a new file format: ax model-files. (extension: "ax model", example: "AxSYS.axmodel"). These are binary files, and provides the same deployment capabilities as AOD files did - and yet they are less than half size. Using a new tool you can import/export ax model files to/from SQL. You can also import AOD files into SQL.
The compiled source is also stored in the database (as a blob)
The labels are now also stored in SQL. We still support export and import of ALD files to support localization - but at deployment you don't need to worry about ALD files, as the labels are also contained in the .axmodel files
To create a model you use the new command line utility AxUtil:
AxUtil create /model:"My Model" /Layer:USR
This will create a new model with the name "My Model" in the USR layer. This new model can be selected in the AX client configuration utility as the default model. When you start AX the status bar will tell you which model you are currently working in - just next to where the current layer is shown. When you make changes in the AOT, like over layering elements, creating new elements, changing X++ code etc., the resulting elements will automatically be contained in your model.
When you have completed all your changes, then your model is complete. In other words it is time to move the model from your developer box to a production system. In AX2009 you would copy your AOD files - with models you need to export it to a physical file. Again you will use AxUtil:
AxUtil export /model:"My Model" /file:MyModel.axmodel
Now you can copy this file to the production system and import it there:
AxUtil import /file:MyModel.axmodel
You can even uninstall it again - if that is what you want. This is semantically the same as deleting an AOD file in AX2009:
AxUtil delete /model:"My Model"
So far I have described the model capabilities that give parity with AOD files: We have a file based container that can be copy deployed and we can delete models again.
From what I've described so far models aren't much different than layers and AOD files. They are; and provide some highly desirable capabilities - which will be the topic of a near-future post - so stay tuned
Here are a few examples where this could be useful in development scenarios:
• If you deliver more than one solution:
You can have a model for each of the solutions you are working on. This enables you to work on them simultaneously while having visibility into which model you are working on.
• If your solution is getting too big:
You can segment your solution into several models - and have teams/team members work on their own model. The models can be either self-contained or have dependencies to other models. This enables you to clearly define ownership between the models, clearly define the APIs between the models, build the models individually, etc.
• If you write unit test:
You can have a model for your production code and a model for your unit tests. These enable you to easily import all your unit tests, run them, and remove them again from the system.
Apparently we cannot guarantee that models can co-exist in the same layer - so what are the options when two models are in conflict? When you import a model that conflicts with an already imported model, you get three options:
• Push-up (default)
This option creates a new model in layer above containing the conflicting elements. This enables you to log into this layer and resolve the conflicts using the MorphX tools you are used to. Please notice that only the few elements in-conflict will be moved into this model, so the resolutions required are limited, and the original models will co-exist in the model store - but not only in the same layer.
For example; if two models ("Model A" and "Model B") are imported into the BUS layer, then "Model A" is imported without any problems, and "Model B" will be imported into two models: "ModelB" in the BUS layer, and "Model B Conflicts" in the BUP layer.
• Overwrite
This option will overwrite any existing definitions with the definitions in the new model. Any model containing element definitions that get overwritten will be logically grouped with new model. The grouping ensure that an eventual uninstall of a model doesn't leave the system in an in-complete state. This option is primary useful for patches that are accumulative in nature.
For example; If a model "ModelA" containing PatchA is already installed, and a new model "ModelB" containing PatchA+B is being installed then this is the right option. Later; if "ModelB" is being uninstalled, then "ModelA" is also automatically uninstalled.
• Abort
This option aborts the operation and leaves the model store untouched - perhaps you specified the wrong model file, perhaps you want to investigate the models before continuing.
thanks, very useful! now, i`m trying to get the difference between models and model stores approaches in deployment
ReplyDelete