Using Extensions on premise, a true hybrid solution

In the next version of our ISV solution, we have arranged everything so it can be delivered as an extension. Hurrah 🙂


If you’re still unsure about extensions, take a look here

But for OnPrem installations this also present a problem, because our OnPrem customers and consultants want the freedom to do modifications the old fashion way. Extensions in their world (OnPrem with lots of custom functionality) is still far off, until they can have the cake (extensions) and eat it too (do all the customizations the customers want) extension will never get a foothold in this category.

Enter my Hybrid-Extension-Model. We’ll split our ISV solution into two parts:

1. All new objects in our own number series
2. Standard objects that are modified

So we’ll install our new objects into a customer database, and create an extension that holds all modifications to standard NAV objects.

But if your custom objects need access to some of the fields added in standard tables to compile – your objects does not work anymore. But there is a way to overcome this limitation. We have created a codeunit with a series of functions.  These are all based on RecordRef and FieldRef. They are both evaluated at runtime, and the fields added by an extension are available at runtime, hurrah 🙂

In this example we have added a Social Security Number (type Text) to the Customer Table as field 50000 (by the Extension):

To get the value of a field added by an extension, we will do like this:hybrid-get

First, we’ll get the RecordRef from the record, then the FieldRef from the field added by the extension. This is the field that is not visible from the development environment, return the value.

To set the value of a field added by an extension, it is almost the same again, just remember to hand the RecordRef back to the Record with SETTABLE:hybrid-set

If we need the caption, for use in reports and other places, almost the same procedure:hybrid-caption

And the last example, if we want to add a filter on a field added by the extension:hybrid-filter

It looks like a lot of plumbing code, but in our case, we have only added a few fields to standard NAV so the plumbing is minimal.

If we need to use the fields on some of our own added pages, we will use the above functions and add a global to pages and wire up that global like this (also OnAfterGetCurrRecord):

hybrid-onafterrecord hybrid-validate-from-page

So our approach here is following: (TL;DR)

  1. Install all new objects in the database
  2. Create plumbing code using RecordRef and FieldRef to access the invisible fields
  3. Install an extension that only holds modifications to standard objects and a codeunit for events on those fields. (and the mandatory codeunit with upgrade functions)


An OnPrem customer database with our ISV solution installed. Since there are no changes to standard NAV objects, all forms of upgrading can be automated and maintenance is minimal.
The database still has the advantage of having all custom objects available for consultants to do customer modifications, so from that perspective, it is business as usual. The only price to pay to for this is the creation of plumbing code for added fields.

If I were in a situation with lots of fields, I would properly create a little code-generator to generate the plumbing codeunit for me.

Perhaps not the approach the Microsoft had imagined, but I kinda like the hack 🙂

So the next release of our ISV product will be delivered in three forms:

  1. As an Extension
  2. As an Hybrid-Extension (as described here)
  3. As normal FOBs/TXTs (but still with the plumbing code)

With option 1 and 2 as the default installation choice.

The conundrum of NAV and Open Source

There is a lot of talk about NAV and “Open Source” these days. Lots of the talk is related to the new Extension model that Microsoft Dynamics 365 and Dynamics NAV 2016/2017 shares.


Let’s first get a few definitions in place:

Open Source” – A piece of software where the source code is available to view and perhaps modify, but the original owner still controls vital aspects of the software.

Free Software” – A piece of software where the source code is available for anybody to use, modify, give away, do anything you want, apart from taking ownership of the software.

Object” – Every piece in NAV/365 is an object. That can translate to a table, a UI page, a report or other internal pieces. Each Object has an ID and the NAV/365 license defines access to the Object.

Business Logic” – The part of NAV that is built with Objects. This is the customer table, the general journal, the sales invoice posting routine.

Runtime” – The system that actually runs on the computers, the runtime executes the objects and makes it all comes to life.

The source code for the business logic in Dynamics NAV is available for those who has a license to that. There are several levels of source access:

  1. Customers can access partial sources if they have designer access to reports and pages
  2. Customers can access most sources if they have brought the “big” designer license.
  3. Partners have access nearly everything if they have a partner license.
  4. ISVs have access to their own “area” and can decide who (other partners) can access their objects.

That is neither open source or free software. This is privileged access to part of the source code of a closed sourced application.  And the privileged is only “given” to the select few that either buy access or through employment at a NAV partner.

So stop calling it Open Source, please 🙂

There are even plenty of NAV pieces that has never been “open sourced” to anybody outside Microsoft. That includes the development environment, the runtime, the different add-ins, add-ons, ADCS, Toolbars, portals etc.

But from a practical perspective, the amount of source code access in NAV has historical been more than enough to give NAV its unique ability to be transformed into 1000s of industry solutions. And this has been a huge factor in making NAV the big success it is today, because, for many years, NAV lacked in functionality but made that up by being customizable.

Looking in from other software development platforms, the first question we are asked is: Why is source code access necessary for this? If we look at DotNet, COM Objects or other ways of building software, customization can be performed without accessing and recompiling the original code?

The answer is found the programming model, NAVs two main issues:

  1. NAV has (until 2016) been missing an extension framework, meaning that there has never been an official way to trigger custom code from the standard application.
  2. NAV does not have an “official” API layer. There is no well defined public interface to NAV processes.

With NAV 2016 we got events that can be used for triggering custom code, and with NAV 2017, we have most of the trigger points that were missing in NAV 2016. Triggers can only be accessed from NAV code; there is no abstract public API layer giving us the ability to trigger NAV business logic from external code. In the old days, we had a library called C/Front which gave us database access to the native database but no business logic, and now we have web service access, but that only give us access to data a limited set of business logic.

So the solution has always been, to dig into the source, and modify NAV to fit the current customer’s requirements.

Wielding this sword has proven a powerful weapon for many NAV developers, a good NAV developer is well traversed in the source of the standard application and can make very cools customizations in a short time frame.

Losing the “Open Source” aspect of NAV, could easily sound as you have to return the sword to Microsoft and be left with a dull little dagger that can’t even glow in the dark when there are orcs around.


But wait? Are you losing anything? Some NAV developers are worried that they will lose the ability to fix bugs in the core product, which in fairness, used to be an awesome power often wielded ten years ago. But with the rapid CU’ing going on, most bugs that I have discovered turned out to be fixed already looking at the latest CU’s change log or they turned out to be bugs in the runtime environment that I never had access to fix anyway.

The current problem with extensions is that they are objects, but do not expose an API, does not give any public interface, they just sit there in the runtime like a ghost. You can’t address them from code in any way. But the new development environment shown at Directions seems to solve this. I cannot wait for the preview at Christmas!

So, going to a “closed source, open model” world, what do I need to serve my customers?

I need access to view and address the model, the same we today can view and reference the public interface of a .NET assembly.
I need a way to modify the standard application behavior, adjust the UI, update the database schema and add my own business logic.

If I can do that, I don’t need your source to do my job 🙂



Dynamics NAV abandons Windows Phone 8 in 2017

As part of the change log for the Microsoft Dynamics NAV Windows Phone client a small, but important message, has surfaced:

NOTIFICATION: With the introduction of Windows 10 Mobile, we will be discontinuing support for Windows Phone 8.1 in an upcoming update during early 2017.


Is this a problem? It could be. I’m certain Microsoft has some telemetry to back up their decision, but many businesses are using Windows Phones, and several models did not get the Windows 10 Mobile update, the Lumia 1020 is just one examples of phones that are left on Windows Phone 8.1

Is this a good thing? Hopefully, because NAV support on Windows 10 Mobile for Continuum is still lacking, and at present, that is the (single) biggest feature on Windows 10 Mobile, the feature that the entire platform is riding on. And having a Microsoft core offering not supporting it, is “less” than optimal.