Walk with me through the learning curve of a developer who is new to Business Central. We’ll assume he/she is familiar with modern web development.
I’ll give Microsoft the WOW effect. When you spin up Business Central you get more than you bargained for. Where other frameworks show you a hello world and an example of how to call a web service and display the results in a table Microsoft really gives you an incredible experience to start with.
When you start customizing the User Interface of Business Central you’ll probably, sooner or later, end up with an extension that has some page extensions. If you look at them you’ll probably expect some HTML and some JavaScript.
This is not entirely true, but it’s not that far off. The way pages are constructed using metadata is not that much different from Razor or Angular and if you are familiar with JavaScript you can probably figure out how to read AL code.
So pages are approved. For a good reason because pages were designed as a first class three-tier citizen about a decade ago.
Next thing you want to do is to add some logic. Being a good developer you don’t want to add too much code to the UI so you start looking for the “back-end” system. Where do I write C# and how to I map this to these “pages”.
You’ve noticed that pages map to something that is called a “table”. This is weird, but ok, what’s in a name, it kinda looks like a class and there is mapping between this “table” and these “pages”.
A table looks like a class. It has properties, although they are called “fields” and there are methods which are called “procedures”.
Then you browse further in the documentation and discover a “codeunit” object. Now you are completely confused because a table and a page can be mapped somewhat to what you are familiar with, but this “codeunit” only allows for some procedures. There is no constructor, no properties.
By now you’ve probably bumped into the fact that all “objects” in Business Central need to have a number and to understand why you need to understand how things work after you’ve completed your extension.
I was probably wasting your time because there are no developers who are new to Business Central, there are only NAV dino’s trying to do what Microsoft asks them to do. Move to Extensions.
Off all the heritage that Business Central gets from NAV, object numbers are probably the most awkward one, especially if you take away C/Side where they make a lot of sense.
I’ve always tried to use Object Numbers to group my objects together that belong together. True, it’s not easy because you always have more pages than tables, but with a little help of Statical Prism and Upgrade Codeunits you can keep a clean schema.
Modern developers expect namespaces and true objects, not a file that is called an object because in the legacy system this file was stored in an Object table.
Most of you have probably given up by now but object numbers are important in combination with C/Side but they become extremely cumbersome in Business Central. Especially now that Microsoft is allowing the world to code for free in any object between 50.000 and 99.999. Who the f*ck is ever going to go through AppSource if you can sell your solutions for free!
But who is going to make sure object numbers are not already taken? How do you manage renumbering and updates?
In Dutch we have a saying, it’s neither meat or fish. Without C/Side object numbers don’t make sense and in an object-oriented world a table and a class are the same with the difference of not writing data to the database.
I promised you to explain it, didn’t I?
Many of you, or most of you, think that Microsoft wrote a new compiler for Visual Studio Code, but this is not true. It’s more of a pre-compiler or syntax checking tool that you run in the fancy modern world of VSCode where everyone can write a compiler.
When you publish your extension the real compiling begins and this is where “not much has changed”. This is not 100% true, but behind the scenes Business Central still generates C# code and these C# files get named with the object number.
If you manage to mess up the compiler, something I did last week when trying to create a Matrix Page, you’ll get a weird error message that C50000.cs does not allow to convert a NAVInt to a NAVDecimal or something along those lines.
Now, I’m not going to explain to all you kids what a Matrix Page is and where that came from, that is a bedtime story for another time.
I use Extensions and Visual Studio Code in my daily life. Or at least for a while, nowadays it’s more something in my weekly life. I try to avoid them when I can.
Not because they are bad or evil but because they slow down my productivity, and because I have legacy software.
Almost everyone I talk to agrees that programming extensions is slower and more clumbersome than C/Side. Not just the first few weeks.
When Extensions were first shipped I was stronly against the way they were architected. Microsoft simply slapped to existing pieces of technology together with a PowerShell sauce and sold it as the best thing since sliced bread.
It was even sold as being the only way to have decoupled code.
This, my friends, is where I think it went wrong.
With C/Side it is possible to have decoupled code, but it is not possible to have decoupled tables and pages. Only if you keep the delta files, which is the artifact Microsoft used as one of the ingredients for Extensions.
If Microsoft would support Table Extensions and Page Extensions in C/Side and if they would disable access to existing objects C/Side would have the same technical capabilities as Visual Studio Code.
It would in fact be capable of doing much, much more… I’ll get back to that.
Visual Studio Code has native Git integration. True. I’ll give you that. I’ve used it a lot but I have yet to find the true value compared to exporting text files from C/Side and moving them to Git manually.
With Visual Studio we cannot debug a live system, or look at an existing object. There is no solution for XMLPort Extensions or Report Extensions nor can you simply replace existing objects with new ones.
The true difference between Visual Studio Code and C/Side is how the solution is managed. Both tools have intellisense and can handle thousands of objects. If you create and maintain an Angular project in VSCode you’ll see that your project easily contains more objects than you can oversee.
Which is where the value of C/Side is imminent. Where Visual Studio Code expects you to only edit a handful, maybe up to 100 files, C/Side allows you to easily navigate accross every file in the solution and change everything.
Visual Studio Code is designed for modern decoupled applications that take dependencies on packages.
This is where we get challenged because NAV, Business Central or Navision (I don’t care how you call it) Is not a decoupled application. It’s a monolitical dinosaur that requires years to master and was never designed with decoupling in mind.
Most ISV solutions are also monolitical applications because we took the habbits from Microsoft and designed our solutions in an identical way. Microsoft must do it right, so let’s do it like they do.
I don’t blame you for making that choice. I did the same and it is the very reason I decided to keep working in C/Side. The solution I work with every day has over 2000 objects. Even though these objects are not depending on the Microsoft objects it is very hard to manage them in Visual Studio Code. You actually realise how smart object numbers are and how easy they make C/Side work once you don’t have them anymore.
VSCode is designed for smaller, decoupled projects. You can work with multiple projects open at the same time, but they work best when separated.
To get the most out of the VS Code experience you need to refactor your solution in multiple extensions and figure out the dependency schema.
Which is a shitload of work and who has time for that.
There is another difference between Visual Studio Code and C/Side that makes it valid for Microsoft in my opinion to keep C/Side alive.
Imagine the scenario a few paragraphs ago. Imagine C/Side with a Table Extension object type and a Page Extension object type. That would make both environments identical rithg?
No… actually it would give C/Side a huge competitive advantage to Visual Studio Code.
Aka Fobs… Tell me how many times you only change two objects in a database that has 8.000 objects or more. Or just one.
How do you ship them? Exactly, you just export the file using C/Side.
If my solution with 2.000 objects were one big extension shipping small changes would become a nightmare. We all have a DTAP system but how often do you make a fix in Test so the tester can continue? How many of you have a Hotfix database? More scary; how many of you just make a change to a report or a page in Production?
For Microsoft to make Business Central in the Cloud succesful they don’t need to do away with C/Side.
The new generation of Cloud developers (if they exist, I only see NAV partners jump on it) never see C/Side.
On the other hand, if Microsoft would move base-NAV to Visual Studio Code we would all take a huge step back.
Navigating in 5.000 or 10.000 file project in Visual Studio Code is a freaking nightmare and compiling and shipping the whole monolith for one report would make customers run away to the competition in a fraction of a second.
So Mark, you say Microsoft has to keep C/Side because of the way NAV is designed, because it is not decoupled. Yes, that is what I am saying.
And this is where it becomes freakingly dangerous what I am about to say.
Let’s be the devils advocate…
If you are forced to refactor or redesign your monolithical applications into decoupled microservices, why would you per-se do it in AL?
That my friends, is where and how we will continue this blog series by talking about things like the API, CDS, PowerApps, Asp.Net Core and Angular.
Yes, I choose to stay with Microsoft, but you are correct if you think you might as well switch to any other framework as long as it is a web-framework. The latter is important if you want to embed with Business Central, the best cloud solution out there today.
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.
Few days/weeks later one of our users comes to our service desk with a posted sales invoice in a currency code we’ve never used before. After some investigation the guy handling the support call figures out that since the upgrade new customers are created wrongly.
Someone at Microsoft (I love saying that) decided it was a great idea to move the Currency Code to another tab or a promoted field, I can’t remember what it was.
The person who creates new customers could not find the field and just thought not to care anymore. However it turns out that in the old version she would always change the currency to euro. When “we” were implemented 12 years ago my predecessor decided to create customer templates with currency codes and they were wrong. Nobody ever reported it. Changing to Euro was just part of the procedure.
Business Central is a monolithic application and therefore hard to upgrade. It has more than 5.000 C# files that are created from C/Side or AL Extensions. The way this all works behind the scenes is pure genius.
Ok, if you are not familiar with these terms you should read at least this article and probably a few more. It’s by Martin Fowler so you cannot go wrong.
The idea behind Microservices is that you break up your architecture into individual components that communicate using API’s. There you go in a nutshell.
Even though Business Central has a brilliant API it is not used by Microsoft itself. When a Production Order needs to post something to the General Ledger it does not use the API but everything internally is written tightly connected.
It makes a lot of sense if you consider that Business Central is based on Navision which was designed 30 years ago.
One of the fundamental design principles of Business Central is transaction integrity. As a developer you should not be able to break that. Well, not unless you put COMMIT everywhere in your event subscribers.
On top of that Business Central has transaction isolation to prevent users to post to the General Ledger at the same time.
All of this is fine until you want to grow with the application and this is where Microservices get interesting.
With microservices you can create several applications that all work together. These applications can be existing software that you buy or subscribe to.
At the company I work for we decided to stop trying to put everything in NAV several years ago. Back then I was against that decision but now I am a big fan.
Because different departments use different software they can all individually upgrade, have small changes done (Extensions in Business Central are brilliant for that) as long as they respect the API.
Most of the API’s I work with respect versioning. If a new version of the software is released the old API works for quite a while until you get notified that it will be depreciated. Giving you time to upgrade.
If you’ve used NAV as a development platform you’ve probably created your own monolithic application and you should reconsider that architecture.
I would encourage every partner if possible to investigate if it is possible to use the API and seperate your IP from Business Central.
In the next set of blog posts I am going to explain how to connect the bits together. Personally I’ve decided to replace NAV with other Microsoft Tech. We’ve chosen Asp.Net Core II with Angular giving us a C# server and a TypeScript front end. So far it is an interesting journey and I’ve created a strategy that will allow us to move bit by bit.
Since I am not yet sure what will happen with CDS/CDM we’ve decided not to choose a database yet. Uncle Bob has learned us never to start with choosing a database. Always make sure you can switch databases.
Don’t miss interpret me. We are NOT moving away from NAV or Business Central. In fact, part of the bigger strategy is to move to the Microsoft hosted option so we can benefit from continuous upgrades and interesting apps from AppSource, CDS, CRM etc.
I just want to move away from Monolithic design into Microservices and Business Central is my financial Microservice of choice every day of the week.
Opinion, by Mark Brummel
When Microsoft closes a door, they open a window. Sure I miss working with the classic client where I could make forms look however the customer wanted them to look. All the colors available withing the RGB pallette, a simple report designer and the database is one file.
If NAV, pardon me, Business Central, was still “that” we would have been out of business for sure even though someone told me 75% of NAV installs are still classic.
We live in a connected world with Web Services, Machine Learning & Serverless Computing. Windows is no longer the dominating operating system.
So Business Central is running cross platform and is a cloud first citizen. Microsoft invested millions of dollars/euro’s to make that happen.
Back to the title of the blog. Project Green… again.
Two weeks ago I managed to get the whole Great Plains community against me. Boy I can tell you these people are well organized. So in this blog I am not going to talk again about Great Plains and where they are in this stage.
Let’s talk about CRM and AX, oh, and Common Data Services.
Last year Michael Nielsen challenged me to co-present at NAVTechDays about PowerApps and Common Data Services. For me that was an eye opener. We agreed I would do PowerApps and he would do CDS.
A good thing from presenting something you know *** about is that unless you want to look like a fool you better learn it. Did not help me though, I stil looked like a fool.
I ended up connecting Navision 1.1 to PowerApps and Michael showed CDS 1.0. I was told, but this can be wrong, that CDS 1.0 was based on AX technology. I think the concept is great but if you watch the video you probably agree that it was not ready for prime time yet.
Word reached me that Microsoft was not happy with CDS 1.0 and was looking for something better. The concept is great.
The CRM people got a shot at it and last week I was reading on LinkedIN that the marriage between xRM and CDS is no longer a secret. Aparently the CRM experts also have different opinions about their new baby.
Yes, XRM Is The New Common Data Service
No, Common Data Service is not the new XRM
I did not have time to read it yet and don’t have an opinion. Last thing I want is the CRM community all over me.
In essence what I know about it, CDS comes together with Common Data Model. You get a pre-defined database with a service that runs transactions. CDS 1.0 did not have the latter. I’ve been told CDS2.0 supports transactions.
On top of CDS and CDM you can use PowerApps as a front end. PowerApps is a cross platform WYSIWYG UI tool.
No, that would be silly, you can read it again. But if you are smart enough you can guess that this is not that much different than the idea of Business Central. You get a pre-defined database, a service and a front end.
Isn’t it a bit silly? Why would Microsoft do the same thing twice? Well, you have to wait a minute, because we have not talked about AX just yet. Or Dynamics 365 for Finance and Operations.
D365FO is also a pre-defined database with a service and a front end. But than in the size of an elephant. Just like Business Central it uses extensions to be customized.
How would I know. It just sounds a bit silly that Microsoft spends millions of dollars maintaining similar platforms. I am not in the Microsoft Board but you can guess consolidation will continue right?
Sidenote to my Great Plains readers. You are still there, no worries. You are just not part of the consolidation. I am a bit jealous.
For now I guess everyone will just keep on rowing in the boat they know. If you are a NAV developer it is quite easy to learn how to make extensions and if you are a CRM developer you can now do CDS and CDM. It’s just ever more confusing for those poor recruiteters who can send their emails to even more candidates hoping they hit something.
It took “us” 15 years to get here. The first decade or so was spent making mistakes and trying stuff that technology wasn’t ready for yet. The last few years things are getting more serious.
The Business Central team has to integrate with CDS and CDM. That is not a question, but an order. If you run BC, you will be able to access your data through the CDS API.
This means you can probably customize NAV, shoot, Business Central, also via more ways. You can build PowerApps.
You can probably also migrate back and forth from BC to FO or the other way around as they are both connected to CDM. If more stuff is connected to CDM your life will be easier.
CDM is probably something you will want to keep an eye on if you make a living doing EDI.
If you build IP for Business Central it can only be used by BC users, not by AX users. If you build for FO it’s the same story.
But, if you build IP on top of CDM everyone can use your solution. Even a NetSuite customer because no-doubt someone will create a CDM connector to NetSuite.
Think about this for a moment… and then decide what your monday is going to look like. What are you going to learn tomorrow?
At this time not much information other than the links I’ve shared is available. Please share linked in the comments.
To be continued…
Sometimes you need an external signal to rethink your strategy. This morning I read this tweet on my timeline.
@markbrummel Thx for sharing your thoughts around business central. In your opinion… if your are looking at competing products. What might be a better option than D365BC? Say 50 concurrent users, multi currency, cloud only, easy to extend… sapB1?netsuite? Acumatica? D365FO? — Kim Kopowski (@KimKopowski) April 2, 2018
@markbrummel Thx for sharing your thoughts around business central. In your opinion… if your are looking at competing products. What might be a better option than D365BC? Say 50 concurrent users, multi currency, cloud only, easy to extend… sapB1?netsuite? Acumatica? D365FO?
— Kim Kopowski (@KimKopowski) April 2, 2018
Funny to me because I don’t see NAV or Business Central as an ERP first, I see it as a Development Platform first with some ERP for free. One that I know inside out better than almost anyone else.
How do you see it? Should we expect Microsoft to take a new approach with ERP first and Development Platform second? For years, or maybe even a decade, everything around NAV was about technology and developers.
With the API present and other development platforms superior it would not surprise me that Microsoft changes this strategy.
Should this old dog learn new tricks? What is the learning curve? Which other platforms? Share your opinion please!
Don’t forget to register for today’s webinar and let’s see if we can find out what happens to C/Side and Object Files. To Fob or not to Fob, that’s the question.