mfp's two cents

AX models - Part 4 - Working with models inside MorphX

This is my final post on models in AX for Milestone 2 (M2). Since my last post (link) the Dynamics AX organization has exited M2 - this means that all planed M2 features are implemented, tested, and all exit criteria passed. The exit criteria ensure quality by enforcing a required bar for a number of metrices across all teams, such as code coverage, no severe bugs remaining, etc. All this is very interesting, but not what I want to talk about today.

When you start AX you can specify a current model. There are several ways of specifying the current model, including a command line option to AX32.exe, This aligns very well with how you specify the current layer when starting AX. Just like the current layer, the current model is shown in the status bar of the MorphX workspace:

Unlike the current layer, you can change the current model without restarting AX. However, you can only change to a model that exists in the current layer. You change the current model by clicking the model in the status bar - this gives the same experience as when changing the current company accounts.

When you create new elements (or overlayer existing elements) in the AOT the resulting new element is created in the current model. In the AOT you can see the model for each element. It is displayed next to the layer indicator. Just like the layer indicator, you can in Tools | Options specify when to show the model indicator. Here is a screenshot where the model indicator is shown for all elements:

Notice, that the model indicator only shows the model for the top-most element. i.e. if an element exists in both SYS and USR layer, only the model for the USR element is shown.

You can also move an element to a different model. You do this by selecting "Move to model" from the context menu in the AOT. It will bring up a small dialog, where you can pick the available models in the current layer.

Wrapping up

This concludes my introduction of models. In AX6 you will be working with models in many scenarios. Here are the highligths:

• Models provide a better deployment vehicle than AOD files did in previous versions, primarily because they can be signed and have a manifest. 
• Models enable side-by-side installation of models from different sources in the same layer.
• Models enable you to segment your solution into smaller and more managable models.
• Models are seamlessly tied into the MorphX development experience.

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

AX models - Part 3 - Multiple models per layer

In my first two posts on models in AX (Part 1 and Part 2) I covered the deployment specific behaviors of .axmodel files - it should be apparent we introduced .axmodel files as a deployment replacement for AOD files. In the process we added some nice capabilities like a manifest and signing. The real benefit of models, and the ultimate reason we are adding this level of abstraction is because:

Let us examine this statement. In AX2009 a layer is the confinement unit of model elements. The layer is the unit of which you can export, deploy and delete model elements. (Here I'm deliberately ignoring the capabilities provided by XPO files, as these are suitable for development purposes only, and not deployment.) In AX6 this limitation has been removed, that means you can segment your layer into as many models as you like.

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. This enables you to easily import all your unit tests, run them, and remove them again from the system.
   

Let's examine the statement a bit deeper. There are two ways of getting a model: Either you create one on your own, or you receive it from someone else. If you can have as many models as you want per layer, it also means:

You can deploy models from several sources into the same layer.

Here is an example: You are a customer and would like to install two ISV solutions that both are available in the BUS layer. In AX2009 you would have a tough choice to make: Either you picked your favorite solution and learned to live without the other one, or you invested in having the two solutions merged into one layer. This merge is technical challenging, and a costly affair once updates to either solution are being released. In AX6, however, you download the two models, and use AxUtil to import them. When a new version of either model is released, you simply use AxUtil to update the model.

The catch

This all sounds too good to be true, what is the downside? There is one limitation to what a model can contain:

This means that two models containing a definition of the same element cannot be installed in the same layer. For example; if the two models both contain a class named: "MyClass" they will not be able to install side-by-side in the same layer. Model elements have two alternate keys, they are: [Type, Parent, ID] and [Type, Parent, Name]. Each layer can only contain elements that can uniquely be identified via the two alternate keys. In less technical terms, this means that two elements of same type under same parent (or without a parent) cannot co-exist if they have same name or same ID. For example: A table cannot have two fields with same name, or two fields with same ID. Another example: You cannot have two display menu items with the same name.

There are three ways you can be hit by this limitation:

1. You create an element, and give it a name that accidentally also has been chosen for another element by someone else in their model. A good way to avoid this to prefix your new elements with short string that uniquely identify you or your company. So instead of me naming my class "MyClass" I should name it "MfpMyClass". You can think of this as poor-man's namespaces. This is a practice that is already widely used.
    
2. You create an element that will be assigned an ID by the system, which already has been assigned to another element created by someone else in their model. Our plan is that this cannot occur once we ship AX6 - we are close to a full implementation of this, but we are not there yet. I'll return with more details on this at a later point.
    
3. You customize an existing element that also has been customized by someone else in their model. There is really nothing you can do to avoid this collision, except to avoid customizing - which is not desirable nor possible. To alleviate this problem we are investing in changing the granularity of elements. In AX2009 tables and classes are stored with a fine granularity. This means that there is no collision if two models change two different methods on the same class or table. In AX6 all new concepts introduced in the model will also use a fine granularity - further we are breaking down some of the existing concepts, so far we have completed this work for Menus.
    

So 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 ("ModelA" and "ModelB") are imported into the BUS layer, then "ModelA" is imported without any problems, and "ModelB" will be imported into two models: "ModelB" in the BUS layer, and "ModelB_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. 
   

Conclusion

Models enable a lot of highly desirable scenarios, one of the most important scenarios being that models from different sources - for example, two ISVs - can be installed in the same layer side-by-side.  There are a few technical limitations; but the risk of conflicts is much reduced in AX6 and even when conflicts occur there is a less-expensive way to make the models co-exist.  

But wait... 

...there is even more to models - my next post on models will be about how to work with models within MorphX.

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

AX models - Part 2 - Manifest and signing

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:

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

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:

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.

If you haven't figured it out yet, I can reveal that an .axmodel file is a managed assembly. This means you can use tools like ILDASM to peek inside it.

But wait... 

...there is more to models - my next post on models will be about ... nah - you have to wait :-)

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

AX models - Part 1 - Deploying models

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:

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:

Now you can copy this file to the production system and import it there:

You can even uninstall it again - if that is what you want. This is semantically the same as deleting an AOD file in AX2009:

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 posting is provided "AS IS" with no warranties, and confers no rights.

"Inside Dynamics AX 2009" is now available

The book is now available at amazon.com. You can also browse parts of the book, including the Table of Contents at Amazon.

Today MS-Press is printing "Inside Dynamics AX 2009"

Today MS-Press will be printing the hard copies of "Inside Dynamics AX 2009". The books will hit the shelves later this summer. I can hardly wait to hold a copy; and to get your candid feedback.

Here is a link to more details on the book. As you can see the book contains over 200 pages more than the AX 4.0 edition - I think this very well reflects all the new functionality added in AX 2009.

I've also heard rumors about an ebook version, and a Russian translation. Stay tuned for more details.

Channel 9 Screencast: 10 MorphX tricks in 10 minutes

A new AX screencasts is now available on Channel9. It shows 10 small demos that will make you more effecient as an MorphX / X++ developer.

Here is the link:

http://channel9.msdn.com/posts/mfp/10-MorphX-tricks-in-10-minutes/

[Update: Media issue has been resolved.]

AX6 sneak preview - elements with 32 bit IDs

In AX4 we added Unicode support. On one hand it seems like a minor thing, it is just the storage format of strings - on the other hand it literally opens up a new world of opportunities. From a technical perspective it was a major surgical challenge; not many system files remained untouched in the process.

The same is very much true for the effort we have just completed in AX6: We have extended the ID range of concepts such as Classes, Tables, Base Enums, Extended Data Types, etc. from 16 bit to 32 bit. This certainly was a major surgical challenge; most files in the system had to be updated; still from business logic and other consumers it is still just an integer. What about the opportunities? First of all (which is very important here at Microsoft, but of little significance to everyone else) it enables Microsoft to not "run-out-of-IDs" and continue development with without disruptions. Secondly; the wider range gets us one big step closer to solving the ID problem. Now we have a range wide enough to contain solutions from various sources; we just need to figure out how to avoid conflicts between solutions other and already installed bits.

This will be the last sneak-preview for a while. We are now starting a new milestone, and I'll be back with more once I have more features to describe.  

THIS POST IS PROVIDED AS-IS AND CONFERS NO RIGHTS.

AX6 sneak preview - SQL AOD

Today we built the first official build of Dynamics AX ever that does not run on AOD files. Starting today Dynamics AX's model database is stored in a Microsoft SQL Server database.

Seen from within MorphX you hardly notice the difference. Everything works as it used to; there are no new feautures; but yet it feels different. The responsiveness of MorphX has slowly been deteriorating as the number of elements in the model has grown over the last releases. Today the speed is back. Navigating the AOT is suddently 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.

But wait a minute; AOD files were not just a database, they were also a deployment vehicle - what is the replacement? Dynamics AX supports a new file format: axmodel-files. (extension: "axmodel", example: "AxSYS.axmodel"). These are binary files, and provides the same deployment capabilites as AOD files did - and yet they are less than half size. Using a new tool you can import/export axmodel files to/from SQL. You can also import AOD files into SQL.

So far we have aimed at providing 1-to-1 parity with AOD files; but the potential of this is amazing - I hardly know where to start...

• Performance can be further improved as the subsystems querying the meta data store starts levarging the powers of SQL. For example; the ISAM database used for the AOD files (and still used by temp tables) doesn't support joins. Due to this many subsystems are overly chatty when reading meta data as they query row-by-row.
• Solving the element ID problem is now possible, as we can leverage the flexibilty and powers in SQL for modifying and extending the model schema.
• Capabilities... There are so many cool scenarios we can enable - but you'll have to wait for an sneak preview after the next milestone to learn more. But to get you thinking: What deployment capabilties did AOD files lack?

To night we celebrate this major achievement with the team. 

THIS POST IS PROVIDED AS-IS; AND CONFERS NO RIGHTS. 

Thank you - Arijit Basu!

I've just handed over my final edits to my chapters of the upcoming "Inside Dynamics AX 2009" book to MS-Press. A big THANK-YOU is due to the book's technical reviewer Arijit Basu. He has diligently reviewed every single paragraph and added suggestions for improvements, corrected inaccuracies, highlighted ambiguities, pointed out missing information and spotted occasional blunders. He has also ensured that all the examples in the book are working as expected, and the figures are illustrative. I've not counted how many hundreds of comments Arijit has added to my chapters, but I'm very pleased with the thorough review. (I can now rest assure that the content is not too far from the mark.)   Arijit; this book would not have had the high quality - if it were not for your massive review effort.

Please visit Arijit's blog at: http://daxguy.blogspot.com/

AX6 sneak preview - X++ Unit test improvements

These days the first milestone of AX6 is being completed. It means the first wave of new functionality has been implemented, tested and documented. As always; it is an exciting time to be working on AX...

One of the features coming in MorphX in AX6 is set of improvements in the X++ Unit Test framework.

First of all the unit test framework in AX6 is leveraging the new attribute feature in the X++ langauge. For example; you can use an attribute to declaratively specify the target class for your test (i.e. the class that is being tested by this unit test). Here is how:

Starting in AX6; you can also use attributes to mark which methods on the unit test class are test methods:

If you are using both unit testing and a version control system, you can benefit from marking your most critical test methods as check-in-tests. When setting up the version control system, you can specify which test project to run during check-in, and whether to run all unit test methods, or only the unit test methods that are marked as check-in-tests. During a check-in process the specified unit tests will be executed, and only if they all succeed the check-in will be submitted. This gives you the flexibility to run the most critical unit tests during the check-in process, while still having a full suite of unit tests that can be run on-demand. Here is how to mark a method as a check-in-test:

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

Innovating to improve the planet

At Microsoft, we are committed to software and technology innovation that helps people and organizations around the world improve the environment. Our goals are to reduce the impact of our operations and products and to be a leader in environmental responsibility.

For more information see: http://www.microsoft.com/environment/

Also see the Microsoft Dynamics AX Environmental Sustainability Dashboard:

http://www.microsoft.com/environment/campaign_dynamics.aspx

migrax(tm): A new way to do code upgrade.

More Dynamics; one of the Gold Sponsors on Convergence 2009; has just released what I find to be a very interesting product: migrax™. migrax™ can assist in migrating AX solutions from version 3 and version 4 to AX2009.

The approach taken is quite different from the code upgrade tools available in AX. The existing AX code upgrade tools live inside MorphX; and can harvest the benefits of MorphX, such as access to the AOT, Compare tools, BP tools, etc. However; living inside MorphX also induces certain limitations; for example all editing has to go through the AOT modeling API.

migrax™ does it differently. It is an external application. You start by loading your solution as an XPO file. It will be converted to XML and persisted in a database inside migrax™. Using XML techniques migrax™ is able to automatically resolve most code conflicts and produce an XPO file upgraded to Dynamics AX 2009.

migrax™ is capable of solving logical conflicts caused when the standard application (typically in the SYS layer) changes, and the changed element has been customized. migrax™ is by-nature not capable of resolving conceptual conflicts, like conflicting or redundant functionality. Here a set of human eyes is still needed.

One might argue that migrax™ is competing with the standard tool set in MorphX in upgrading code. I have a different perspective. The goal for me is to enable customers and partners to upgrade to Dynamics AX 2009 as seamless as possible. Having a larger tool box is a benefit to everyone.

Make sure to check-out the migrax™ site, and visit More Dynamics at Convergence 2009 in New Orleans.

The Power of Cause and Effect.

Dr. Eliyahu Goldratt has just published a comforting article on the opportunities arising in the wake of "the impression of an economic crisis".

http://www.goldrattconsulting.com/PowerOfCauseEffect/

It is well worth a read.

Dr. Goldratt is the author of The Goal, a novel illustrating his Theory of Constraints.

Dynamics AX 2009 Version Control Interview

At Convergence in Copenhagen 2008 Morten Jensen (PM in the MorphX Team) and I were interviewed by Ben Riga on the version control integration in Dynamics AX 2009.

In AX 4 we first introduced version control with integration to SourceSafe.  In AX 2009, we introduced Team Foundation Server (TFS) support as well as a MorphX VCS a low –end home-brew version control.  I demo the MorphX VCS feature showing how it integrates Check In/Check Out functionality directly into the AX IDE.  MorphX VCS is included with Dynamics AX.  The target for this low-end VCS is VARs maintaining numerous client system customizations on the same code base.

Version Control is just one leg of the Dynamics AX team’s commitment to Engineering Excellence.  They’ve also integrated unit testing and best practices policy enforcement.  The Dynamics AX team uses this integration themselves integrating with Source Depot (an internal Microsoft versioning system).  They are looking at moving to TFS.

See the full interview and demos at Channel 9.