NAV2016 | (Im) Possibilities with Extensions

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.

  1. Getting Started with NAV2016 Extensions
  2. Create your own Extension in 5 easy steps
  3. 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.

  1. Extending Microsoft Dynamics NAV Using Extension Packages
  2. How to: Create an Extension Package
  3. How to: Develop an Extension
  4. How to: Publish and Install an Extension
  5. Extension Packages Capability Support Matrix

The last one is of essence for this blog. The support matrix. Let me elaborate on that.

Possibilities

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
  • Workflows
  • Facades
  • Hybrids

Impossibilities

The most important impossibilities are

  • Reports
  • Query
  • XMLPort

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.

Get Started

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.

Advertisements

11 thoughts on “NAV2016 | (Im) Possibilities with Extensions

  1. Hi, great post, thanks for that.

    One thing that I am struggling with, when publishing my extension, is inter-dependencies between objects. In my extension there are bespoke pages, codeunits and tables that all have dependencies and references to each other. Whenever I try to publish my extension, it always fails with these kinds of error:

    Publish-NAVApp : Development Environment – Compile Object Errors:
    Table
    [85132265] Codeunit 92000 does not exist. — Object: Table 92001 Astral Send Report Config
    [85132265] Codeunit 92002 does not exist. — Object: Table 92004 Astral Send Log
    [85132265] Codeunit 92004 does not exist. — Object: Table 92005 Astral Send Document Batch
    At C:DataupgradeAstral SendAstralSend.ps1:5 char:1
    + Publish-NAVApp -Path “C:DataupgradeAstral SendAstralSend.navx” -S …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidArgument: (Microsoft.Dynam…s.PublishNavApp:PublishNavA
    pp) [Publish-NAVApp], InvalidOperationException
    + FullyQualifiedErrorId : Microsoft.Dynamics.Nav.Apps.Management.Cmdlets.PublishNavApp

    All the codeunits are included in the extension, but obviously haven’t been imported and/or compiled when the tables are complied.

    I’m hoping that I’m doing something wrong, or that there is a way around this issue. If not, this is the biggest drawback of all for me.

    Like

  2. Hi, great post, thanks for that.

    One thing that I am struggling with, when publishing my extension, is inter-dependency between objects. In my extension there are pages, codeunits and tables that all have dependencies and references to each other. Whenever I try to publish my extension, it always fails with this error:

    Publish-NAVApp : Development Environment – Compile Object Errors:
    Table
    [85132265] Codeunit 92000 does not exist. — Object: Table 92001 Mail Send Report Config
    [85132265] Codeunit 92002 does not exist. — Object: Table 92004 Mail Send Log
    [85132265] Codeunit 92004 does not exist. — Object: Table 92005 Mail Send Document Batch
    At C:DataupgradeMail SendMailSend.ps1:5 char:1
    + Publish-NAVApp -Path “C:DataupgradeAstral SendMailSend.navx” -S …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidArgument: (Microsoft.Dynam…s.PublishNavApp:PublishNavA
    pp) [Publish-NAVApp], InvalidOperationException
    + FullyQualifiedErrorId : Microsoft.Dynamics.Nav.Apps.Management.Cmdlets.PublishNavApp

    All the codeunits are included in the extension, but obviously haven’t been imported and/or compiled when the tables are complied.

    I’m hoping that I’m doing something wrong, or that there is a way around this issue. If not, this is the biggest drawback of all for me.

    Like

  3. Hi
    hanks for this article.
    But I have one query related to Events and Extensions. In one our database we are facing the situation where some base code is commented in Field Triggers. If we go on and use the publisher function or manually comment the code, then we will not be able to Publish our extension. Could you help me in this situation on how to handle code commenting situation for base code codes when using Events and Extensions simultaneously? Thanks in advance.

    Like

      1. Hi Mark
        Thanks for your reply and solution.
        So can we quote the statement like this “It is not possible to upgrade existing NAV database to NAV 2017 purely using Extensions and Eventing concept ?”. Is this kind of limitation of Events and Extensions currently?

        Thanks in advance.
        Regards
        Rachit

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s