Thursday, June 29, 2017
Since the introduction of Microsoft Dynamics AX, modifications have involved the use of either overlayered code or Extensions. While overlayered code is the most used approach it is often the source of frustration when moving from one release to the next due to the high cost and time required for conflict resolutions, testing, etc. Thus, to stem these undesirable factors, in conjunction with the Spring release 2018 in Q2, all solution modifications in Dynamics 365 Enterprise will only be possible through Extensions.
If you have yet to become familiar with Extensions, plan to get acquainted fairly quickly. This blog post will explain why the exclusivity of Extensions for Dynamics 365 Enterprise is actually the best thing for your business as well address what are the best options to move to Extensions.
What could these Dynamics 365 Enterprise changes mean for you?
In March 2017, Microsoft announced a new release roadmap which revealed that Microsoft is now starting the seal standard of Dynamics 365 Enterprise objects. "Sealing" means that objects, which are part of "sealed" models, will not be available for overlayering anymore. There are two ‘sealing’ terms in the release roadmap that explain how different parts will be placed under Microsoft’s complete control (see Release Roadmap below):
- Soft seal . Soft seal is just a warning that a model will be locked for overlayering soon. Here compiler will give a warning when the overlayer of a model is being compiled.
- Hard seal . Hard seal is a lock of the model. Compiler will give an error when the overlayer of a model is being compiled. This compiler error in Dynamics 365 Enterprise means that the whole application is not compiled, thus none of the changes will be saved to executable files.This has changed since the previous versions where objects could have been compiled and added to executables one-by-one.
Figure 1: Release Roadmap
Microsoft is already locking standard objects for overlayering. App Platform Model and App Foundation Model were locked in the latest release. The App Suite Core Models will have Soft Seal in the upcoming Spring 2017 release ( expected in July 2017 ). This means that solutions that have customized/overlayered objects of these models are already incompatible.
If you still have overlayered code customizations on Dynamics 365 in the Fall of 2017 they will be supported for three years, providing ample time to migrate them to Extensions. This does not mean it is a good idea to take advantage of overlaying while it is still possible . If anything, this makes transitioning to Extensions even more important, not opting for the “quick and dirty” code upgrade offers. While it may be tempting to not move overlayered code to Extensions now this will only lead to a larger effort to upgrade next Spring.
App Suite is expected to be hard sealed with the Spring 2018 release, meaning that with this release all solutions must be implemented or moved to Extensions in order to be functional on the latest Dynamics 365 Enterprise release.
What are Extensions? Why will you win moving NOW?
Extensions simplify modification and customizations through keeping themt separate from the standard application objects and code base. Meaning that you won’t have to invest the time to review compatibility of each Extension after every Cumulative Update or version release. Extensions make creating and maintaining customizations for Dynamics 365 Enterprise easy!
Currently, there are still two techniques to customize a system: (1) overlayering which, as we already learned, won’t be available after the Spring 2018 release, and (2) Extensions .
It’s an old-style development technique used since the first release of the Axapta, where all modifications were implemented via overlayering of the standard objects. Meaning that custom code is written on top of the standard code, thus it “overlays” it: the new code doesn’t overwrite the core, it simply rolls on top of it and is readily separable.
Extensions is a new development technique, introduced with the current version, which enables implementation of custom functionality for Dynamics 365 Enterprise without changing the standard application objects. Not having standard objects modified means that:
- Solutions can be installed easily onto a Dynamics 365 Enterprise instance and no additional development effort is required to merge changes onto standard application objects;
- Updating Dynamics 365 Enterprise will require less development effort as each customization will not have to be reviewed after updating standard code.
Unlike the overlayering capabilities of Microsoft Dynamics AX 2012, Extensions don’t overlay or disturb the standard code. Instead, Extensions are compiled as a separate assembly that adds to or customizes the model and the associated business logic, which eliminates the need to merge any custom code. Currently, Extensions support customizations of the Dynamics 365 data model, business logic, forms, reports, labels, security artifacts and even data entities. Nevertheless, not all types of objects allow the use of the Extensions development method.
The following two diagrams illustrate how Extensions are isolated in their assemblies.
Figure 2: Merging Overlayering customizations in base package/ Extension based customizations in separate packages
Support of Continuous Updates
Writing custom code on top of the standard code (overlaying) provides flexibility, though it is quite costly as the more you overlay, the more you have to merge when the version of standard application has changed.
Extensions in Dynamics 365 Enterprise make it easier for you to deploy, manage and upgrade customizations without directly altering the base source code of Dynamics AX. What does this mean? It means moving forward, even with many customizations in play for your Dynamics AX solution, your annual upgrades become easier as these Extensions sit alongside the AX base code, rather than in a customization within the code. Essentially, you eliminate the need to merge code moving forward (with some exceptions).
How to choose the most suitable option for moving to Extensions
Moving your current Dynamics AX version modifications to Extensions means lifting those modifications from overlayered objects and attaching them to the Extension “hooks” provided by Microsoft in the Dynamics 365 Enterprise version. Thus, depending on the number of standard application overlayered objects, the whole solution’s transition to the Extensions can become complex and costly.
To ease this transition from AX 2012, Microsoft introduced tools that can partially move the code to Extensions during an automatic code upgrade, while AX 2009 and earlier version code should be migrated through Dynamics AX 2012 or manually. Thus, other options should be considered or earlier versions. Let’s dive into which two possible roads are available to move to Extensions.
- Direct path to move your customizations from Dynamics AX 2012 to Extensions automatically.
Currently, Microsoft provides its Lifecycle Services tool to auto-migrate customized solutions to Dynamics 365 Enterprise if the solution is run on AX 2012 R3 CU8 or later AX 2012 versions. This tool is primarily intended to aid in moving modifications from the old model store to a new platform, but it will also move some customizations to Extensions. For example, the custom table fields will be moved to table Extensions automatically.
Find the overview of solution migration to Microsoft Dynamics 365 Enterprise here .
Several examples of moving to Extensions:
- Overlayered method modifications can usually be moved to custom methods that act as event handlers and subscribe to either preceding ( pre-) or succeeding ( post-) events of original method.
- Custom table fields can be moved to table Extensions.
- Changes to some table field properties can be moved to extensions.
- Some changes to properties of extended data types (EDTs) can be moved to EDT Extensions.
- Changes to enums can be moved to enum Extensions (only for enums that are enabled to be extended).
- Moving to Extensions from Dynamics AX 2012 where auto-migrate tools aren’t available.
Not all the customizations are yet moveable to Extension, as Microsoft is well aware of. Therefore, solutions may have to be re-designed and re-implemented. Even though the list of tools aiding to move to Extensions are expected to be extended by Microsoft, it will never be possible to automate this process. The reason is that some of those modifications are using standard objects in a way that it will not be possible to do when moved to Extensions. Examples of these are modifications to methods that disable standard code, change SQL statements, adjusted table constraints, etc. These modifications should be examined by a developer and that developer should decide how the desired modification functionality will be achieved using the development technique that Extensions provide.
Note, that there are several well-known challenges when moving to Extensions that are yet to be resolved:
- Not all enums are extensible. There are currently 800+ enums that are extensible and the list is growing.
- Overlayered method restrictions: (1) it is not possible to add code in the middle of method via Extensions; (2) it is not possible to access protected class members; and (3) it is not possible to change SQL statements inside method. Modification must be re-designed to achieve similar functionality.
If you are planning to scope the work now or in a few months keep in mind that Microsoft is planning to release improvements that will simplify your work. Microsoft is adding more and more “hooks” for Extensions to attach to the standard application to enable new Extension scenarios. There are plenty of extensibility features that are planned to be introduced in the upcoming releases:
- Table fields – more table field properties will be supported for Extensions (AllowEdit, EDTType, etc).
- Form patters – it will be possible to change form patter in form Extensions.
- Table relation – it will be possible to add table relations to table in Extensions.
- Query range – enable/disable or change value of query range.
- Form events – new events on form datasource (validate, lookup, preInit).
- Form control events – possibility to cancel super() on control’s clicked() method subscriber.
- Class extensibility – a new design is in progress to have pre and post events on public and protected methods, access to variables of base class, and support for transactions between pre and post logic, etc.
- Development is needed to move to Extensions if on an earlier version than AX 2012 R3.
Microsoft does not currently provide options for older version of Dynamics AX (AX 2009, AX 4.0), thus code should be migrated manually, meaning that a full/ partial re-implementation is needed or an upgrade to Dynamics AX 2012 to use the auto-migration tool.
- Upgrade through Dynamics AX 2012 R3 and then use auto-migration tool to upgrade to Dynamics 365 Enterprise.
To avoid total system reimplementation, lightly customized solutions with consistent data can be upgraded from AX 2009 or earlier version to AX 2012 R3 and then leverage Lifecycle Services and Visual Studio tools to migrate code and data to Dynamics 365 Enterprise.
- Moving straight to Dynamics 365 Enterprise (re-implementation of the customizations using Extensions)
Heavily customized solutions with inconsistent data should be reimplemented without doing the full data upgrade (starting from AX 2009). Currently there are no tools for code upgrade and data migration from AX 4.0 and earlier versions, thus only pure reimplementation is possible from AX 4.0 and earlier versions to Dynamics 365 Enterprise.
Detailed information about the upgrade scenarios to move to the Dynamics 365 can be found here .
Better together: moving to Extensions with upgrade professionals
英雄联盟竞猜抽注入口v8.8 安卓版 helps Microsoft Dynamics Partners assess the most beneficial upgrade path that best suits their customers’ needs in addition to offering a number of assets and services that help prepare for the transition to Dynamics 365 Enterprise smoothly, including transforming code into Extensions.
英雄联盟竞猜抽注入口v8.8 安卓版 works as a natural extension of Microsoft Dynamics Partners’ expert team to deliver the technical components of upgrade projects and transformation of customizations on Dynamics 365 Enterprise while reducing the risk and shortening the upgrade time. Click here to find out more about upgrading to Dynamics 365 Enterprise with help transforming customizations to Extensions.