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:

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:

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

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

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):

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)

Result

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.