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.