Let’s recap on the blog posts from the last three days.
Visual Studio Code is an awesome editor but due to the nature/legacy of Business Central and many ISV solutions it can be less productive when moving large monolitical solutions one-to-one.
Solution is to break them up into smaller extensions with dependencies.
When taken out of the context of C/Side the old object ID’s are not so powerful as they once were. Adding the hybrid capabilities with C/Side and the nature of extensions to be decoupled it backfires quickly and silently.
Solution is to add a Namespace to each extension to make the ID unique. The ID itself can stay or be moved to auto-numbering in the back-end.
Compared to other programming languages AL can be less intuitive to get started with and it behaves unexpectedly for modern developers. It requires a lot of effort for the Business Central team to maintain a language dedicated for only one application.
Solution is to move AL to TypeScript to reduce the learning curve for new developers and add modern programming capabilities.
Taken as constructive feedback I hope it is worth something. If not it can serve as food to digest and explanation for those new to our community for legacy bits and pieces.
Now what do we do…
One of the questions I got on my blog was how to take this product that was shipped by Microsoft and make the best of it.
Let’s try to point out the points that make Business Central stand out from other frameworks. It has a number of nice built-in features that not a lot of other frameworks have.
Not something on the top of everyone’s list, but most business applications require some form of reporting or printing of documents. Think of shipping documents, labels, invoices or customs paperwork.
For most modern solutions printing to PDF is enough but sometimes printing to a real printer can be a requirement.
Business Central has that built-in without requiring a plugin.
In frameworks like Angular there is no built-in security. You need to build it yourself and with modern requirements such as GDPR this is something you want to make sure this is done in a solid way.
Business Central requires very detailed security, maybe a little too detailed if you are unfamiliar with the datamodel.
Everything is connected these days and a simple file-via-ftp is no longer considered high-tech, let alone safe. (Remember GDPR?). Web Services allow a safe and real-time way of transferring data. Business Central supports sending and consuming SOAP, REST and OData(4) and is shipped with a very solidly designed out-of-the box API.
Office 365 Integration
Within our community we take Azure Active Directory (AAD) and Open Authentication (OAuth) for granted but everyone who has ever try to build in these into their own platform understands that it’s not an easy task.
Because the Web Framework parts of Business Central are perfectly aligned with the technology used by the Office team the integration between the two is a seamless as possible. No other framework can match the level of integration.
Last but not least. Business Central is one of the few frameworks that guarantees transaction integrity across extensions.
I was very unsure to mention this as a plus because it can also create huge problems since Business Central is built on SQL Azure and the main posting routines run on transaction isolation.
If you call a Web Service in your extension during a transaction there is a fair chance other people cannot use similar transactions in the same company.
To my experience, solutions that are architected in a more modern fashion tend not to need long running database transactions but I want to avoid another debate here.
Hybrid is the future
As mentioned earlier, I don’t believe in 1-on-1 porting of traditional business solutions designed for C/Side to be moved to a monolith extension.
The legacy solution should be re-evaluated and reflected to modern requirements.
In one of the next posts I will dive deeper into the possibilities given by the use of the API in combination with embedding parts of Business Central in your Web Application or the other way around.
I think we should start with explaining the design difference between using an API and using Extensions.
This will not be posted this week since I have my wedding anniversary to prepare for. So prepare for a quiet time ahead from my end. At least on my blog, not if you are my neighbor.