mfp's two cents

...on Dynamics AX Development!
  • mfp's two cents

    AX models - Part 1 - Deploying models

    • 18 Comments

    About a milestone ago I announced SQL AOD. Since then it has been quite quiet on my blog - for two reasons 1) I've been heads down in new features and 2) I've been on paternity leave. Now the completion of M2, the next milestone of AX "6", is within reach and I've returned to my office. This means I can share some more exciting news.

    Since the days of AOD files are numbered we need a new vehicle for deploying metadata elements to an AX installation. To address this need we introduce Models. A model is a containment of metadata elements.

    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 overlayering elements, creating new elements, changing X++ code etc., the resulting elements will automaticaly 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 gives parity with AOD files: We have a file based container that can be xcopy 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.

    This post is a part of a series on models:

    1. Deploying models
    2. Manifest and signing
    3. Multiple models per layer
    4. Working with models inside MorphX

    This posting is provided "AS IS" with no warranties, and confers no rights.

  • mfp's two cents

    AX models - Part 2 - Manifest and signing

    • 1 Comments

    In my first post on AX models I showed that models provide parity functionality with AOD files. Models goes several steps further, and addresses some of the shortcomings of AOD files. Have you ever been in a situation where you had several AOD files, but couldn't quite remember which was which, and where they came from? Models solve this problem by containing a manifest. A manifest contains attribute values describing the model.

    AX models support these manifest attributes:

    Name
    Name of the model.

    Display Name
    Friendly name to be presented in user interfaces.

    Description
    A longer text describing the model.

    Publisher
    Publisher of the model, e.g. “Microsoft Corp.”

    Version Number
    Four part version number, e.g. 1.0.0.0.

    Source Layer
    ID of the layer from which this model was exported and hence target layer during import.

    The manifest can be inspected for models in the model store by using AxUtil:

    AxUtil list /model:"My Model"

    To modify a model's manifest you can use AxUtil:

    AxUtil edit /model:"MyModel" /manifest:Version="2.0.0.0",Publisher="MFP",Description="My first model"

    Now we have a model with a manifest. This mean we can track structured information about the model. The next thing you want to do is to ensure the receivers of your model file can trust the model - or at least be able to judge if the model comes from a trustworthy source. To achieve this you can sign the model. We support two ways of signing a model. Strong name signing and Authenticode signing. Here is a post that explains the details and use scenarios of each. 

    Strong Name Signing 

    When you are importing a strong name signed model; you are guaranteed the model file hasn't been tampered with since it was exported. To strong name sign an model, you need to use the Strong Name Tool: SN.exe to generate a key pair file. When you export your model to an .axmodel file you can specify the key to sign the model with:

    SN -k mykey.snk
    AxUtil export /Model:"My Model" /file:MyStrongNameSignedModel.axmodel /key:mykey.snk

    Authenticode Signing

    If you are a publisher of models, like an ISV that provides models e.g. for download, you should consider authenticode signing your model. If you do, then your customers are guaranteed the file hasn't been tampered with, and that you created the model.

    When you are importing an authenticode signed model; the model's publisher is authenticated. Depending on the certificates, the model is either imported silently (if the publisher is one you trust), or you will be prompted to ensure you trust the publisher. If the model isn't authenticode signed, you will always be prompted (to accept importing a model where the publisher can't be authenticated).

    To authenticode sign a model file you need to export it first using AxUtil. After this you use the SignTool to perform the actual signing.

    Conclusion

    The features around deployment and manageability of models by far exceed what was possible for AOD files. Having this solid foundation enables many new scenarios and drives down TCO. It is also a solid foundation for us to add more capabilities. For example; dependency management between models is high on our list of things to consider next.

    You might have realized this already, an .axmodel file is a managed assembly. This means you can use tools like ILDASM to peek inside it.

    More on models... 

    This post is a part of a series on models:

    1. Deploying models
    2. Manifest and signing
    3. Multiple models per layer
    4. Working with models inside MorphX

     

    This posting is provided "AS IS" with no warranties, and confers no rights.

Page 1 of 1 (2 items)

September, 2009

mfp's two cents

...on Dynamics AX Development!