With this blog post, Microsoft announced the March update of the Developer Preview. The usual Docker images will be publicly available on April 2^nd and will contain the Microsoft Dynamics 365 Business Central release candidate.

In the blog post Microsoft listed a number of nice improvements and a lot of fixed issues. However, one of the improvements didn’t make it to the blog post, maybe because it was also discussed in one of the issues on GitHub.

Anyway, it is an import feature, so I’m going to explain it here. The tableextension object has four new triggers:

• OnInsert
• OnModify
• OnDelete
• OnRename

What are these triggers and how are they related to the OnInsert / etc. triggers in the base table? And what’s the difference with the already existing OnBefore and OnAfter triggers in the tableextension object?

The difference is that these new triggers will be executed before the data of the table has been written to the database. While the OnAfter triggers will be executed after the data has been written to the database.

Let me explain the background.

Back in NAV 2016 we got database events that we can subscribe to. Those events are executed after the database operation. If you want to update data in the record, you have to use MODIFY again, otherwise data will not be saved to the table. To read more about this behavior, I can recommend this in-depth blog post from Vjeko.

With AL this behavior has not changed. The database events are still being raised after the database operation. However, with AL we also got the tableextension object with triggers like OnAfterInsert, etc.

What’s the difference between a database event subscriber in a codeunit  and a trigger in a tableextension? There is just one difference: a trigger in a table extension runs only when the RunTrigger parameter is TRUE. While an event subscriber in a codeunit always run. In other words: Rec.Insert(true) will execute both OnAfterInsertTrigger in the tableextension and the event subscriber in the codeunit, while Rec.Insert(false) will only execute the event subscriber in the codeunit. But both will execute after the real database operation!

So we still need to do Rec.Modify in the tableextension trigger to preserve data in the record. Which can potentially lead to unintended looping between insert and modify triggers and event subscribers.

So here is where the new triggers in the tableextension object kick in. These new triggers execute before the database operation. Like the OnAfter triggers in the tableextension, they only run when RunTrigger is true.

With so many triggers and events, I thought it would be a good idea to compose a list with the correct order in which they are executed. So here is a table for the database insert (same applies to modify, delete and rename of course):

I think that the OnAfter triggers in tableextensions are now getting less important, to not say quite useless. The new triggers are very close to writing extra lines of code to the end of the C/AL triggers in the base tables (not 100% the same, some restrictions apply, see below). In C/SIDE you don’t write a MODIFY in an OnInsert trigger, do you? The new tableextensions triggers don’t require a modify either, so that is a great improvement. In my view, the new triggers are what the OnAfter triggers should have been in the first place. Ok, I know that the logic behind OnAfter is: after something is completed, so it should occur after the real database operation (that’s the logic Microsoft follows). But in my mind, and I think in the minds of many NAV developers, OnAfterInsert means: after OnInsert trigger of the table, but still before any database operation. Just because with C/SIDE we do the same when we add code to the end of the OnInsert trigger.

To make the OnAfter triggers less useless, one could set a rule like: put code that modifies fields in the table in the new tableextension triggers and all other code should go in either the OnAfter triggers or an event subscriber in a codeunit. But then again, I would rather go with an event subscriber because then I know that the code will always run, regardless of the RunTrigger parameter. But it also depends on the scenario of course.

Anyway, you probably want to move your code from the OnAfter triggers or the event subscribers to these new tableextension triggers to avoid the unintended endless loop that can be caused by using Rec.Modify.

Finally, I would like to express my support to this issue on GitHub: Access to local variables and functions in table and pageextension. Enabling access to local functions in tableextensions would make those new OnInsert etc. triggers even more useful!

Maybe I’ve missed some announcements, and maybe others also blogged about this and I totally missed it. But so far I have not seen this message: with Dynamics 365 Business Central it is possible to customize tenants to individual needs.

What does that mean?

Tenant customizations

That means that you can create an extension for a single Dynamics 365 Business Central tenant which can be deployed directly, without going through AppSource.

In short:

• Dynamics 365 Business Central is open for customizations in the 50000-99999 range
• Use Visual Studio Code and the AL extension and the client designer
• Develop against a Dynamics 365 Business Central Sandbox or a Docker container
• Deploy the app directly to the production tenant

Background

Why would Microsoft enable this?

This is to enable the partner channel to deliver customizations for Dynamics 365 Business Central that fit customer needs. In fact, this is placing the end user in the center, because it is possible to create bespoke customizations on Business Central. It even allows the end-user to create tenant customizations themselves because you don’t need a development license at all!

Having said that, along with the positive aspects, we have to remember the flip side of the coin.

First of all, it is all about Extensions, AL code and VS Code. Which means that with Business Central we cannot do exactly the same as we can with Dynamics NAV on-prem.

Is that a problem?

Choices…

I could easily come up with more than a handful scenario’s that could only be solved by modifying source code. We are kind of spoiled by NAV and C/SIDE, aren’t we? But that on itself does not prove the approach of Dynamics 365 Business Central wrong. It just proves that it is a platform with different possibilities. With pros and cons. You have to make choices like: do I accept less or less optimal functionality, compared to what I could do with code customizations, can I still run my business with that? Or should I accept the costs of code customizations (don’t forget the hidden costs!) and stick to on-prem deployment for the moment?

By the way, I don’t want to say that Dynamics 365 Business Central is less optimal compared to on-prem deployment. From my experience, I can tell you that setting up the full Dynamics 365 experience like integration with Office 365 or PowerBI in an on-prem scenario is not that simple and straightforward. Want I want to say is that you have to make a choice what is more important: get the full experience of an online solution and accept limited customization possibilities or get the full flexibility of an on-prem deployment but accept the complexity and the costs.

Secondly, although it would be technically possible for end-users to create tenant extensions themselves, I would really recommend to handle this with care. To create extensions for Dynamics 365 Business Central you need to have in-depth knowledge of the architecture of the application. You don’t try to tune the engine of your car without proper knowledge, don’t you? So don’t customize the software solution you run your business with without exactly knowing what you do! The possibility to adjust Dynamics 365 Business Central to individual needs of customers is meant to be used by Dynamics 365 Resellers in the first place.

More information on customizing tenants can be found here.

Developing and deploying a tenant customization

Some important notes about developing and deploying a tenant customization.

You should develop with VS Code against a Dynamics 365 Business Central sandbox or using a Docker container. With a Docker container you will also have the possibility to develop for the next version.

Make sure to set the correct number range in your app.json and to apply to correct code analyzers. When you develop a tenant customization, set the number range to 50000-99999 and use the PerTenantExtensionCop code analyzer. When you develop an app for AppSource, then set the number range to the range you got assigned. And then you should use the AppSourceCop code analyzer. Look here for more info.

Deploying the tenant customization is done through the Extension Management page (no PowerShell needed!). You can just upload the extension package file. During this process, you will have the possibility to deploy for the current version or for the next version. More information about this can be found here.

Here are some screenshots of the upload extension wizard:

Who says that Dynamics 365 Business Central is a closed application? It’s rather the opposite!

My last blog post was about the possibility to create tenant customizations for Dynamics 365 Business Central. That raised some questions about licensing. Which I perfectly understand considering where we come from. With Dynamics NAV on-prem we have to license every single object. A base set of objects like Pages and Reports come for free with Page Designer and Report Designer, but if you want to have extra objects you have to first wire some money to Microsoft. So the question how that works with Dynamics 365 Business Central is a very valid question indeed.

Disclaimer: what I write here is the current status to the best of my knowledge. Microsoft could decide to place restrictions or even completely remove the possibilities. It’s unlikely to happen, but anyway, don’t shoot the messenger…

Dynamics 365 Business Central allows for three different number ranges to create extensions.

Tenant Customization

Here we are talking about extensions created in the 50.000 – 99.999 range. Like I explained in my previous post. For those who find it hard to believe that all these objects are just for free: this is similar to the SPLA license which also includes this object range for free.

Extensions created in this number range cannot be published on AppSource. The only way to deploy a tenant customization to Business Central is to upload it through the Extension Management page. These extensions can also be deployed to a on-prem installation, as long as the license includes the objects being used.

ISV number range

An ISV can choose to create an extension in the number range they already have for their on-prem solution. This is the existing number range 1.000.000 – 60.000.000 for ISV’s and it requires an RSPA and CfMD to be free for the ISV. This number range is usable both on-premise and on Business Central.

This comes close to business as usual, right?

So ISV’s could choose to use their existing number range and convert (parts of) their existing solution to an AL extension. This AL extension will then be usable both on-premise and on Business Central. What’s more, it will be possible to publish these extensions as an app on AppSource. That means there is no need to split development between cloud and on-prem.

The pricing and payment can be similar as it is today when delivered directly to an end-customer. But when published on AppSource it is recommended to include monetization options like running in trial mode and integrate with a payment provider.

Please note that at this moment AppSource is not accepting extensions in the ISV range, but it will be implemented soon. Wait for communication from Microsoft about this. However, it should not stop you to start moving your solution to extensions!

AppSource number range

The number range 70.000.000 – 75.000.000 was the original number range for apps for Microsoft Dynamics 365 Finance and Operations, Business Edition (last time I use that in full writing…). This number range remains and should be used for apps that will not be available on on-premise. These apps are ‘born in the cloud’ so to say.

At this moment AppSource doesn’t have a payment process. The app needs to have a built-in payment process. Which is another topic I could talk for hours about…

More information

More information can be found on this landing page: Build Your Business on Dynamics 365 Business Central.

Or directly in these PDF files:

• Getting you started with Microsoft Dynamics 365 Business Central Add-on Apps
• Developing and publishing Microsoft Dynamics 365 Business Central Add-on Apps

Publishing on AppSource

This is the most preferred way to get an app. Both for the customer and for the ISV. For the customer AppSource is the first place where they can find solutions to extend Business Central for their business. They can trust that these apps have gone through a validation process. A vetting process that checks if the app is designed for Business Central, follows the UI guidelines, has the same end-user experience as the whole application and, last but not least, is backed by a support process.

For the ISV it is important to be on AppSource because it allows them to reach a wider audience. Microsoft will put AppSource in the spotlights and ISV’s get that marketing power for free. Being visible on AppSource also proves the ISV to be trustworthy, it comes with a positive image.

Keep in mind that there is a validation checklist to publish an app AppSource. The linked PDF’s above do have more information about the technical and marketing validation checklist. The technical checklist can also be found here.

Compare the rules for publishing and app on AppSource with the rules for CfMD and you will see a lot of similar requirements. There are also differences of course. For AppSource you don’t go through the CfMD process that is available for on-premise solutions. The rules are tested during the app validation process after you have published the app.

Final remarks

I wouldn’t be surprised if ISV’s and VAR’s are going to ignore AppSource because they think they can continue to do what they do today. Well, technically it is a difference because AL is not exactly the same as C/AL, we all know that. But from a business perspective it looks like they could work with Business Central as they do today with on-premise or private hosting.

But I consider that a wrong approach. It ignores the benefits of AppSource. Partners who do that do not take the opportunity to reach a wider audience. They sell themselves short by ignoring the potential volume they could have.

Another very valid question I got about these mix of extensions: what about naming conflicts? That’s a complex issue if you want to allow conflicting names and solve that silently in the background. The most simple solution is to not allow conflicting names. The same applies to Dynamics NAV, you can’t import a fob file with conflicting names, without manual steps, can you? With extensions it’s the same story, you can’t deploy an extension with an object or field name that already exists. So make sure to use unique names, something that ISV’s are already used to with their solutions.

Update: Dmitry Katson reminded me of the possibility to reserve your prefix / suffix for Dynamics 365. More information can be found here, including an email address to send in your prefix / suffix.

That’s it, I hope this clarifies object licensing with Dynamics 365 Business Central. I would say there are no reasons left to not even try to move your IP to AL extensions and try to get your part of the big pie Microsoft is cooking.

Last week I attended Directions North America 2018 in San Diego, CA. It was the best Directions NA I’ve ever attended. I’m not going to go over all kinds of “what’s new in the next version” because others already did, and probably better than I can. Like Waldo did on his blog (he has a good memory indeed).

Some people think there was no big news at Directions NA this year. I guess it depends from what angle you look at it. Things are currently moving in a predictable direction. Business Central gains traction, it has a focused team and it is evolving to a real cloud-first business application. No doubt partners are following it and embracing this. Over the last year we have had the opportunity to help many partners to get ready for Business Central and we see partners making the change right now.

For me, the real big change was announced a week before Directions NA. We had a MVP meeting with Microsoft in which they shared that they were really close to move completely to AL and VS Code and leave C/AL and C/SIDE behind. But we weren’t prepared for what happened during day 2 of Directions: they showed it! Apparently, they got it working over the weekend and couldn’t resist to demonstrate it during the second keynote.

BOOM!

They even updated the roadmap after the first keynote to reflect this new step that is going to happen in the future:

As you can see, the plan is to move in 2020 to AL and VS Code only and also to end support for the Windows Client. Well, the news about the Windows Client wasn’t really a surprise, but abandoning C/SIDE is really a game changer.

Surprisingly, it didn’t really get a lot of attention. During a strategic session with Marko Perisic, there ware no questions all about it (ok, until I asked to give us some more insights what this means for our future).

Huge impact

Two years ago, I already wrote about ‘the new developer experience‘. At that time I thought it was going to take 3 to 5 years for Microsoft to completely move to AL. Apparently, they are on the lower end of my estimate. Let me explain why I think this is a huge change and why you should start preparing for it right now.

We have seen quite some changes in the past that had a big impact on how we developed for Dynamics NAV. I’m sure most of you remember the move from Forms in the Classic Client to Pages in the Role Tailored Client. And what about moving from classic reports to RDLC / Word report layouts? Both changes had a huge impact on the developer ecosystem as we had to learn new technologies and tools. There were even developers who chose to not follow along and moved to a different position or completely out of the Dynamics channel. Luckily, these were only a few and the most of us are still around.

The change to AL and VS Code is not different. We will be forced to learn a new way of developing. The AL Language has for sure a lot of overlap with good old C/AL, but the way we develop is completely different. With a code editor that is used by many others, with Source Code Management in a way we could only dream of with C/SIDE. With a deployment model that is different and new possibilities like Continuous Integration and Continuous Delivery.

The change to this whole new way of developing for Business Central shouldn’t be taken lightly. Based on so many workshops I’ve delivered over the last two years, I can tell you that NAV developers are eager to learn, but it takes time to adapt and change the current way of working.

Let me share a number of thoughts about the move to AL and VS Code.

How it was done

The way how the move to AL is achieved is surprisingly easy to understand for everyone who has worked with Extensions v2. The base application, which was only delivered as C/AL objects in C/SIDE is now an app on itself. In C/SIDE you will only find some codeunits in the 2-billion range to provide platform level triggers. In Business Central October ’18 release you can already see this because Codeunit 1 was removed in favor of these new platform Codeunits.

All objects were converted to AL, which results in a big AL workspace with about 5800 objects. After compilation, which only takes about 2 minutes (compare that to a full compile in C/SIDE!) the output is an app file that can be deployed on the platform. This is the new base app.

This also means that Microsoft will use AL and VS Code as their only development environment for maintaining the base application. Which is a very good thing, in my opinion.

Modifying base app

It was made clear that we will be able to get our hands on the AL source code of this base app. Just like we can with objects in C/SIDE, we can modify the code of the base app and create our own base app.

But be careful! I consider this to be a risk! We all know that one of the beloved key features of Navision was it’s flexibility to modify code. But this key strength is also it’s weakness. There are many customers with bespoke customizations who are now stuck with an old system because upgrading became to expensive. Please follow the conversation between Guus Krabbenborg and James Crowter about this particular topic.

In my opinion, being able to modify the base app potentially introduces the old way of doing customizations. You should certainly do your utmost to stay away from that situation! Now that we have extensions technology, we should make use of that and benefit from it.

There are partners who do have a big vertical, who added thousands of objects to the base application, which can’t just be converted to an app in a week, or a month, or even a year. Those partners will benefit from this new possibility, because they will be able to turn their big vertical solution into a complete new base app and benefit from all the powerful features that come with AL and VS Code.

And then you have customers who deliberately choose to not go into the cloud. There are companies who have reasons to keep everything on-prem or privately hosted. And while you can still use AL code to deliver apps for those customers (if they are running Business Central), it is quite tempting of course to just go into the base code and make modifications right there. Although I think you shouldn’t, I would expect there will always be partners who keep doing this. Well, even those partners will need to switch to AL and apps. They will need to create there own base app, for that particular customer or group of customers.

Splitting base application into modules

A question that was asked during the strategic Q&A with Marko Perisic at Directions: are you thinking about splitting up the base app into multiple modules? And the bold and clear answer was: Yes.

Think about it for a moment: what if the base app is not one app, but consists of separate modules for Generel Ledger, Sales, Purchase, Inventory, Manufacturing, etc.? It makes so much sense!

Back to earth… the very valid question is of course: how to get there? I mean, this is like doing maintenance on a flying plane. This level of refactoring code is going to have a huge impact on everybody. Probably the new Telemetry feature it going to help here, because is allows Microsoft to see what objects and functions are used the most, and what less. But then again, I’m sure this is going to be a big change that impacts everybody!

As mentioned on this GitHub repository, you can even contribute to the modules that are separated from the base application:

Going forward, an increasing part of our application business logic will be modularized and extracted into extensions, which will be published onto this repository; this is true for both application add-ons as well as application localizations. The core application thereby becomes thinner, better extensible and better localizable. The extracted modules become open for contributions, are replaceable in the application with substitutes, serve as starting point for verticalizations of the modules or serve as samples for extension development in general.

What is unclear at this moment

There are certainly a number of issues that need to be addressed before Microsoft will switch to AL-only development. To name a few:

Data upgrade
As you may know, tables that are created as with an extension are not exactly the same as tables created with C/SIDE. The table name contains the appid and you can’t see them from C/SIDE at all. There needs to be an upgrade path to move data from ‘old’ existing tables to new ‘AL’ tables for the base application.

Migration of code
The conversion from C/AL to AL did involve a conversion tool and some manual work.  

Deploying a new base app online
Another question that arises, when talking about changing the base app: will we be able to run a modified base app on the online Business Central platform? Answers from Microsoft suggest that it is going to be possible. But I’m quite sure it will come with certain requirements. For example, the base app uses .Net code while we were not able to use it with Extensions for Business Central online. Would we now all of a sudden be able to publish a base app that uses .Net code? I don’t think so… I would expect (but this is an educated guess) that modified base apps will be published on a dedicated server environment with a different price tag and you probably might need to be at a certain level in terms of users or license revenue. Time will tell…

Call to action

Let’s summarize the message into a number of actions you should take today.

Move to Extensions
If you ignored Extensions until now, then it’s about time to wake up and start moving your solutions to Extensions. With as minimal footprint in the base application as possible. Maybe you miss events in the base app, request them here: https://github.com/Microsoft/al/issues.

Learn to leverage VS Code & Source Code Management
Do not only start with moving to AL. Also learn how to use VS Code and Source Code Management and apply a strategy for working with continuous integration and continuous delivery.

Learn how to use Test Automation
Didn’t mention test automation above, but as soon as you start building apps for AppSource, you need to build automated test packages. But why not use it as a default, for both online and on-prem? It can save you so many problems and so big time…

Conclusion

Changing the base application into an app will force partners to move to AL development with VS Code. Going forward, there is no way to avoid that. Another huge change, but certainly one that brings great benefits to all partners!

A question I get quite often during my AL development workshops or coaching sessions for partners is this: can other apps access data that is stored in my app?

And the short answer is: yes, they can. There is no way to avoid that.

Let’s not go into the discussion why partners want to prevent others from peeking into data stored in their tables and or to see there table structure. Every partner has their reasons for that and it’s an endless debate between pro’s and con’s.

But let’s be clear about one thing: the data in the database belongs to the customer, not to the partner. It’s their data and nobody should prevent the customer from getting access to their data. Well… that’s my opinion at least… Anyway, there might be situations where you still want to protect data. Let’s look at a few examples.

Storing license data

AppSource doesn’t provide any way to license or monetize your app. So partners are left with two options: either give away their app for free (not an option many would say…) or to build in a license model. Which means they have to store license data somewhere. I think I don’t have to explain potential problems when customers can get their hands on that data and tamper with it. So the question is very valid here: how to store data out of sight of anybody else.

Storing access keys

Another example is when your app has an integration with external servers, e.g. a web service. You don’t want to store any access keys or passwords in tables that can easily be accessed by others.

These two examples can be easily be extended with others. But where it comes down to is the question: how to store sensitive and confidential information.

Isolated Storage

This is where the new feature of Business Central comes in: Isolated Storage. This feature is briefly described here.

Let’s first make clear what Isolated Storage is not: it’s not a property on a table that indicates that a table is only to be accessed by the app that creates the table. It is not even close to a table at all.

So, what is Isolated Storage? It provides a way to store key / value pairs in the database that can only be accessed by the app that stores that data. The value is simply any text value, not limited to 250 characters. It is stored as a BLOB in a new non-company table called ‘Isolated Storage’.

DataScope

Data in the Isolated Storage has a scope. The scope determines who has access to the data. By default the data is accessible to all users who run the app. But you can also limit it to a particular user or to a single company. The access level is set with a new datatype, called DataScope.

When you store a value into the Isolated Storage, then you have to indicate the scope. The scope determines who will be able to read the data back from the Isolated Storage.

• Module – Globally in the whole app, across all companies and users
• Company – By all users but limited to the company that is used to store the data
• CompanyAndUser – Only in the company and only by the user who stored the data
• User – Only by the user who stored the data, but across all companies

Isolated Storage API

Now that we have seen that we can actually store data with different access levels, we need to look at how to store and read the data.

There is a new API available: IsolatedStorage. This API has functions to store, read, delete and check data in the Isolated Storage.

I guess the functions speak for itself…

All functions need a key to identify the value you want to store or get. This key is a text and can be anything you choose. The maximum lenght of the key is 200 characters. You can use a GUID or just a readable key or anything that makes sense to you.

All function accept the DataScope as an optional parameter. If you omit DataScope, then the value DataScope::Module will be used.

The data you store is a text value. This could be a simple string or a more complex piece of text like XML or JSON. It is highly recommended to encrypt the value before storing it, which will add another level of security.

Example

Here is an example of how to use IsolatedStorage. This example exports the records of a table called License to JSON, then encrypts the Json value and finally stores the encrypted text in the Isolated Storage.

The function GetStorageKey just returns a GUID:

And with this function the value is read back into the table.

Do not create a codeunit with public functions that expose the sensitive data you store in the Isolated Storage. If you do that, then the Isolated Storage becomes useless, because one could easily create a dependent app on your app, call that function and get his hands on the sensitive data. Only data should be exposed that is safe to be exposed. So think twice about your code that handles the Isolated Storage.

In examples above, the table is declared as a temporary table in a Codeunit. The data never leaves the Codeunit and the Codeunit has only functions to tell if a valid license exists. With that approach, the data is completely isolated and nobody could tamper with it.

Final thoughts

I would be even more happy if it was possible to have really isolated tables instead of only storing text values. However, I do understand that it would require a way more complex modification to the platform because it affects features like RecordRef or the option to run a table in the web client. And since isolated storage will probably only be used for specific circumstances, like storing licenses or other confidential data I can certainly see this feature as a solution that fit our needs.

It would be nice to get a generic function to export and import table to JSON though… Now I had to create a function myself to read and write every single field to a JSON value.

Enjoy this new feature and don’t forget to tell Microsoft if you have any improvement for this feature!

Recently I received a number of questions from people who were using the first self-monetization example code I created about a year ago. They received an error message when installing the app: Callback functions are not allowed.

This error happened because there is code in the install codeunit to do an outgoing HTTP call to a webservice. In the same period, people started to report that the sandbox environment showed a popup when they triggered an outgoing HTTP call from code.

The reason

Let’s first look at the reason why this popup happens and why there is an error message during installation. Microsoft introduced the possibility to create an online sandbox that contains a copy of the production data. To read more about that feature, refer to the documentation about the Business Central Administration Center.

Because the sandbox can now contain production data, including all settings, there must be a way to prevent unintentional outgoing webservice calls. As you can imagine, it could potentially lead to all kind of problems if a test environment is going to to webservice calls as if it is coming from a production environment. So for that reason, the sandbox blocks outgoing HTTP calls by default. This is also mentioned in the documentation of the Business Central Administration Center. And because the docker sandbox containers behave as if they are an online sandbox, you also get the same experience with blocking HTTP calls.

So that’s where the popup is coming from. The user can now select what to do. Is it safe to do the outgoing HTTP call or should the app be blocked? For always or only once? Please note that the setting you choose here applies the all HTTP calls from that app. So be careful with what you choose. And a special recommendation to tell your customers about this!

But what about the error message when you install an extension? Well, that’s easy: the platform recognizes an outgoing HTTP call and wants to present the popup to the user. However, if you install an app from VS Code or with PowerShell, then you don’t have a GUI. So the platform can’t show any popup. That’s where the error message comes from: ‘callback functions are not allowed’. This is the same error message as documented here. I have suggested on GitHub to just block the call in these cases.

How it works

There is a new table called “NAV App Settings” which has a field “Allow HttpClient Requests”. When the user selects one of the Always options (Allow Always or Block Always) then a record is inserted into this table with the field set to true or false.

You can also manage this setting from the Extensions Management Page. 

This opens the configuration page where you can change the setting for the app.

What happens when an outgoing HTTP call is detected? Then the platform checks the table “NAV App Settings” if there is a record for this app. In case there is a record, then platform will either block or allow the HTTP call, based on the setting. When there is no record in this table, then the popup will be displayed to the user. Or the error message during install…

How to tweak this behavior

It is possible to create that record from code and with that prevent the popup from being displayed. Here is a code example how to do that.

As you can see, the code first detects if it is running in a sandbox environment and only runs in that particular case.

This code was inspired by a suggestion that was done in this issue on GitHub. It could be that Microsoft blocks access to this table in the future. Anyway, be very careful with this code! You should only do this when you are absolutely sure that this is safe to do. For example, in the new demo for self-monetization, I have piece of code as shown below. In this case, you can be sure that a call from the sandbox will end up in the test environment of the webservice. Other webservices might use different URL’s for test and production API’s.

Currently there is a bug when cleaning up the data. If you completely uninstall an app, including data, (e.g. with Sync-NAVApp -Mode Clean) then the record still remains in the NAV App Setting table. Also, the Recreate option for schemaUpdateMode in the launch.json does not clean that record. If you are testing your code you should be aware of this. The issue has been reported on Github.