The FOB is planning its retirement

In software we’ve invented all kinds of terminology to make it sound as if removing a feature is great. Terms like sunsetting and retirement give you a great feeling. Who does not love to see the sun go down with a beer and a loved one.

In reality it means that software that once was is no longer and we’ve had plenty of that in our beloved Navision product, now referred to as Business Central.

FOB is an abbreviation of Financials Object, just like FLF is short for Financials License File.

We use FOB files to move objects from one database to another using C/Side.

In the future of Business Central there is no room for C/Side. Microsoft is currently working very hard to make the Visual Studio Code experience and the ALC.Exe compiler mature enough to replace C/Side. On top of that C/Side also manages the system tables and a lot more that “something else” has to take over.

But this post is not about C/Side. C/Side will be there in October when NAV 2019 is released just like the Windows Client and the Fob option. But that does not mean it is smart to continue using them.

NAV Architecture, Design & Code

Loyal readers of my blog will not be surprised to read that I am not a fan of how NAV is architected, designed and coded.

I’m not talking about the base design principles and patterns. They are fine and should be used, but also by Microsoft.

NAV is one monolithical application where the functional modules cannot be recognised in the code structure.

This is not a problem in C/Side because here we can easily filter on object names and object numbers and most of us somehow leverage the Version List to filter on objects that have been modified for a project or customer.

Making a Fob

When we make a Fob we apply a filter in C/Side and export the files. This export does not necessarily need to contain all changes. We can cherry pick.

I did this for one of my customers this week. We are hybrid in NAV2018 and have close to 2.000 new objects added to NAV. We wanted some of the modifications in DEV to ship to PROD, but not all of them.

This is easy these days by just marking the objects, exporting them, putting them into the Acceptance system, do one final test and go live.

What if we don’t have Fobs no more…

Let’s say that I move all of this customers modifications to an extension. I actually tried this a few times.

When NAV 2018 was just released I ran the ExportToNewSyntax and the Txt2Al and quickly gave up. I had hundreds, if not thousands of compile errors which were caused by many things starting with bugs in the export, the converter and then the fact that NAV 2018 does not support DotNET which crashes a big percentage of our code.

I did the same thing a few weeks ago and to my surprise I was down to 414 errors. Many things had been fixed and DotNET variables no longer error out although they don’t work yet.

When NAV 2019 ships in October these 414 errors are probably down to a number that is overseeable and fixable. DotNET will work and I can migrate everything to an extension.

Why is this a bad idea?

If I migrate all my changes to one super extension my life will become impossible. It will be very hard to work with Visual Studio Code because finding objects is hard. The compiler will be very slow because it has to evaluate 2.000 objects with each keystroke.

Working on the same database with more than one developer will be hard, even if we use Git and GitLens. Sure, Git will merge but it will make mistakes and I will loose time.

Moving parts of my changes which are finished and testing while leaving out ongoing mods will be extremely hard.

The Solution

I need to break down my solution into smaller projects with dependencies. If I break down my 2000 objects into groups that belong together and compile together I can ship different versions when they are tested. I can write automated tests for these components and have different developers working on different parts of the application without them running into Git Merge issues.

I can have junior developers working on simple extensions and have senior developers work on the core objects that are difficult to maintain.

How To Get There?

I don’t know. Because DotNET is not supported yet I’ve not yet had a chance to move stuff around easily.

In theory it should be as easy as moving .al files around into different projects and have the compiler test if everything still works.

You’ll probably run into the situation where you have to move code from OnValidate triggers to events because they belong in different components.

Dude, is this still simplicity?

Right. This is exactly why I am debating this for my customer. For the last 20 years or so we’ve been using NAV as a development environment. The solution has very little dependency on NAV.

With Extensions and Visual Studio Code Microsoft is moving into a more Object Oriented approach with dependencies and a high level of abstraction.

For this reason I am comparing NAV to .Net Core. This allows us to use the full C# stack, Entity Framework and any HTML front end framework like Angular, React or whatever the framework of the day will be in five years.

Extensions as Micro Services

Whatever I can do today as an Extension I do as an Extension. We have 8 extensions already and none of them have more than 20 objects.

With a little help from the ForNAV Object Explorer it is very easy to manage. Every extension gets 10 numbers assigned from our license. When we need more than 10 numbers the extension get’s too complex and has to be broken up into more components.

How Many Extensions?

We will probably end up with about 30 extensions, maybe less if we move some of our components to .Net Core.

In .Net Core we are going to take the same approach. Small projects on a shared core. We have four projects as we speak that have organically grown over time. This summer the plan is to synchronize them and generate a NUGET package that will allow communication with the Business Central API.

Who knows, this NUGET package might be available for you as well.

 

 

10 thoughts on “The FOB is planning its retirement

  1. Erik P. Ernst (@EPErnst)

    Hi Mark,
    I know working with a too large project in VSCode is not practical. But going down to a max of 10 object numbers (so about 50-60 objects max), is that taking the micro service thought a bit too far? And how about extension inter dependencies? With you behind the wheel, then I’m sure this project was already developed with clean code and modularity in mind. Personally then I’m afraid that many projects continue as always, and when “suddenly” C/Side is no longer supported, creates one big extension, which will haunt them for years to come. Giving extensions a bad rep.

    Liked by 1 person

    Reply
    1. Mark Brummel Post author

      Which is why I blog this.

      You know I offer (free) consulting on this. I’ve helped several partners in developing a strategy. Most of the time free of charge. Most people use (abuse) me because I have authority to send a message to their management and get attention.

      Not looking to make money, but to make a better community.

      Like

      Reply
  2. Shankar

    Mark, it will really hard for the companies maintaining their vertical such as LS Retail and like our company manages Wealth Management system inside NAV, we just use NAV as development tool because you can develop things quickly and even trickery and complex solution can be developed in weeks. Now this whole new strategy from Microsoft questions us how we move forward…

    Liked by 1 person

    Reply
  3. monckfish

    When you say .net core do you mean seperate .net applications interacting with Nav via the api? Or do you mean azure functions that do specific features that al code hooks into when needed?

    Like

    Reply
  4. Andreas Nilsson

    Hi Mark,
    Great stuff!

    We´re trying to use the same approach as you with many small extensions.
    The problem we´ve encountered is that the dependency system for extensions in NAV is a bit hard to use.

    Let´s say that every developer on the project uses a local docker instance on his/hers computer to develop against with vs code. No one needs to worry about disturbing some data import, test scenario or any other developer. When the developer is happy, he/she merges the git branch into “test” and the extension automatically is deployed to the test/qa environment for validation.

    This works very nice for us in every way except for the dependecies. When a new developer comes aboard the project, our vision is that this developer does a git clone of the repo and install all dependecies that particular extension uses. Just like you do in every other language like c# or javascript.

    We currently have our extensions in a private npm register, and can accomplish this using a simple npm install command. However, there is no validation against object numbers and so on and I see a great risk moving forward with this that we will mix it up….

    This approach is meaning that everything we develop for a specific cusomter/project is one big extension, with the dependency management in a package.json file. With the big drawback you pointed out, that the compiler is having a hard time.

    How do you manage dependencies in your projects? Are all developers developing against the same NAV instance?

    Like

    Reply
    1. Mark Brummel Post author

      I don’t think I understand the problem. In the dependencies you assign a version number. NPM should download that version number. Can you send me a contact message so we can have a quick skype call about this? I am curious.

      Like

      Reply
  5. thetazzbot

    I am in the situation where we have a large application made up of third party modules (2 dozen) in 2009 and we need to “migrate” the functionality to 2018. VP wants us to use extensions, but these third parties have added numerous fields to core tables (Table 9 etc). Their functionality may or may not depend on those fields being on the core table. So I’m stuck. I argued with the boss over this and my main complaint is how to access the extension table data from C/AL code. RecordRef/FieldRef can access it but that is bloody cumbersome. Perhaps the solution is to write our entire solution in AL (also horribly cumbersome).

    For the extension development, I envision a directory structure with extensions in subfolders. You exclude app.json and launch.json from the version control system. The build server would have its own app.json/launch.json which has a single GUID for the solution. This way there is one version to build and deploy to QA/PROD etc. We have 12 prod and 12 qa instances of the application, plus a shared DEV currently. We are concerned about extensions to tables that have 100 million records..and performance of installing updated extensions.. PS I sent you a message on LinkedIn.

    Like

    Reply
    1. Mark Brummel Post author

      Why don’t you use 2018 as intermediate where you still go C/Side & VSCode hybrid. The next upgrade can be extensions only when everything is more mature.

      This is what I do and what I will present at NAVTechDays.

      Like

      Reply

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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