AX365 Customization: Overlayering and extensions

(1) Share

Report

Posted on by Foxsor

160

Hello,

In AX365 there are two methods of customizing source code and metadata of model elements: overlayering and extensions.

I read in other posts:

"It is not possible to develop a solution 100% free of OverLayring, as of today".
"You need a customization if you want to change code inside a method".

I need to:

-create new specific table MyNewTable (Extensions)
-new referenced field link (refrecid) related to my table in standard table StandardTable1 (ApplicationSuite) (Extensions)
-create new others specific fields in standard table StandardTable1 (ApplicationSuite) (Extensions)
-Initialized specific field value and standard field value from specific value (Delegates)
-Modify other standard value from my specific value ( for instance class runnable treatement job)
-In standard active method form datasource: modifiy standard allow edit rules (standard If/else) from specific fields ... (Extensions not possible...,Overlaying way)
-Modify standard method with no super() (Extensions with Reflection)

I read you must create a new extension package/model (ApplicationSuiteExtension) and use Extensions Code (Events/Plugins/Class Extensions/Reclection),Table extensions/Form extensions etc

But when one point requires an overlaying way (for instance for a specific extension field / specific table code change use inside standard code) what's mean?

Get back to an overlaying solution in a new specific model (ApplicationSuiteCustom) in ApplicationSuite package for specific field/table and inside:
-Continue to use delegates/static method extensions to minimize overlaying code
-Create extensions only for field/tables in this specific model when they are no standard code change inside a method?

*This post is locked for comments

I have the same question (0)

All responses (4)

Answers (0)

Mea_ 60,284 on at

Like (1)

Report

Hi Foxsor,

Usually you have one model for extensions and one model for each package you are overlaying. As mentioned before, it's not possible to do everything using extensions, so sometimes you need to overlay standard code. You can use delegates to keep overlaying to minimum.

In most cases extension model will reference Application suite. Eventually at some point code that belongs to customization of Application Suite will need to refer some code from extension model, however, AX does not support cross references of models. In this case you will have to create new model to break dependencies or use delegates.

Was this reply helpful? Yes No
André Arnaud de Cal... 301,020 Super User 2025 Season 2 on at

Like (1)

Report

Hi Foxsor,

Ievgen is correct here. I just want to add a comment that sometimes by thinking differently it would be possible to use only extensions. At a customer where we are implementing now, we have the policy of NOT using customization layers, only extensions. Some developers did struggle a bit, also given the fact things were achieved using a customization in AX2009 before. But by analyzing what was required, we could turn the solution to do it a bit different. Result: still an overlayering

free environment! So don't look back what you did in the past, but try to do it different.

PS: AX365 does not exists. The product is called: Microsoft Dynamics 365 for Operations.

Was this reply helpful? Yes No
Foxsor 160 on at

Like (0)

Report

Thank's for your replies

Was this reply helpful? Yes No
Martin Dráb 237,878 Most Valuable Professional on at

Like (0)

Report

Also don't about classic object-oriented ways for removing direct dependencies - interface-based programming and polymorphism, dependency injection, dependency lookup (such as plugins in AX), events (delegates in AX) and so on.

For example, you declare and use a dependency in ApplicationSuite as an interface and let your extension package to provide a concrete object implementing the interface. This allows you to customizations just in the minimal necessary way (to refactor standard code to be extensible) and keep all your actual business logic in a separate package.

Was this reply helpful? Yes No