When I first heard about extensions in Microsoft Dynamics NAV 2016 a little more than a year ago, I felt like this was something that could completely change the way we modify to Microsoft Dynamics NAV to fit clients’ needs. Instead of creating new functionality directly in NAV code, the concept of the extension assumes that most of the changes are created outside the standard NAV code. You can then install your modification on top of the standard NAV application, and uninstall it if no longer needed.
The first release of extensions with Microsoft Dynamics NAV 2016 had many limitations. For example, there were only four types of objects which could be created: pages, tables, MenuSuites, and codeunits. In Microsoft Dynamics NAV 2017, these limitations do not exist. Reports, XMLports, and Queries are now available, and it is possible to use web services per tenant. Extensions are created using PowerShell scripts.
Testing Extensions in Microsoft Dynamics NAV 2017
- Create two equal test databases: DEV database and LIVE database.
- With PowerShell, import modules. This could be tricky in certain cases, as instructions found in MSDN articles do not always explain where to get the module you need:
- Create folder structure as DELTA, MODIFIED, and ORIGINAL folders:
- Export the Original object you are planning to change from the LIVE database. If you are going to modify multiple objects, you can export all objects:
- Development in the DEV database:
- Export Modified object, Create Delta, and Build the Extension package:
- Build package, Publish and Install Extension on the LIVE database:
As a result, we can see field “Name 2” in the LIVE database:
However, the NAV object is not modified!
If you check the page in design mode in the LIVE database, field “Name 2” is not there. But it does exist on the RTC page. That means our customization is stored as an Extension.
There are many pros and cons to extensions in Microsoft Dynamics NAV 2016. One of the obvious benefits is that it allows you to make tenant-specific customizations in a multi-tenant environment, because NAV object tenants that tenants share do not change. One of the potential problems is you cannot see customization code in the LIVE database, and instead, have to refer to the DEV database each time. In order to make any changes, you must uninstall the extension, modify the object in the DEV database, create a package, publish and install a new version of the extension again. This might be standard for other applications, but not yet for Microsoft Dynamics NAV.
There are still many limitations. For example, I was not able to add a new action to the page. However, it looks like Microsoft will continue making extensions technology more powerful and eventually it will be the predominant method of tailoring Microsoft Dynamics NAV. Expect object-oriented programming with objects, classes, methods, etc., with all the benefits and challenges. The transition period will not be a piece of cake, but being prepared will help things go smoothly.
Some extra information about Extensions in Dynamics NAV 2017 can be found here.