How To, Part I | Breaking a Monolyth

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.

4 thoughts on “How To, Part I | Breaking a Monolyth

  1. davmac1

    Commissions is much smaller, but should be a separate app as well so it can be replaced easily.
    Look forward to hearing more about this project.
    Didn’t Bill Gates originally think that we needed a standard G/L that many other apps could use?


  2. Hans H. Fiddelke

    How do you solve the issue that there are extensions that are overlapping, like extended text management. that allows to handle texts per document type (in separate tables) or commissions which which may be used from service and sales.
    Does this mean, that we need additional or different apps for every of the separate (base) app module- combination?
    Where does this end, if you split up base app into multiple apps?


    1. Mark Brummel Post author

      Hans, instead of complaining about problems, can you please make a suggestion of how you would solve this? You are a smart man and very experienced so offcourse you are right. But being right doesn’t solve the problem.


      1. Hans H. Fiddelke

        The only solution i currently know is not to break up BassApp. But that means slow develpoment.
        My solution would be a solution you would/can not accept: Use C/AL. There you don’t have the problem with with the large base-app in most cases.
        And a real usefull solution requires also C/AL: Conditional Compile. If whole source is uploaded into the tennant, and compiler is also integrated, you are able to compile an object after a module is installed. Then you are able to use a compiler directive like “#IFEXIST(OBJECT::”WhatEver”)…#END” and a property at variables or functions “IgnoreIfNotExist”=True.
        But conditonal compile also requires also a large amount of tests, because you have to test also every combination of installed apps.
        BTW: The problem why breaking up the base app is not a good idea, is the same why breaking up large ISV- solutions is not a good idea. They have to many dependenies through the modules.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.