- Get started with Dynamics 365
Stay on top of the latest features and releases
FastTrack your deployment
Speed up your rollout with personalized tools, resources, and best practices
Find the right eLearning courses for your role
Resources for people with disabilities
Learn how Dynamics 365 supports your GDPR compliance journey
- Get started with Dynamics 365
The AL developer environment is evolving with frequent updates. To stay up to date on the latest information and announcements, follow us on the Dynamics NAV Team Blog.
Development in AL
Extensions are a programming model where functionality is defined as an addition to existing objects and defines how they are different or modify the behavior of the solution. This section explains how you can develop extensions using the development environment for Dynamics 365 Business Central.
If you are new to building extensions, we recommend that you read this document to get an understanding of the basics and terms you will encounter while working. Next, follow the Getting Started with AL to set up the tools.
If you are looking for the C/SIDE documentation, visit our Dynamics NAV library.
Understanding objects in the development environment
All functionality in Dynamics 365 Business Central is coded in objects. The extension model is object-based; you create new objects, and extend existing objects depending on what you want your extension to do. Table objects define the table schema that holds data, page objects represent the pages seen in the user interface and codeunits contain code for logical calculations and for the application behavior. These objects are stored as code, known as AL code, and are saved in files with the
.al file extension. The AL Language extension also supports the multi-root functionality which allows you to work with multiple AL folders within one workspace. For more information on how to group a set of disparate project folders into one workspace, see Working with multiple AL project folders within one workspace.
A single .al file may contain multiple objects.
There are two other special objects which are specifically used for building extensions. Table extension objects and page extension objects are used for defining additive or overriding changes to table or page objects. For example, an extension for managing a business that sells organic food may define a table extension object for the Item table that contains two additional fields,
Produced Locally. The
Produced Locally fields are not usually present in the Item table, but through the table extension these data fields will now be available to store data in and to access from code. You can then use the page extension object to display the fields that you added to the table object.
Extension objects can have a name with a maximum length of 30 characters.
You have several options for creating new objects with the AL Language extension for Visual Studio Code. For more information about the objects that you can create for your extension, see AL Development Environment.
Developing extensions in Visual Studio Code
Using the AL Language extension for Visual Studio Code, you will get the benefits of a modern development environment along with seamless publishing and execution integration with your Dynamics 365 Business Central tenant. For more information on getting up and running, see Getting Started with AL.
Visual Studio Code and the AL Language extension lets you do the following tasks:
- Create new files for your solution
- Get assistance with creating the appropriate configuration and setting files
- Use code snippets that provide templates for coding application objects
- Get compiler validation while coding
- Press F5 to publish your changes and see your code running
For more information, see Visual Studio Code Docs.
If you have previous experience working with the C/SIDE development environment and need an overview of some of the changes between the two development environments, see Differences in the Development Environments.
The Designer works in the client itself allowing design of pages using a drag-and-drop interface. The Designer allows building extensions in the client itself by rearranging fields, adding fields, and previewing the page design. For more information, see Using Designer.
Compiling and deploying
Extensions are compiled as .app package files. The .app package file can be deployed to the Dynamics 365 Business Central server. An .app package contains the various artifacts that deliver the new functionality to the Dynamics 365 Business Central deployment as well as a manifest that specifies the name, publisher, version, and other attributes of the extension. For information about the manifest, see JSON Files.
Submitting your app
When all development and testing is done, you can submit your extension package to AppSource. Before you submit the extension package, we encourage you to read the checklist to help facilitating the validation. For more information, see Checklist for Submitting Your App.
Dynamics 365 Spring 2018 release – main changes
For the Dynamics 365 Spring 2018 release, Microsoft promises major improvements in three areas:
1 – Adjusting the Dynamics 365 applications so that they will work together better across all business processes. Rather than a combination of separate applications, Dynamics 365 will become a unified group of solutions which can support all business activities.
2 – Improving Dynamics 365 integrations with other Microsoft products.
3 – Bringing new platform capabilities: the Business Application Platform will make it easier to create and customise new applications using Dynamics 365, Office 365, PowerApps, Microsoft Flow and Power BI.
The Dynamics 365 Spring 2018 release will affect most areas of Dynamics 365. Amongst the wealth of modifications which are about to be made, a few particularly exciting ones deserve to be listed here:
- GDPR: the Dynamics 365 Spring release includes changes designed to ensure the compliance of Dynamics 365 with the requirements of GDPR. We will soon publish a different blog article about GDPR and its impact on Microsoft Dynamics.
- General availability of Dynamics 365 for Marketing: a new application focused on building relationships with prospects more effectively and to provide more automation for marketing processes.
- Dynamics 365 for Sales: a new version of the Dynamics Sales application takes Sales Force Automation a step further.
- Artificial intelligence: new artificial intelligence capabilities have been included to this new Dynamics 365 release.
- New Power BI apps will be available for preview: Power BI for Sales Insights and Power BI for Service Insights.
- The Common Data Service for Apps will be updated – see the announcement for the PowerApps Spring Update.
- The Common Data Service for Analytics will be added to Power BI.
Online readiness resources
For a summary of the spirit of the new release, read the Dynamics 365 Spring 2018 release notes announcement on the Microsoft blog.
If you’d like a deeper (and more practical) dive into the functionalities of this Spring release, read Accelerating digital transformation with the spring 2018 release for Dynamics 365 and Business Application Platform by Microsoft Corporate Vice President James Philips.
The Microsoft Dynamics 365 Roadmap page is also a great place to go for details about each of the new Dynamics 365 capabilities.
Events not to miss
This new release is a focal point of the Microsoft Business Forward event in Amsterdam. We highly recommend keeping an eye on the Microsoft Business Forward page for links to blog articles, videos, webinars and resources related to the Dynamics 365 Spring update.
Webcast: Microsoft is holding a Business Applications virtual spring launch event on March 28th( 8:00 am PST 11:00am EST). Register now if you don’t want to miss it!
Lately, a number of ISVs have asked me this question:
If you where me, what would you do?
To give the question a little context, we are talking about Solutions, Customizations, Extensions, Modifications or whatever name you use. We are talking On-prem, Hosted, Managed Service, Dynamics 365 for financials.
What is the magic bullet? What should the ISV do in order to make sure that you are ready for the future, without wasting a lot of time.
The answer can really be given from a technical or from a business model perspective, but since I am a Technical Evangelist (and not a Business Model Evangelist:-)), I have decided to see things from the technical side. I claim, that even if you would see this from the business model side, you will reach the same conclusions.
This post is my response to these ISVs.
Let me first start by defining a number of different “states” an ISV solution can be in. This list is not be complete, people can be in between or have more than one solution, but work with me on this, don’t get caught up on the details:
- Solutions are customer specific, every customer is running on their own version of the app on their own server (on-prem or hosted) and the customer pays to get upgraded to new versions of NAV. Best practices are followed as to tagging code customizations and a merge tool is used to merge the latest update from Microsoft with the customer solution when the customer decides to do so.
- Like 1 – except the solution is a standard solution following the guidelines of the Road to Repeatability program. Customers still decide when to upgrade to a new version, but when they do, they get the latest version, which is the same for all.
- Like 2 – except that the solution is running in a multi-tenant environment and all customers are in fact running on the same versions of the app. When upgrading, a new multi-tenant environment is spun up and customers are moved over.
- Like 2 or 3 – except that the solution is using event based architecture, using events to modify base behavior where possible and if no events are available, a new event is introduced in the base app as the only code modification to merge. A merge tool or the merge Cmdlets are used to automagically merge updates from Microsoft with the solution.
- Like 4 – except that the solution is actually packaged as an extension, meaning that all customers will be using the same base app and the individual tenants can install the extension if they like. Upgrade is done by rolling the extension off and on again, restoring the data where needed.
- Like 5 – except that the extension is Saasified and uploaded to AppSource and Cutomers using Dynamics 365 for Financials (always multi-tenant) can install the extension, try it out for free and the app can request a registration and/or payment to use full functionality. Upgrades are handled automagically every month.
These six models really showcase the transformation solutions in NAV has taken – just over the last approx. 5 years and no wonder that it can be hard to follow along – and now Microsoft is talking about Extensions v2 and Visual Studio Code????
You can probably easily identify where you are on the stairway – and maybe you even have a clear plan on where to do?
For every step you take up the stairway, you will meet challenges. Some are easy to overcome, some harder. Some challenges might even be to the point, where you decide not to take that step, but please be aware, that you normally cannot skip any steps on a stairway. You need somehow to get over it or be stuck below that step.
Here are a few of the challenges you will meet on your way:
step 3 – multi-tenancy means people cannot write to the app database, some scenarios are harder.
step 5 – real extensions means that you will have to live with the events that are exposed by the base app, you cannot modify and add new events.
step 6 – no server side DLLs, no file access, only limited .net interop, no Windows Client.
and when we talk about extensions v2 and Visual Studio Code, there will be more challenges, which Microsoft will try to provide good workarounds for (either by extending the language or making built in support for stuff like Azure Functions and Web APIs)
Note, that it is important for Microsoft to hear about the challenges from Partners. Microsoft cannot foresee every single obstacle every partner will ever run into, so feedback is important, whether it is missing events, missing functionality or other things that prevents partners from taking the next step up the stairways.
So, what would I do?
I assume that you want to move up the stairway – all the way to the top of the stairway to heaven… (sweet music:-))
I assume that you eventually want to be standing on the top with an app in AppSource but what should you do to get there? Should you wait until Dynamics 365 for Financials is in your country? and what if that date isn’t even planned yet?
If my solution was on step 1-3 on the stairway – I would refactor it in order to get to step 4 – Event Based Architecture.
Getting to step 4 will put you in a better place and doesn’t really add any challenges that cannot easily be overcome. It is just a good way of writing your code, which makes updates and merges easier and will enable you to identify missing events and know more about what it takes to move to an extension. This work can be done in NAV 2017 using the Classic Development environment.
Once at step 4 or above you can decide to continue up the stairway using Extensions v1 and the classic development environment or you can switch to Extensions v2 and use Visual Studio Code – and this is really determined by timing.
How does your code look at step 4
When refactoring your code for step 4 you should think about the next steps, but you shouldn’t limit yourself due to challenges you see today.
- Use events to intercept base app functionality and add your own behavior.
- Introduce new events in the base app if you cannot find events that meets your needs – this will be a code modification causing a delta and a challenge when moving to the next step. Postpone the resolution of that challenge until you take the next step, but check NAV Tenerife to see whether that event is coming – else notify Microsoft about the missing event.
- If you have code which you know will cause challenges at higher steps (could be Web Services communication, calling a DLL or other things), then encapsulate this in functions and use these functions throughout. Postpone the resolution to that challenges until you take the next step, but check NAV Tenerife to see if and how this challenge can be solved.
- Do not limit yourself to whats possible in Extensions v1 or in Extensions v2 today. If you meet a challenge, encapsulate the challenge, document, check NAV Tenerife, tell Microsoft and then postpone.
- Saasify your solution, use assisted setup, wizards, notifications and other tools to make sure, that your app is easy to use and doesn’t require a lot of training hours for users to understand.
- Make good use of design patterns in your implementation.
You can (and should) really perform a lot of the refactoring of your solution at step 4, when refactoring for the event based architecture. At this step, you can still ship, test and develop your software. You are in a safe haven.
Extensions v1 vs Extensions v2?
I hope that it is clear by now, that step 4, the event based architecture is the place to get to and that this has absolutely nothing to do with Extensions v1 or Extensions v2. It also has nothing to do with whether or not Dynamics 365 is available in your country – it is just a good step to be on and take a rest. Furthermore… it is a necessary step.
The two options you have now is Extensions v1 or Extensions v2. Extensions v1 is out there in NAV 2017 and apps on AppSource today is based on Extensions v1. Extensions v2 is in preview and you probably won’t be able to publish apps on AppSource before summer of 2017 using Extensions v2. Extensions v1 is likely to be deprecated in AppSource some time during 2017.
New events are available in CTP drops of NAV Tenerife – both for Extensions v1 and Extensions v2.
Extensions v1 and Extensions v2 will be supported in NAV Tenerife (on-prem). Extensions v1 will likely be deprecated in a future NAV release.
Whether Classic NAV Development will be deprecated at some point in time in the future – I have no idea and that is totally unrelated to this blog post.
Extensions v1 has limitations on where you can add code and it is cumbersome to work with. Extensions v2 is still in preview and doesn’t have full functionality yet.
With this info, it isn’t really a question about one or the other. It is more a question on when do you move to Extensions v2? and whether you are going to use Extensions v1?
Should you use Extensions v1 (C/SIDE)?
Maybe you are already on step 5 with extensions v1 or maybe you have an app in AppSource and you are at step 6, then you of course would use extensions v1 until you select to move to extensions v2.
If not, then IMO, you should have a business reason for taking step 5 with extensions v1. That reason could be that you need to ship something to AppSource tomorrow – then your only option really is Extensions v1.
When should you move to Extensions v2 (Visual Studio Code and In-Client Designer)?
If you haven’t already done so, you should spend some time on the NAV Developer Preview.
You should familiarize yourself with the new development environment, read the blog posts on the NAV Team Blog, follow the questions and issues on GitHub, Investigate the samples on GitHub and the earlier you get started, the better your chances of influence the shape of Extensions v2.
The conversion tool is likely to be shipped in the April update of the NAV Developer Preview and should be able to help you convert from Step 4, 5 or 6 to the same step using the new Development environment – allowing you to take the final steps in Extensions v2.
The conversion tool is not going to take you all the way, you will probably have to do some manual work too. You might also find that it would be best to refactor a few things in C/SIDE before the conversion to make the conversion run more smooth. Do that, run some test conversions and move over to Extensions v2 and Visual Studio Code once you have a business reason for making the move.
If you want to move your solution forward and up the stairway, you need to consider a few things.
If you are not there yet, you need to refactor your code to step 4 – Event Based Architecture.
While at step 4, make sure that you have everything in place for the next steps before going there.
- Identify challenges and engage with app solution providers or Microsoft to solve these.
- Easy to use user interface (how do users get a WOW experience in just 5 minutes of using your app)
- Test automation (when upgrades and release are automatic, you need to have high code quality)
- Sustainable Dev Structure (agile development, source code management, release management etc.)
- Good alignment between Marketing and Engineering
When you have all these things in place the next steps up the stairway are easy to see and easier to overcome.
I hope this is helpful
The last year has been quite a journey for people using Docker images for Microsoft Dynamics NAV or Dynamics 365 Business Central. Images have been available in various places and private registries, navdocker, developer preview, navinsider, microsoft/dynamics-nav are just some of the terms you have run into.
This blog post should demystify and explain clearly which Docker Image is the right for you in a given situation – and where to get it.
Developing for Microsoft Dynamics NAV
If you are developing for Microsoft Dynamics NAV, you will find Docker images on the public Docker Hub under microsoft/dynamics-nav.
In the public Docker hub, you will find all cumulative updates to NAV 2016, 2017 and 2018 in all country versions and you can use the images simply by specifying the right tag. The tagging strategy used in microsoft/dynamics-nav is:
- version is 2016, 2017 or 2018 (default is 2018)
- cu is rtm, cu1, cu2, … (default is latest)
- country is w1, dk, de, nl, na, … (default is w1)
Image name examples:
microsoft/dynamics-nav microsoft/dynamics-nav:2018-cu3-de microsoft/dynamics-nav:2017 microsoft/dynamics-nav:2016-dk
You will also be able to run earlier versions of Microsoft Dynamics NAV using the generic image as explained here.
Developing for Dynamics 365 Business Central
If you are developing for the current version of Dynamics 365 Business Central, you will find Docker images on the public Docker Hub under microsoft/bcsandbox.
You will find the current version of Dynamics 365 Business Central using
- build is the build number (default is current version)
- country is w1, dk, us, ca, de, … (default is w1)
Image name examples:
microsoft/bcsandbox microsoft/bcsandbox:us microsoft/bcsandbox:dk microsoft/bcsandbox:12.0.21229.0-us
You should normally never use the image with a specific build number unless instructed to do so. This is primarily used when you spin up Container Sandbox images from within Dynamics 365 Business Central (page search for Sandbox).
Maintaining an app in AppSource for Dynamics 365 Business Central
If you have published an app in AppSource, you should continuously test that the app works with the next version of Dynamics 365 Business Central. You will be able to get insider builds of Business Central from a private registry called bcinsider.azurecr.io and the credentials for this private registry is available through Microsoft Collaborate.
The insider builds are normally updated daily and the Dynamics 365 Business Central servers are updated monthly to this version. When the Dynamics 365 Business Central servers are updated, the image will also be deployed on the public docker hub under microsoft/bcsandbox (see previous section).
The image name follows the same tagging strategy as the public Dynamics 365 Business Central images:
- build is the build number (default is latest version)
- country is w1, dk, us, ca, de, … (default is w1)
Image name examples:
bcinsider.azurecr.io/bcsandbox bcinsider.azurecr.io/bcsandbox:us bcinsider.azurecr.io/bcsandbox:dk bcinsider.azurecr.io/bcsandbox:12.1.21581.0-nl
You should never use the image with a specific build number unless instructed to do so. Setup Continuous Integration and Continuous Deployment by pulling the daily update of the Dynamics 365 Business Central Sandbox Container image.
Developing for a future release of Dynamics 365 Business Central
Much like the strategy for Windows and other Microsoft services, Dynamics 365 Business Central will receive major updates semi-annually. If you are developing an app for AppSource targetting the next major update or if you need cutting edge functionality directly from the lab, you will be able to get insider builds of Business Central from a private registry called bcinsider.azurecr.io and the credentials for this private registry is available through Microsoft Collaborate.
The insider builds are normally updated daily and the Dynamics 365 Business Central servers are updated semi annually to this version. When the Dynamics 365 Business Central servers are updated, the image will also be deployed on the public docker hub under microsoft/bcsandbox and will receive updates monthly (see previous section).
Please be aware that these insider builds might be more unstable than builds from the previous sections. You might see new functionality being developed over multiple days and upgrade procedures between versions might not be working smoothly. Please only use builds from this branch if you have a reason to do so.
The image name follows the same tagging strategy as the public Dynamics 365 Business Central images, but with a different namespace:
- build is the build number (default is latest version)
- country is w1, dk, us, ca, de, … (default is w1)
Image name examples:
bcinsider.azurecr.io/bcsandbox-master bcinsider.azurecr.io/bcsandbox-master:us bcinsider.azurecr.io/bcsandbox-master:dk bcinsider.azurecr.io/bcsandbox-master:12.1.21581.0-nl
You should never use the image with a specific build number unless instructed to do so.
If you encounter issues with Microsoft Dynamics NAV or with the current release of Dynamics 365 Business Central, you must report issues through the Dynamics Support team. You can open Support Request to CSS through PartnerSource portal (https://mbs2.microsoft.com/Support/SupportRequestStep1.aspx) or contact your Service Account Manager (SAM) in the local subsidiary to understand what is included in your contract as of support incident and PAH (Partner Advisory Hours). Your SAM might also direct you step-by-step how to open a support request or how to get credentials if this is the first time you or your company are engaging Support.
If you encounter issues which are specific to the insider builds of Dynamics 365 Business Central, you should report these on Github AL issues.
In the near future, there will be a blog post on the NAV team blog explaining the above in more detail.
If you have issues running the simplest NAV on Docker container (docker run -e accept_eula=Y -m 3G microsoft/dynamics-nav) you should troubleshoot your infrastructure. A lot of frequently encountered issues can be solved be reading this blog post. You can also download a Container Host Debug PowerShell script here: http://aka.ms/debug-containerhost.ps1 to troubleshoot issues with the container host.
If you have issues running NAV on Docker or Business Central Sandbox Containers, which you think might be related to problems in the Container images, please report these on Github nav-docker issues.
If you have issues running NAV on Docker or Business Central Sandbox Containers using navcontainerhelper, which you think might be related to problems in navcontainerhelper, please report these on Github navcontainerhelper issues.
If you have issues running NAV on Docker or Business Central Sandbox Containers in Azure VMs using the ARM templaes (http://aka.ms/getnav, http://aka.ms/bcsandbox, etc.), which you think might be related to problems in the ARM templates, please report these on Github nav-arm-templates issues
The Txt2Al conversion tool allows you to take existing Dynamics NAV objects that have been exported in .txt format and convert them into the new .al format. The .al format is used when developing extensions for Dynamics 365 Business Central and Dynamics NAV. Converting the objects consists of following two steps:
- Exporting the objects from C/SIDE in a cleaned format.
- Converting the objects to the new syntax.
NAV GDPR Tools In Action (@NAV 2018 CU4)
I have published several posts on the GDPR, we are currently implementing it from several customers, many people still ask me for information on the subject. I have already talked about what to do for the old versions of NAV (which are no longer under maintenance)
But yesterday … the CU4 of NAV 2018 was released (and the other CUs for NAV 2015. 2016, 2017) which includes the TOOLS useful for GDPR. The technical\application modifications have been introduced since CU3, from the CU4 onwards all the necessary tools will be inserted.
PS: Soon my article relational to the GDPR Topic will be published on NAVUG Magazine (article prepared before the CU4 of NAV 2018, therefore generic)
In this post (as promised yesterday in the post on the publication of the CU4 of NAV 2018) i will explain what has been done in CU 4 and how the GDPR tools work.
NAV 2018 CU4 GDPR Tools
If you set this profile you can access to “Data Privacy” menu
PROFILE -> Administration & Security
DATA CLASSIFICATIONS -> Data Classification Worksheet
From this it is possible to classify sensitive data (as described in the GDPR Whitepaper issued by Microsoft), field by field for standard and other custom tables.
It is also possible to set the sensitivity of the data in a massive way, Microsoft has set a standard (base) classification that must be verified and validated.
Set Data Privacy on Customer Table
SETUP DATA CLASSIFICATION (WIZARD)
It is possible to export and import from Excel, importing from Excel is useful if you have made a map of the data required for processing (sensible and personal date types).
WIZARD IN ACTION!
Choose the right option!
SAVE TO EXCEL
DATA PRIVACY UTILITY
With this button you can execute two functions:
Export data of the subject
Creation of a configuration package (yes, Microsoft has decided to use the old package introduced in NAV 2013 to export import data and manage the cancellation of data…)
Creation of a configuration Package for “Employee” table
SENSIBLE DATA DECTIONFILTEREXPORT
Now you can export sensitive data detected in the system using this Wizard, you can filter what you need.
TYPE OF DATA
- Company Confidential
FILTER ON DATA SENSIVITY: “ONLY SENSITIVE DATA” in this case
You can extract data in Preview Mode before exporting it, you can check it before exporting it to Excel
EXPORTING TO EXCEL FUNCTION
After exporting to Excel the system logs what has been done (AUDIT & LOGGING FEATURE)
CREATION OF NEW CONFIGURATION PACKAGE
it is possible to create a new configuration package from this wizard
..THIS IS A PACKAGE WITH SENSITIVE DATE
Should I encrypt it? NO, it’s not clear, it’s already in binary code.
DATA PRIVACY ACTIVITY LOG
Each activity is tracked and written in the log (as required by the GDPR)
CHANGE LOG ENTRY
You can activate use the old Change Log Entry to track changes to the data (function existing from the first versions of NAV). Take a look at my old post if you do not use it.
My Post about “Track activities Change” in NAV https://robertostefanettinavblog.com/2015/06/09/nav-2015-tracking-sessions-users-activity-change-log/
Designing with customer regular license.
I was thinking about difficulties to teach NAV design to final customers without full developing license. Most of customer licenses only can develop code in reports and XML ports. They can´t put code into Codeunits, table and pages.
So essentially teaching final customers is create new tables, fields, pages and mainly report builder design. It´s easier to teach customer with full dev license, closer to your daily work and you are not fighting all the sessions with license limits and the absolute not funny fact: you can´t develop business logic.
The test with Visual Studio Code.
We configure in Nav 2018 local machine service with the specifications:
– No dev full license.
– Codeunit Objects purchased from 50000 to 50099.
A very common scenario in NAV customer final license.
So, the first test is develop an extension and deploy it pressing F5. The result is:
It failed because an object was out of 50000..50099 range (50150). If I change the number of the extension into available number range, the extension is successfully created.
I also notice, anyway with or without right range, the package can be created.
Conclusion: Customers can develop extensions with their own license, also Codeunits. The only requirement is assign numbers in their purchased range objects (even for tableextensions and pageextensions).
Able doesn´t mean easy. Opinion.
We can expect a crowd of final customers developing Coduenits by themselves……….or may be not.
We can see some difficulties for become this real: C/SIDE was simple and direct, more accessible to people without a strong programming knowledge. VIsual Studio Code is less democratic on that point. It free, but requires programming background.
Also we are all the time in an On-premise scenario and On-premise will not be future mainly scenario.
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.
Mark, wait a minute… Mololithic? Microservice? What the f…?
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.
It’s the API stupid
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.
New Design Paradigm
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 chosenCore 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.
I LOVE Business Central
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.