How To, Part I | Breaking a Monolyth

I often wonder how I find myself in situations like this. On my day off I find myself behind my desk doing something which is not my responsibility, nor am I getting paid to do it.

If you say A, you also have to be willing to say B and C. This is what my parents told me when I was young so when I promissed Bugsy and Jesper to look into making the Business Central Base Application smaller I decided I may as well make it into a decent project.

The Project

The current status of the project is that we are moving four application area’s away from BaseApp into it’s own separated module. The area’s are Fixed Assets, Cost Accounting, Service Management and Jobs.

As a fifth application area we are looking at making Item Tracking better to extend.

Fortunately I am not doing all the work myself. I am only doing Fixed Assets which I will blog about. Others are doing the rest and the team currently counts over 10 heads. I’m trying to do a poor-mans project management with GitHub, Teams and email.

Now please note that all of this may very well be a dead end road. We are presenting the first results to Microsoft on January 9th and then we’ll have a first evaluation.

Business Case & Limitations

In order to move on, we need to have a valid business case that proves that this is adding value to the product.

Personally I see three important reasons for doing this.

  1. If the BaseApp becomes smaller it will be easier to understand for newbies that don’t have two decades of Navision experience. It will also increase the speed of the pre-compiler and C# conversion process.
  2. Partners can replace the modules we extract with their own. This means that a module like Service Management does not have to be extendible by itsself.
  3. Extracting these modules will require new event publishers and the introduction of enum’s in the BaseApp. Partners can use these to connect their extensions. By extracting these modules we’re exactly pinpointing the area’s we all need

Please note that we are ONLY moving stuff around, we are not doing ANY schema changes or rewriting of AL code. The impact of this project should be as minimal as possible to the existing partners. All they should do is change their depencencies and rewire some event subscribers.

Step 1 – Move and See what breaks

This step is something I’ve done myself first for Service Management and then for Fixed Assets and it’s a realatively simple step.

We move all objects to a new extension that fit 100% in this module. I did this mostly based on experience and with help of the compiler. I have two instances of Visual Studio Code open and use cut and paste from within VSCode.

Note that the size of BaseApp makes this a very tough task for your machine. Turn down all code analyzers and even make sure you don’t have any open browser pages. I’ve noticed that having google chrome open uses some CPU you need for VSCode during this project.

Step 2 – Make the BaseApp compile

The new module, in my case Fixed Assets, will take a dependency on BaseApp. In order for this to work, I need a BaseApp that builds into an .App file without the files I just moved.

Since we are still in proof of concept phase I want this to happen asap.

To make this happen I used the compiler errors. In my case there were little over 1000 errors after moving the FA objects to their own extension.

Every object I “fix” needs to be more fixed later. Some fixes will become event publishers and subscribers and other fixes will be table extensions and page extensions.

Since I don’t want to loose time doing that not knowing if this will work I’m using Todo Tree. This is a very popular extension on the marketplace.

At the moment of writing this blog I have 73 errors to fix before I can start with step 3, which will be my next blog.

Comment List