Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 1 PlanDynamics 365 release plan for the 2022 release wave 1 describes all new features releasing from April 2022 through September 2022.
2022 release wave 1 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
With arrival of AX7, as we have got two approaches of development, a new development approach i.e. Extension allows us to extend AOT Elements.
For each element there is a property called isExtensible, which is either false or true.
Incase isExtensible=false, for an AOT element, that element cannot be extended.
An example let’s take a base enumeration LedgerTransTxt, which is part of Application Suite. Because of any reason such as for any of my ISV solution, I may think to extend this Base Enum, but I cannot extend it, as it is set to isExtensible=false
My question is simply, what made Microsoft to keep some elements extendable whereas other non-extendable?
Making enumeration extensible is actually pretty difficult and it has performance implications. It's not like with normal enums, where every element has a fixed ID. In fact, "extensible enums" aren't technically enums anymore, they're classes that AX merely presents to you in the same way.
To avoid conflicts, you can't assign any ID at development time - you can do it only when you put all extensions together. Then you have to store the mapping between enum elements and IDs (in database), look up them when necessary and so on...
If you need some enum to be extensible, please let Microsoft know . They're interested in this kind of feedback. But making all enums extensible isn't practically possible.
That means, at some point, it is need to customize few elements, in order to integrate solutions with existing AX, customization/over-layering will come into action
Correct. Overlayering is necessary in some cases.
The first thing here is that extendable and extensible are very different. Extendable is related to inheritance (EDTs, Tables, and Classes).
Base Enums are the only types that the author decides whether or not it is extensible, and there is a good reason.
Firstly, standard Base Enums compile to CLR types, but extensible Enums are compiled to a class, and each element is a static method. There is therefore additional load.
Also, you can't use extensible enums as status fields, where we want to compare. If they made SalesStatus extensible, they can't guarantee the numeric sequence, and you can't write "where SalesTable.Status < SalesStatus::Invoiced". The numeric value of extensible enums are installation specific.
Hello Gentlemen!I’d like to ask your help in order to clarify some issue regarding to BE extension.1. Martin, you wrote “…To avoid conflicts, you can't assign any ID at development time - you can do it only when you put all extensions together…” – what does it mean: “you can't assign any ID at development time” and more unclear phrase for me is: “…you can do it only when you put all extensions together…”. Can you please explain - how I can put all extensions together and where I can do this? Another question – “…Then you have to store the mapping between enum elements and IDs (in database), look up them when necessary…”. How does mapping looks? Is this some table or what? And where is should be kept (“…in database…” – where in database?).2. Simon, you wrote “…standard Base Enums compile to CLR types, but extensible Enums are compiled to a class, and each element is a static method…” – what will happen with standard Base Enums which will be extended by ISV (will it be compiled into CLR as well? Or?)The basis of my question is – these things (related to BE extension) are not clear for me (yet), and I’m sure, that there are a lot of other developers for whom this thing not clear either.Thank you
Re 1) Extensions are put together by Dynamics AX if you use more then one extension for the same object (maybe in your single model, but more likely by installing several solutions developed by different companies). Then AX also assigns element IDs for extensible enums.
It's in Enum* tables, but please never touch them. It's maintained by AX kernel, not by developers.
Re 2) "What will happen with standard Base Enums which will be extended by ISV" - if "standard" means "not extensible", then it can't be extended. If you mean extensible enums, it's covered by Simon's reply.
If all these implementation details makes little sense to you, simply ignore them. Sohaib asked why Microsoft made some decisions; you don't have to understand them to use Dynamics AX.
Can you suggest how to solve this type of error you mentioned above .
done some customization for SalesQuotationStatus Enum(added an element) by making the property IsExtensible::true and Use enum value:: No . Later,added the element required and used in the eventhandlers for some logic to be executed. Now there are errors in other classes which uses this salesquotationstatus like the condition above.
Error:"Cannot use Extensible Enum type(salesquotationStatus) in non-equality comparisions. how to resolve this>? please suggest
Hi "Test Bot"(!?)
For SalesStatus, take a look at what has been done with the SalesStatusOrderedList class.
And you really shouldn't change the IsExtensible property of anything. It would be difficult for you to figure out what the complete system consequences would be. Which you to some extend have experienced already yourself as you now have compilation errors in other classes.
When Microsoft hasn't made this extensible yet, it is because there is a lot of changes that need to be done to existing code to handle that the enum is extensible. I suggest you add an extension request with your business case. That might bump it up in priority.
How to rectify/revert the change done i.e. how to revert back to original state of salesquotationstatus. pls suggest so that the compilations errors in other classes can be gone.
I will look onto the idea of logging extensibilty requests.
I'm actually a bit curious about how you did the change. If you did it through overlayering and you didn't change anything else on the enum, you can just delete your overlayering.
From Appln Explorer ,right click and click the customize option(my custom model referencing appln suite) ,changed the properties IsExtensible::true and Use enum value:: No . Later,added the element required . thats it and didn't changed the standard elements in the enum. used my new element for executing some business requirements.
delete your overlayering means!! can u explain a bit more. I am new to D365
Okay, then you did an overlayering. You should delete the element from your delete, which again should delete the overlayering from whatever layer you're working in.
Okay as you said, I will delete the element which i created in the enum and then will delete the enum from my model in which i am working and do full build. will check your suggestion for sure!
Is there any workaround for this requirement except extensibilty requests ?
I'm afraid there is no good workaround.
If you are pressed for time, due to plans for go live, you could consider still adding this enum as an overlayering (without changing the two properties - which really isn't needed in case of overlayering).
But you must plan for getting the extension point, and I'm pretty sure someone else already has put a request in for this enum. I'd be surprised otherwise.
The above idea of yours worked . but a warning is like "salesquotationstatus enum will have upgradation issues". For the time being your idea worked for removal of compilation errors in other classes
Business Applications communities