Upgradeable Programming in Microsoft Dynamics AX (v7)
AX 7 has many new features around organizing code; partners, customers, and ISVs need to understand these features to build upgradeable customizations. With prior versions of AX, it was common for customers to get stuck on a version because of the complexity of upgrading.
Keeping AX upgraded benefits customers, ISVs, and Microsoft. Having customers on a more recent code base reduces the cost of maintaining old software versions and the cost of providing support for bugs that have already been fixed.
Prerequisite Knowledge for this Post
To understand the upgrade story for AX 7, a good understanding of the new Package and Extension technology is required. Read this post first for a refresher course.
Upgrading from the Bottom Up
Below is a simplified diagram of Packages and Models in a typical Dynamics AX implementation. There are many more functional Packages provided by Microsoft; for example: Ledger, Subledger, Dimensions, and Workspaces are all separate Packages.
In AX 2012 it was only practical to upgrade the entire application (Microsoft, ISV, and Customer code) at the same time, making the cost of upgrade high and the regression testing complex.
In AX 7, upgrades can be taken in pieces to make the overall upgrade cycle more manageable. More frequent, smaller updates is a huge change for the AX community; developers need to make sure they are supporting this story.
An upgrade would start from the package with no dependencies – Platform. The Foundation Package could be upgraded next, followed by the Application Suite and other functional packages. Finally, ISV add-ons can be upgraded.
AX 7 has not been around long enough to know exactly how upgrades will look, but they might look like this in terms of frequency and testing impact:
- Platform, Foundation – Every three months. Minimal business process impact.
- Application Suite, Functional Packages – Every six months to one year. Low to medium business process impact. May require regression testing for changes to features in use.
- ISV Solution – Every six months to one year. Medium to high business processes impact and requires regression testing, although generally for a smaller set of features than the Application Suite.
- Customer Modifications – Do not require upgrading, unless impacted by new features in other packages. If required, upgrades would be done in conjunction with other packages upgrades.
Developing in an Existing Package has an Impact on Upgrades
Whenever development is done in an existing package, the upgradeability of AX is impacted. The amount of code that goes into a package owned by someone else should be as minimal as possible.
Code extensions provide a way to modify objects in other packages without touching the original object. Creating extensions in an existing package is different than creating extensions in a new package. An ISV who puts their extensions in the Application Suite is creating a dependency where the upgrade of the Application Suite is tied to a simultaneous upgrade of the ISV solution. An ISV who correctly refactors their code to a separate package limits the Application Suite upgrade to the ISV Overlayer Model.
Even when using all the available tools around Extensions and Eventing, there still will be cases where the only solution is overlayering. AX 7 has features to help with this scenario as well.
Merging code between layers happens at much more granular level compared to prior versions of AX. Granular merging minimizes the number of conflicts to deal with during an upgrade.
Delegates are another new concept in AX 7. Delegates are sections of code that can communicate with another Package, but from a compiler perspective are not dependent on the other Package. An example of Delegate usage is when a table is extended in an ISV Package, but the value in that table needs to be returned to a method inside the Application Suite.
Using extensions and limited overlayering is fairly easy when doing new development. When upgrading code from AX 2012, a concerted effort needs to be taken to refactor existing code. Refactoring with the new delegate and extension paradigms is an investment in the future upgradeability of AX.
Any code that is added to a package not owned by the ISV or customer should trigger a discussion between the developer and the solution architect. The discussion may cover multiple questions:
- Is there an alternative extensible design that is acceptable?
- Can the owner of the package change their code to make it more extensible?
- How can the footprint of the overlayering be minimized?
Upgrading Higher Packages First
There are cases where a customer may want to upgrade an ISV Package before upgrading lower packages to take advantage of new features. This scenario is sometimes possible; it mainly depends on the stability of the Packages the solution is dependent on.
- If there are changes to the ISV Overlayer Model, it has to get upgraded before the new package can be installed. This may require code merging since the overlay model may be linked to a specific Application version.
- Extensions can cause dependency issues. If the ISV Package extends a newer object, that object may not exist in the customer’s existing Application version.
To support this type of upgrade, the best approach is to try and keep dependencies with other packages as stable as possible over time. When there are new dependencies created, document in the release notes the minimum version requirements of the dependent models.
SAGlobal Can Help
SAGlobal has experience upgrading and refactoring code from AX 2012 for multiple ISV solutions.