Solving the element ID problem

We’ve had feedback from many sources (comments in this blog, emails, in-person meetings, partner advisory board, etc.) that we should fix the element ID problem in AX – the sooner the better. Thank you very much for this feedback. This post is intended to give a bit of background on this subject.

The element ID problem in AX causes pain on two fronts:

  1. Uniqueness. Element IDs must be unique on any given installation. We have a suite of tools to help generating unique IDs, detect uniqueness conflicts, etc. Learning and using these tools are painful, resolving ID problems is even more painful, especially on live systems. Further the uniqueness issue makes it hard to combine solutions from different source in one installation.

  2. Upper limit. Each layer has a finite number of IDs. This means there is an upper limit to how many model elements you can create. Microsoft’s core development team knows exactly how this pain feels.

At any rate; this is a problem we need to address – and my team has been given the task. While many solutions spring to mind (use GUIDs or drop IDs completely) this is a case of Devil in the Details.

Business Data: IDs are persisted in the business data base. Any change to IDs would require upgrade scripts. To make matters even worse, IDs are also stored in unstructured blobs; making identification and migration even harder.

Business Logic: Business logic uses IDs. Both Microsoft’s business logic; but certainly also the business logic in solutions authored by partners around the world. Changes to IDs would impact all this business logic.

Kernel: The implementation of the kernel used IDs heavily. Changing data type or dropping IDs totally would require rewrite of large portions of the kernel. The kernel provides the API for converting IDs to names and back again.

Application model: IDs (and Names) are stored in the Application Model. IDs are used as references between model elements and IDs bind customizations to the original element. Whatever changes we make, we cannot break the references in the model.



Getting challenges like this is what I love about my job.



Comments (11)

  1. msmfp says:

    Well – the design time is now 100% name based in AX6.

  2. developer says:

    Well, well, reading back is quite fun. Name based solution didn't make it to Ax6 neither 🙂

  3. In AX4 we added Unicode support . On one hand it seems like a minor thing, it is just the storage format

  4. Today we built the first official build of Dynamics AX ever that does not run on AOD files. Starting

  5. msmfp says:

    ddjong: I cannot yet reveal all the details of the solution; but you are not far from the mark.

    Our goal for AX6 is to provide a name based solution, so you as a developer only have to care about names.

    Providing namespace support is the next logical step; but will not make it into AX6.

  6. ddjong says:

    I hope this ID problem gets properly solved. In fact we talk about naming collision prevention. Then very often you see the question ID-based or Name-based coming up. Quite often you see ID-based being used (GUIDs), but what do you think if we in real-life are going to use GUIDs to identify people? I think internally in an application, using GUIDs is a good thing to prevent huge rename actions when an ID changes, (many objects might refer to that changed ID … But ultimately we NEED NAMES … I would like to have NAMESPACES be part of AX ….

    plz let all components in AOT have a namespace and also provide tree-alike structure in AOT to organize things according namespace ….

    This would be really phantastic … And whether you use internally GUIDs, i don’t mind … And if you internally generate an ID (numeric) for a GUID since kernal requires that … i don’t mind. But don’t expose this to outside world … 🙂

  7. The summer is over, and you might have noticed I haven’t been blogging much the past few months. You

  8. msmfp says:

    Microsoft is already using the combined ranges from SYS+GLS+SLx. This gives us a total pool of 20,000 IDs.

  9. «Upper limit. Microsoft’s core development team knows exactly how this pain feels»

    Why not change layer ID limits? If lots of classes and forms and EDTs has been consolidated on the sys layer from multiple dis-layers, why not merge sys and dis layers ID ranges?