In my previous posts about Extensions in NAV2016 I tried to explain the concept, reasoning and get you started with your own Extension in 5 easy steps.
- Getting Started with NAV2016 Extensions
- Create your own Extension in 5 easy steps
- Real world examples for Extensions
I got a lot of feedback and emails based on these posts. Some about PowerShell and using DotNet interop, some about XMLPort and Reports.
In this post I will talk more about the current possibilities and limitations and if, how and when these will be lifted.
In essence this blog is relatively simple. Microsoft already did a great job in documenting these on MSDN.
- Extending Microsoft Dynamics NAV Using Extension Packages
- How to: Create an Extension Package
- How to: Develop an Extension
- How to: Publish and Install an Extension
- Extension Packages Capability Support Matrix
The last one is of essence for this blog. The support matrix. Let me elaborate on that.
In short, the most important options you have in NAV2016 are:
- New Tables
- New Pages
- New Codeunits
- Add fields to Tables
- Add Controls to Pages
- Change properties (See support Matrix for options)
- Leverage Events for business logic
You cannot change code in existing objects!
With these options you can already do a lot, as I mentioned in one of my other blogs:
- Create Role Center Extensions
The most important impossibilities are
These object types are simply not supported in extensions
The real challenge
So you can learn all of this from the MSDN, so let me focus on being independant; the MVP part.
First of all, it would be great if the missing object types are added, and they will. I know that Microsoft is working on that and hope and trust they will make this happen in some future version.
More important are the fact that the extensions are still depending on the “good old” numbering limitations that we have in Dynamics NAV. I say “good” but that is actually not what I mean.
In Dynamics NAV, all partners can add changes and objects to Microsofts base code. We do that using “number bands”. The most well known is 50.000 to 99.999. Every partner and customer can in essence add objects here depending on their license. We can also add Menu Suites in numbers 1050, 1051, etc.
On top of that, all Objects in NAV must have unique names accross the application and Field names must be unique per Table. Tables have a maximum size of 8000 bytes, which is forced by SQL Server. Also some field properties such as Autoincrement are limited to one per table.
The Dynamics NAV 2016 Extensions are still using these same numbers and restrictions which means that if I add an Extension with table 50.000 and this table already exists in NAV the Extension cannot be applied, even though it is a valid Extension based on Cronus W1 database. The same happens with Fields.
It gets even more confusing with names. If I create a table called “Shipment” and try to import an Extension with a Shipment table I get an error, even though they might have a different number.
Ok, these restrictions can be solved using CfMD licenses (official add on numbers) and Suffixes for names. This however creates a new challenge which is licensing. I’ll come back to that later.
The two limitations that will bite us first are the MenuSuites and SQL table limitations. There are simply to few MenuSuite numbers for all CfMD solutions to co-exist and many CfMD solutions add fields to popular tables such as Sales Header and Purchase Header.
The licensing is a challenge in Multi Tenancy situations where one tenant want an Extension and I have to aquire a license or if I just want to play with an extension before I buy it.
Development Environment – Object Designer
Another restriction that I see a challenge with is the Object Designer in our Development Environment. Currenly this is unaware of extensions. In real life this means that if I buy an extension I cannot make my own report based on an extension table, or use an extension field in a standard table in a Web Service.
Let’s asume for example that Schouw FoodWare or Lanham E-Ship is an extension. This means I can no longer access the code and make a small change.
This makes Extensions very limited from a vertical solution perspective and impossible to use for localization layers.
If, and I say IF, the object designer would be aware of Extensions I could design new code based on (dependent of) existing Extensions.
A dream: If all localizations would be an Extension and every vertical solution is an Extension with a dependency on a Localization I could customize a customers database as an Extension depending on the two base layers. This would completely change the way we upgrade databases to new versions and make it so much easier for ISVs to go global with their add on. I do believe this would be THE way to make NAV grow to the numbers that Paul White wants it to grow. More than the cloud and multi tenancy story. It would reduce implementation time and make it easier for partners to keep their customers up to date.
BUT… this is a dream and my vision on the future of the product. I’ve shared this with Microsoft and now I am sharing it with you.
I’m not sure how Microsoft will lift the real restrictions, but I do know that they have smart people. I hope that whatever change they make will preserve simplicity.
Bottom line: start using the extensions and get familiar.
I’ve been part of the discussions around extensions and eventing with Microsoft over the last 12-18 months and super enthousiastic about the current result. Don’t hesitate to send me an email, I will help you get started with this and help to be prepared for the future.
Extensions and Eventing is now also part of my Master Class for Application Architecture and Design Patterns.