Packaging Extensions for Dynamics AX
Packages. Extensions. Layers. Models. These are important technical concepts in the new Dynamics AX; it is enough to make your head spin. Your future self with thank past self for taking the time to understand how to organize AX code before the first line of code is written
An Extension is a brand new AX object that references an existing object. This style of development allows existing objects to be customized without directly touching the original object. It is a beautiful concept for application updates; upgrades become much simpler by reducing the number of dependencies.
In the example above, the Customers table is defined with two fields: Account and Name. A feature requirement calls for adding a third field to this table. Instead of directly touching the existing table, a new object is created that references the existing Customers table and defines the properties of the New field. The AX compiler will come along and say “Hello Customers and Customers extended; I will magically merge you both together and create a Customers table with three fields.” (My apologies to Peter Villadsen for not understanding a single thing about how the compiler works.)
What is great about this approach is there is distinct ownership of each object. Microsoft owns the Customers table, while an ISV, Partner, or Customer owns the Customers extended table. Each party can make changes to their object without impacting the other.
Tables are one area for extensions, but there are quite a few objects types eligible for extension.
- Data entities
- Some Enums
- X++ Code (Events)
Microsoft continues to evolve the extension story and support more scenarios.
Packages are another new concept in AX; a Package is a collection of unique objects and code. The objects may be extensions of objects in other packages, or brand new customizations. Objects are organized into Models within a Package. The point of packages is to divide up a large platform into smaller chunks that can (sometimes) be updated independently.
Packages should be split to facilitate upgrade and development scenarios for a solution.
Frequency of update
Code may receive fast or slow updates depending on the risk to the ongoing business processes.
- Fast: AX user interface and browser compatibility
- Medium: Business intelligence and Reporting
- Slow: Business Process
Necessity of update
Some updates may be forced because lawmakers like to make new laws, while others features are nice to have.
- Required: Regulatory Updates
- Optional: Localization Features
Code can be divvied up if the development work is split between multiple teams.
- Feature A: Dev Team 1
- Feature B: Dev Team 2
Packages and Extensions Are Not the Same Thing
When new to these AX concepts, it’s easy to conflate Package and Extension concepts into one. That is not quite the case; extensions can be done in the same package as the original object or in a new package.
Conceptually it is easier to think of three different development scenarios:
- Overlayering – The way it has always done in prior versions of AX; overlayering means directly changing an existing object.
- Extending in existing package – This approach is commonly used in conjunction with overlayering. Objects are extended, but these extensions can be referenced within overlayered code.
- Extending in new package – This is the ideal scenario. Entirely new objects that can be maintained separately from other packages.
Impact on Design
When designing new features, the extension and package concepts should influence the functional design. Developers generally will want to start work in a new Package. They may run into technical issues that, based on the functional design, would require extensions. At this point it’s important to regroup and make a conscious decision to either change the design or accept the overlayering.
One real-world example SAGlobal had was an AX 2012 form where a new data source was added. In AX 7, this design would have required overlayering. The work-around was to instead add a button to the existing form that opened the new data source. Communicating throughout the development process resulted in a more maintainable solution without sacrificing critical functionality.
Impact on Prior Version Upgrades
When upgrading code from AX 2012, the upgrade tool will automatically create some extensions, but will not put them in a new package. Generally, the upgrade has to go through a series of steps that include:
- Code refactoring so as many extensions as possible are utilized.
- Cut objects from existing Model and compile.
- Paste objects into new Model/Package and compile.
This is can be a daunting task, so for larger solutions our recommended approach is to do this work one feature at a time, instead of trying to refactor the entire code base at once.
- Azure Marketplace and the new Dynamics AX (v7)
- Workspaces in Dynamics AX (v7) - Let’s Make them Awesome