Category Archives: BusinessCentral

Business Central; Developers, Developers, Developers

A new version of Business Central is around the corner. The codename is BC16 or 2020 Wave I. Both are the same thing.

I think it is safe to say that Business Central is a great succes. In the competing world of Cloud Business Solutions it is the most flexible product and the customer base is growing rapidly.

Business Central has a fantastic user interface and the extensibility model is next to nothing else out there.

Last week I was talking to a reseller of Business Central on the west coast of the US. He said he was small reseller since he only sold 10 installations in 2 years. Yes, he was new to BC and had no prior NAV experience.

Knowing that in the old world NAV resellers often only sold 3 licenses or less per calendar year I had to laugh a bit.

Cloud brings both challenges and opportunities that are beyond anything we have ever seen in our ecosystem.

I can see the opportunities from my perspective as a freelance developer. The demand for AL developers is insane. In Europe it seems to be doing ok, but in the US they are screaming for resources.

As for the reasons I can only guess, but it seams that growth of Business Central is happening most from outside the traditional NAV world. New partners are jumping on the opportunity to then find out that implementing BC almost always means implementing a few changes that require per-tenant extensions.

Many traditional NAV resellers still struggle with Business Central because of two reasons.

  1. Their IP is a big mess
  2. Their COGS is too high

Also, almost always they know nothing about the Azure stack and integration with Office 365.

In my opinion it’s time to change but this seems very difficult. NAV partners have a very expensive (pre) sales department that is funded with large license revenues. Their Developers have been rewarded for 20 years to deliver crappy hacks in C/Side that only had to work as quickly as possible to then start on the next hack.

I’ve seen situations where it was considered “normal” that the service desk employees of a partner logged into a customers system almost on a weekly bases to fix data with reports and customers actually pay premium service for this.

Grim Reaper in the NAV ecosystem

It seems so hard to change, that many owners of traditional NAV resellers choose the easy way out. They sell their company to investment companies.

This is probably also due to the current economy where interest is at an all time low, stock markets are way overpriced (although “Corona” settled that last week) and money is looking to be spent.

Titanic or Oil Tanker

It’s not the first time that the faith of our ecosystem is influenced by global economy. When the Three Tier concept was presented the world decided to have one of the biggest recessions in history.

If you had asked me two or three years ago I would have compared Microsoft to Titanic. In all their glory they wanted to go so fast that they ignored all the rules and headed straight for an iceberg.

Now that Business Central is being picked up by new partners and a (small) subset of the existing NAV ecosystem I am a bit more positive. Actually a lot more possitive.

Today I would compare Microsoft more with an Oil Tanker that is trying to change course but it is going insanely slow. People at the bridge are giving orders to change direction but by the time this is happening it’s (almost) too late.

Now is the time!

It’s easy to say to existing NAV partners that they are too late, but that is unfair and not true. The ERP world is moving a lot slower than Microsoft wants. ERP is not implemented at startups but at companies that have been in business for a longer period of time.

Business Central 2020 Wave I contains a few changes that are important for the old NAV ecosystem. The most important ones are the actual implementation of Enum’s, the introduction of flexibility of the sales pricing module and integration with Common Data Services.

Microsoft is listening but change is slow, but slow sometimes is good.

Oops, they did it again

The previous release of Business Central caused a massive riot because Microsoft broke the majority of Apps published by their partners on the AppSource. This resulted in a lack of trust and the compeition even started to use this as selling against Business Central.

Microsoft made a drastic, but important executive decision to promise not to make breaking changes anymore.

Unfortunately this seems to be an impossible promise since the enum implementation again breaks existing extensions, although I think it will be a minority this time. I haven’t checked this however.

Since Wave I 2020 is not officially released Microsoft might actually decide to fix this. Let’s see what will happen.

Small NAV Partners, now is the time!

A few things need to happen.

  1. Stop paying sales people that cannot even do a proper demo. They are not needed anymore. Instead you need industry specialists that understand the customer.
  2. Stop calling everyone who can make a change to C/Side a developer.
  3. Embrace Azure

What if they don’t?

What we see in the US will happen in Europe too. New partners will start selling Business Central that don’t have the legacy. Legacy in expensive sales people and legacy in bad code. Even legacy in stupid customers who accept crappy solutions.

It’s time to decide which side of the Business Central ecosystem you want to be part of, because Business Central will continue to be the best ERP in the cloud, with or without you.

Developers don’t have to be affraid of the future. If you are willing to let go of writing fast and crappy solutions and invest in repeatable quality apps the future is fantastic.

Tip #59 | Multiple Start Configurations in Visual Studio Code

When developing extensions for Business Central you have a wide array of publishing options to choose from.

My most used options when working on the ForNAV Customizable Report Pack are our Sandbox and Docker.

Testing is best on the Sanxbox for two reasons. First because all the Azure Active Directory stuff actually returns something which is useful for licensing scenario’s. Second because you can easily share the result with the team since everyone is on the same Sandbox.

Docker is useful when you don’t want to test on current but on an older or vNext instance.

Lastly it’s also possible to install Business Central on your own infrastructure altough this is a dying species.

In your Visual Studio Code project you can specify how you want to publish in the launch.json file but did you also know you can setup miltiple configurations and then choose one at the time of publishing.

This is how it could look:

{
     "version": "0.2.0",
     "configurations": [
         {
             "type": "al",
             "request": "launch",
             "name": "Docker",
             "authentication": "UserPassword",
             "startupObjectType": "Page",
             "breakOnError": true,
             "launchBrowser": true,
             "server": "http://bcsandbox",
             "serverInstance": "NAV",
             "enableLongRunningSqlStatements": true,
             "enableSqlInformationDebugger": true,
             "schemaUpdateMode": "Synchronize"
    },
    {
        "type": "al",
        "request": "launch",
        "name": "Microsoft cloud sandbox",
        "startupObjectId": 6188475,
        "startupObjectType": "Page",
        "breakOnError": true,
        "launchBrowser": true,
        "enableLongRunningSqlStatements": true,
        "enableSqlInformationDebugger": true,
        "schemaUpdateMode": "Synchronize"
    }
] 
}

Now if you publish your code Visual Studio Code will ask for the correct configuration.

NOTE: Your credentials cache is shared accross these configurations. You will need to clear the credentials cache if you switch.

TIP: You can also use this to create a seperate config for Syncronize and Recreate.

Episode 4 – BC Fall Release | Give Feedback

Feedback is critical for Microsoft to improve Business Central and all of their other products.

For this reason a preview is published of the upcomming release this fall. You can install this using Docker and I’ve been told a DVD will be made available soon.

This release will be the biggest change since the introduction of the Three Tier model and Role Tailored Client and fits into the row completing the move to SQL Server and Dos to Windows.

The move to AL is probably the smallest change here. AL has been running side-by-side with C/Side for a few releases and is proven stable.

More important are dropping the Windows Client and the refactoring of parts as described here. https://github.com/microsoft/ALAppExtensions

I strongly encourage every partner to reflect their solution against the preview.

Learn from the past

When Microsoft introduced Pages and the Role Tailored Concept the majority of the partners ignored the first wave and waited until they persieved it as more mature.

However, when the majority moved it was too late to give feedback as the base architecture was carved in stone and decisions were made that were irreversable.

Running multiple platforms side-by-side like in the days with SQL Server and Native, or Classic Client and RTC is too expensive and partners are using it as an excuse not to move forward.

Ask for help

Don’t reinvent the wheel. Help is available in a large quantity of resources. Getting started can be hard.

An example is the blog from Saurav who explains in clear steps how to get started with clear screenshots from the docker preview.

https://saurav-nav.blogspot.com/2019/08/how-to-setup-business-central-2019.html

The Penalty for sitting it out

Even though some may disagree, upgrading Navision has always been a very easy and straight forward process, especially if you did frequent small steps.

It was harder if you waited longer, but a direct upgrade from Navision Financials 2.01 to version 4.3 or 5.0 were no exceptions.

With the introduction of 2009 a mandatory in-between step was introduced that everyone has to go through which IMHO is the real reason upgrades got a bad reputation.

NAV2018 or Business Central Spring release are other examples of mandatory steps to go through before upgrading and moving to the cloud becomes harder the longer you want as will the price increase.

Dropping out

When the gap becomes too big the chance of dropping out increases and as a community we should do anything we can to prevent that.

Episode 3 – BC Fall Release | Finding Stuff

UPDATE!! Microsoft is listening!!

Big news, it seems that Microsoft is fixing the issues we’ve found in our App for AppSource. Both the functions on the TempBlob and the Language table will be added back!

But also, let’s continue where we left off with the previous episodes because there are more challenges that won’t be fixed. Let’s see if we can fix some reference problems.

Before we do that, please allow me to repeat that despite these breaking changes Business Central remains by far the best customizable ERP system in the cloud.

For this blog post I’m going to fix the errors in the ForNAV Modern Object Designer as Extention. Benefit is that you can do this yourself too. Just download it from http://www.fornav.com, convert it using the fornav converter against spring and than connect it to the Docker. (end of advertizing ForNAV)

Issue #1 – Renamed Codeunits

After connecting the extension to Fall we see that the codeunit NavExtensionInstallationMgt is missing.

However… this is not true, and very confusing.

Reason for this, is that Microsoft RENAMED a codeunit (they actually renamed a bunch). Now in the old days this was NOT DONE, even though in this case C/Side would have handled the rename for us because C/Side works at compile time with object ID’s. This is because C/Side was developed in the late ’80ies early ’90ies when memory was expensive.

Visual Studio Code works with object names. So how do we figure out the new name for this codeunit???

The obvious answer here would be to install the ForNAV Modern Object Explorer but hey, we are fixing this now right? So let’s go nerdy and hack into SQL and see what’s going on there.

In C/Side we can see that the Codeunit ID is 2500. But Fall does not ship C/Side.

Let’s see what we can find in the SQL Server database.

Accessing SQL on Docker

If you run Docker you can still access SQL via Management studio. An SA account is created with the same password as your NAV user. The SQL does not have an instance, so just connect to the IP address of the container.

The default name of the database is Financialsw1 which I think is funny and a remainder of our temporary product name. If you want you can also relate it back to Navision Financials.

First place to look would be the Object Table. So let’s run a query.

Select * from [Object]

No results, which makes sense because there is no more C/Side and all code is in an Extension.

SELECT [Object Name], * FROM [NAV App Object Metadata] where [Object ID] = 2500

So let’s see what we can find in the NAV App Object Metadata table

Here it is, and now it is called “Extension Installation Impl”. So let’s try that!

Issue #2 – Protection

So we’ve found the codeunit’s new name. Yeah! Let’s change it and see what happens.

One of the functions started working, but one did not, and the codeunit still does not compile.

The reason for this is the protection level of the codeunit, and a broken contract. But how do we investigate that?

If you try Go To Definition on the object, you still get a “D/AL” file with no code, and it seems like Microsoft is not shipping the AL code in the App file on the Docker Container for the System app. Also we don’t know yet if it is in the system app.

Back to SQL Server

select * from [NAV App] where [Package ID] = '6418C5AF-4672-43DA-AD73-FF140FBBD537'

From the previous query we know that the App the object belongs to has ID 6418C5AF-4672-43DA-AD73-FF140FBBD537.

If we query that app in the NAV App table we can see it is system.

Now the next thing we need to do is clone the GitHub from https://github.com/microsoft/ALAppExtensions. This will get us the sourcecode, but Go To Definition does not work.

I’ll make it easy for you, the code is in https://github.com/microsoft/ALAppExtensions/tree/master/Modules/System/Extension%20Management/src

Codeunit 2500 has a property called Access which is set to Internal. Even if my extension is set to OnPrem I cannot access this function.

Step 3 – The Fix

In my case, the fix is easy. Just clone the code from CU 2500. It’s a fix I hate but IMHO unavoidable in this case.

Step 4 – Compile, Yes!!!

When you now run the MOD (Modern Object Designer) and filter on Object ID = 2500 you can see why I like this thing so much…

And then… No….

Now I should be able to export the object from the MOD but when I try I get this error?

And for a good reason, look at the variables!

Remember, we don’t have a Windows Client anymore? So we cannot run DotNet on client either.

For this I need more time to figure out a solution but I would also ask Microsoft to please enhance the compiler. I should not be able to compile and publish this extension against FALL release.

Episode 2 – BC-Fall Release Wave II | Checking Your Extension

Before we dive into the list of (breaking) changes that I’ve discovered so far, I will first explain how to check your extension against the preview of the fall release.

This is mostly interesting for those who are on AppSource or partners who have refactored their IP into On Prem extensions. I’m going to assume all of them have access to the Ready to Go program. If not, send me a message and I’ll help you onboard.

In another episode we’ll dive deeper into making your own Base App run on System.

So assuming you have a running service tier (on Docker or via de DVD on your machine) we need to make a few changes to the App.Json.

NOTE: You first need a new VSIX compiler. Download this from the Docker or DVD.

Plaform & Application

The Platform version needs to be changed to 15. The application needs to be removed. There is no more application.json file with symbols.

Now the dependencies need to be set. There are (most often) two apps needed here

BaseApp

Not really a “Marketing Friendly” name for the whole old Navision solution converted to AL code, but that’s it actually.

GUID =  437dbf0e-84ff-417a-965d-ed2bb9650972
Version =  "15.0.0.0"

Essentially you’ll get the same information as in previous versions with the app.json file generated by the finsql.exe but the .app file contains source code. I’ll get back to that in next episodes.

System Application

No consistency here. You would expect it to be called SystemApp, or BaseApp to be called Base Application. 😉

This is not to be confused with the platform .app file you’ll still get too. This still contains the 2 billion system objects that just are magically there (I think still maintained by finsql.exe when generating the database)

The new System Application is actually what you can find here on GitHub. But this seems not to contain source code. Again, more in a next episode.

Some examples of application parts that are moved to System Application are

  • TempBlob
  • Language
  • Tenant and Azure AD management
  • DotNET stuff
  • Etc.
GUID =  63ca2fa4-4f03-4f2b-a480-172fef340d3f
Version =  1.0.0.0

Your app.json file will now look something like this

Delete Old Symbols

It’s always a good idea to remove old symbol files before moving on. The compiler always looks at the latest version but here it might get confused because of all the moving parts.

Download new Symbols

Now just get the new symbols and your window will look something like this and starts showing you the warnings and errors.

Please note this is the result after some cleaning up. I’m not finished. I’ll write more about TempBlob and other refactoring challenges later.

See you in the next episode.

Episode I – BC-Fall Release Wave II | The Upgrade Dream Shattered

Be careful what you ask for, you might actually get it.

This phrase illustrates what we will see when Microsoft releases Business Central Wave II this October where C/Side is removed in favor of Visual Studio Code, The Windows Client discontinued in favor of the Web Interface and the old Navision application is broken into two parts and very heavy refactoring has taken place.

For years, we as a community have been asking Microsoft to modernise NAV in order to be more attractive to young developers and move to modern development methods.

Wave II is the result of a plan that started execution many years ago and the managers who executed the plan no longer work at Microsoft. This is scary and in a series of blog posts I’ll illustrate the challenges you can expect as a partner when you try to move your solutions to this new platform.

Today I’ve analysed the impact of the refactoring done my Microsoft on the AppSource solution I’ve developed for ForNAV. The Customizable Report Pack. After my analysis Michael Nielsen and I carefully concluded that Microsoft in our estimates has broken 99,9% of all solutions on AppSource and each and everyone will have to go through a certain level of refactoring.

In the next few blog posts I’ll explain some of our challenges based on what I’ve found in the new System App that is publically available on GitHub. Our challenges with the new Base App are limited, but even if they were huge I think this is still under NDA and in private preview. Need to be careful here. Hopefully the BaseApp will be publically available by the time my posts reach this part.

The Upgrade Dream Shattered

Let’s get back to the title of the blog. This was not just there as click bait and I will elaborate on that.

Upgrading Navision has always be a challenge. I don’t think anyone in the community disagrees to call that the Achilles’ heel of our framework so when Microsoft management used this as a reason to change we do development in NAV not a lot dared to think about complaining here.

In the same time a our community started to rant that NAV development was not modern enough and they demanded change.

F#$^@K

The idea was to make upgrading easier for both Developers/Partners and Customers. As long as partners would migrate their solutions to an extension life would be easy. If customers moved to BC-Cloud they would be upgraded automatically.

This has consequences that some might say are unexpected and others would clame “I told you so”.

From a partner perspective the first crack occured when Codeunit 1 was removed. Not a major change but enough to keep everyone busy and break most of the solutions out there. It made it especially hard on ISV’s that try to keep a codebase in synch with many NAV versions out there.

With this Fall release it becomes clear that there is no such thing as a free ride. For example this line of code will no longer compile:

CurrReport.LANGUAGE := Language.GetLanguageID("Language Code");

Which all of us will recognise as being present in 95% of all customers customized reports.

The first extensions on AppSource are already rated with 1 star by customers because they simply don’t work or are not easy enough to setup. For most partners the economic value of an extension is not high enough to justify the cost.

From a Customers perspective it’s also not all sunsine. Customers may have asked Microsoft for easier upgrades, but nobody ever anticipated that if you have a large company with for example multiple locations your IT department can never keep up explaining new features and changes to users. Many companies still struggle with (sometimes older) users who simply remember to click on the third button from the right and if that is suddenly the second button they can’t do their work.

I had this experience myself. I use Exact Online for my accounting. Not out of free will but because my accountant supports it and I have to pay extra to run other software. When I got back from vacation last week I quickly wanted to check my balances and the dashboard had been completely redesigned. A quick check that should have been seconds became 15 minutes and it was even full of weird errors.

On top of this hard to manage experience most Business Central customers I work with have customizations. Per-Tenant extensions. In some cases they have their own Invoice report with, yes, the line of code that will change the language.

These per-tenant extensions will break with Fall Update and the customers will be forced to pay the partner for the upgrade, where in the past they had the option to continue on the old code at least until off-season where they have time.

So all concluded I think it is fair to say the marketing people can stop claiming that the upgrade problem has been fixed. It’s not and in some ways it has gotten worse.

As said this is just the first post in a series. My head is totally full of ideas and stuff I want to share.

Keep Positive!

Business Central is still by far the best customizable ERP system. Some things are getting worse, some get better. I’m sure at some point in time someone somewhere in a corner office in Redmond will start realizing that effort needs to be put into the places where we are getting worse. I hope this series of blogs will help both partners and Microsoft move forward.

Using Business Central as Microservice

Opinion, by Mark Brummel

Upgrading software is hard. Not because merging software is hard. It’s hard because people are creatures of habits.

Let me give you an example. We recently upgraded from NAV 2016 to NAV2018. This means big changes to the Customer Card. I’m fine with that. While in the process I moved my customizations to a Page Extension and I was a happy IT manager/developer.

Continue reading

Microsoft Dynamics 365 Business Central ≠ Microsoft Dynamics NAV

Opinion, by Mark Brummel

Continued from previous posts

My daily driver is a Defender. You tech nerds should know enough but for those of you who don’t, a Land Rover Defender.

It’s 18 years old. I bought it a few months ago after a lot of research. I needed  a car that can carry at least two adults, five kids, preferably more if they bring friends, a dog and luggage.

Continue reading