Aug 3, 2011
Filed under: #daxmusings #bizapps

I’d like to do a little follow-up on the models&events article series I’ve posted. It’s nice to get the feedback from you, these long posts take some work but from the feedback I’ve received it seems people found the series very useful so that is awesome to hear. There was also some other feedback, and the main one I’d like to touch on comes from MFP, which I thought I needed to share with you.

Obviously what I’ve dubbed the “Power Combo” is a very powerful concept and I hope people will embrace the new thinking to make the most of this concept. MFP agrees wholeheartedly, but wanted to make sure I mention the following three other concepts that make this powerful combo possible.

1. Fine grained metadata: I actually explain this one in the first post on models, but it’s important to know the power combo would not work without forms, parts and other AOT artifacts(such as VS projects) storing their components more granular than in previous versions of AX. I did get an email from a reader called Thomas who asked how I could state that an object can only exist in 1 model within a layer, but yet I imported my “customization” to the custTable table and form twice in two different models. Well, the granular metadata is exactly the answer to that!

2. Installation specific IDs: Object IDs have always been an issue in AX. In a strict development environment, with code ONLY moving from DEV to TEST to UAT to PROD, object IDs “should” never be an issue. The issue with object IDs is very easy to illustrate. Assume I create a class in DEV, which gets ID #50000. Someone else meanwhile, is actually creating a new class in TEST as well, which of course will also get ID #50000. Other scenario could be we create two classes in DEV, 50000 and 50001. Now we want to move the second one to TEST, but not the first one (let’s say it’s not done yet). If we move the class into TEST without IDs, it will generate a new ID on the fly (which will be 50000). Again, object IDs are out-of-sync. For classes, although it requires manual intervention, this can be resolved. However, for Table IDs, field IDs and anything that has security tied to it, changing IDs means dropping data from the database, security losing connections, etc. There were different attempts in the past to solve this problem. When source control was introduced in AX 4.0, the recommended setup was every developer having his own AOS and AX instance to work in. To remedy the issue there, a “team server” (poor naming, this has nothing to do with Team Foundation Server) was introduced, to keep track of IDs of objects across environments. In AX 2009, the export and import for XPO code was changed so that “export with IDs” was enabled by default. Which actually caused more issues for some clients who were not paying attention. In any case, as MFP explains on his blog, object IDs are no longer a concern in AX. I suggest reading that blog to get more background information. Short of it is, the IDs are still used by the compiler and the runtime, but they are assigned when a model is installed. To uniquely identify objects across environments, they are assigned GUIDs in the background, when and where you create the object. I’m butchering the details here, so I suggest you read the full explanation here. There are some things to keep in mind, for example, storing element IDs in data is a definite no-no, since they are most likely different between environments (making data export/import impossible). Also, Microsoft had to fix BLOB types (containers) to use element names instead of IDs for that very same reason.

3. SQL-based model store: I’m sure you’ve heard by now, the AOD layer files are gone, and all code and metadata is stored in SQL. There may not be much in your daily life as a developer that will make this change apparent, but it has enabled a lot of the goodies we get in AX 2012.

That was it. I have another big blog post coming up, so stay tuned. Please use the “contact me” link and keep sending me your comments and questions!

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!