Category Archives: Dynamics NAV

Working on Design Patterns for Business Central

Yesterday at Microsoft I had two meetings, or goals. The first as you know was about our initiative to do a proof of concept to break the BaseApp into smaller extensions.

The second meeting was about revamping the old Design Patterns we had for Dynamics NAV and bringing them up to speed for Business Central.

For those of you who don’t know or to refresh memories; a few years ago there was a joint project between Microsoft and the community to document Design Patterns.

The old patterns wiki still exists but there have not been any updates.

A Modern World

Things have changed a lot in the last few years and Microsoft moved from MSDN to Docs who are open source and maintained on GitHub in markup language.

Within Microsoft there is a standardised way of documenting best practices with code examples, also maintained on GitHub that must me working examples people can clone and compile.

Five years ago all of this did not exist and even if it would, C/Side would not integrate anyway.

Thinks have changed for sure.

Perfectly Mixed Priorities

When talking to Business Central leadership there is a need to publish modern patterns about extensibility. This is is awesome but my personal ambition has always been to keep the old patterns alive.

We agreed that this would be a perfect mix since MSFT can take the lead on the modern stuff and the community will update the old patterns if they still make sense.

Examples

Step one will be to publish half a handfull of examples to inspire people. I will take on this task and work with Microsoft on finetuning the process

Call on the Community

The first patterns project was driven by transparency and community. I hope to be able to call again on you folks, my readers. If we get 5 to 10 volunteers to update some of the old patterns to Markup Language and AL/GitHub we should have them up to date in notime.

So please maintain some patience while we execute on some of the first steps, the plumbing. This always take longer than you expect but it will be there eventually.

Thanks, and goodbye from CPH airport.

Enum != SchemaChange

I love a nerdy title and I love learning about cool new smart stuff.

But before you continue reading I want to say thanks to my colleagues at ForNAV, especially Michael Nielsen. Without him pushing me (again) to step out of my comfort zone this would not have been possible.

Yesterday I visited the Microsoft office in Lyngby for the first time in a very, very long time to talk about our project to split up the base app. We also talked about something else, but that will be another blog. (Soon…).

The biggest showstopper we had in the old days with C/Side to separate code was the option field. Option fields are often where modules get together and programmers make switches in the code about which business logic to execute.

This is fixed now with the enum, and it will be even better in the next spring release with the interface implementations.

But before you can execute on that you have to change the Option field into an Enum. And yes, this means changing a field type.

Changing field types is not allowed in AL when you run on AppSource. You have to obsolete the field and introduce a new field.

You can imagine that this makes implementing this feature incredibly complex right?

The day before yesterday’s meeting however I sat down with Michael at our office in Horsholm to see if we needed to make changes to the ForNAV product in order to implement Enum support.

Imagine how surprised we were when we noticed that the FieldType::Enum did not exist.

And we did some testing and it looked as if an Enum field returns FieldType::Option.

I tweeted to #BCAlHelp and got no logical answer.

So I decided to save this question for my meeting with Microsoft, also because one of our team members, Cristina Nicolàs identified the schema change as a project risk.

At Microsoft I was happy to learn that this is all by design. Someone smart at Microsoft must have realised that since at SQL Server level this is always an Integer anyway it would only make sense to allow this flipping without making a breaking change.

The Test!

Off course I had to test this in order to blog about it.

I have created a simple table with an option field and published this to a Sandbox.

Next I change it to this

And yes, I can publish this without getting errors.

Enums will come in next Spring Release!

All of the teams in our project of splitting up the base app implemented their own Enum’s because last Fall release was shipped without it.

We were happily surprised to hear that Microsoft has implemented the Enum in the usual suspected places and they are expected in the next Spring release.

I’ve been told, but I did not yet have time to confirm this, that the Insider Docker build already as this code. The compiler of this Docker image also allows you to play around with Interface objects.

Enjoy!

Again, thanks to everyone to make this possible and transparent. Thanks to the Base App split team and thanks to Jesper and Bugsy at Microsoft,

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.

Breaking up BaseApp | Business Central

Social media is fantastic and it can be used in many different ways. Where most people are mostly consumers others use it to ask questions. Some share knowledge and experience and gain loyal followers. This is pure awesomeness and mostly rewarded with the Microsoft MVP award for those who don’t give up.

Drive Change

Very few succeed in using social media to drive change. Those who do are known by many such as Elon Musk and Greta Thunberg.

With Business Central we have a very little ecosystem but we also need to drive change from time to time and most often this change is very slow and requires patience.

We’ve been through a lot of changes and each and every one challenged our legacy. Just to name a few examples: Move from Dos to Windows in 1995. Move to SQL Server, move from Forms to Pages, implementing RDLC, moving from C/AL to AL, going from Windows Client to Web and last but not least the extensions only model.

During all these changes the code of our beloved application has barely changed a bit. If you open the customer table in the old DOS version of Navision you’ll see code that still exists today. This is just a tiny example.

The most important learning that I take from this is that Business Central was born in the cloud when the cloud has yet to be invented. We’ve always been a lo-code environment before this was hip and modern.

Time to change

In essence there is nothing big that I would like to change to Business Central. Nothing that would drastically destroy the main architecture.

However I do think it’s a bit to big and it could be broken up into a few decoupled modules. Fortunately I am not alone in this quest. This is where social media get’s in.

A few weeks ago I’ve done some calls for action telling that I wanted to experiment making the BaseApp smaller starting with some of the edge cases.

The reason why I think it’s good to make BaseApp smaller is to make it easier to understand for new developpers.

Our Test

We’re trying a few things. One is to make two or three modules into a seperate extension on top of BaseApp. Examples are Service Management, Fixed Assets and Cost Accounting.

Service Management brings challenges to inventory and removing it exactly points out the places where extendability is important.

If we implement events and interfaces/enums at the point where Service Management needs them others can use these points to hook in their apps.

Fixed Assets looks to be a bit more manageable but we’ll hit the interface with Sales and Purchasing. Again, implementing events and interfaces/emums for Fixed Assets will help others plug in modules into these area’s.

Cost Accounting has not been started. This is orriginally a DACH module and more or less stand alone. Curious to see what can of worms we open here.

Lastly one of our team members has a great idea to make Item Tracking more extendable using Argument Tables.

Together with Microsoft

First in Vienna and later at NAVTechDays I talked for a very long time with the engineers at Microsoft and they are open for ideas. I think we both realise that most of the knowledge of BaseApp is in the partner ecosystem and what we need is a manageable bridge between both parties.

This is the challenge I’ve accepted. On top of my “normal” business and my family.

This means the team, now six members, is self managed. We use Microsoft Teams and email to communicate and GitHub to share code.

The process is slow but steady and in January we’ve presenting the first results to Microsoft.

This may just as well be a dead end road but I have high hopes this is not true.

Remember that the modules that I descibe here have been added later to Navision. Had there been extensions back then it would have probably already been loosely coupled.

Both Ends

Microsoft is working very hard from their end to make BaseApp smaller by working more on the generic parts. This is more framework-like work and fits better with the engineering capabilities that Microsoft is good at.

Together we might be able to cut the size in half or maybe two/thirds which would be a great start.

Join Us

If you think you can handle the responsibility of working in a team that is not micro managed where people work when they have time you can join us.

I think we should not make the experiment bigger than it is. Four branches is enough.

Nobody in the team is an mvp. Just mere mortals trying to see if this might work.

Submitting to Business Central Open Source, the code review…

So to continue where we left off yesterday when I did a pull request on the Business Central System App project on GitHub.

After my pull request someone at Microsoft did a code review in order to make sure quality standards are respected. Here are the details:

I have to admit something. First of all, this is not actually my code. It came from my colleague Michael Nielsen. Secondly this blog post is a bit orchestrated since Jesper and I discussed in Antwerp at NAVTechDays how to promote people contributing.

Working with Microsoft is pretty tough since your doing code for millions of users, not just one customer. Business Central should be easy to use and if you call the culture info with for example 0 or 80,943 you’ll get an error explaining that the language does not exist but not in an easy to read way.

I’m tempted to follow the idea to wrap the call in a TryFunction, but that means introducing a readeable error message, which includes translation and I am worried that will delay my pull request.

An alternative is to wrap it into a try function and return the orriginal integer if the call fails.

What do you think? It proves to me that coding for millions is a lot harder than it looks.

Business Central System App is Open Source! Contribute, don't be shy…

With the recent Wave II release of Business Central we also got the first wave of Open Source in our beloved NAV/BC product.

This means that rather than making customization for one specific customer or ISV you can now have this pushed back into the product and stay there forever.

Today I did my first Pull Request and I wanted to share how I did that.

What did I need?

With reports, especially documents that go out, translations are key. In the next release of our ForNAV extension we wanted to add a new feature where you can translate invoices by simply adding captions to a table or import them from an Excel sheet or Azure Blob Container file.

With translations there are rules that allow you to inherrit languages from related languages if they are related. For example Flamish (NLB) can be inherrited from Dutch (NLD).

Especially in Europe this drastically reduces the number of translations and you only have to manage exceptions where terminology is different. (Trust me, this is the case with Flamish and Dutch).

DotNET

I actually only need one line of DotNET code

CultureInfo.CultureInfo(LanguageId).Parent.LCID

Normally you are not allowed to do DotNET, but System App has target set to OnPrem so simple usages of DotNET are actually allowed. (I hope).

Fork & Clone

The first step is to log into GitHub and Fork the Microsoft ALAppExtensions project and clone this to your Visual Studio Code

Branch & Publish

Then you do the change. Remember Microsoft has this two-layer model where your real code is in the implementation.

Pull Request & License

The final step, or at least where I am now, is to do a pull request and sign the license.

After this you need a code review and this is what I am waiting for right now.

Tip #65 | AppSourceCop & mandatoryPrefix

Today I was a bit puzzled by getting this error message and how to fix it.

error AS0054: The AppSourceCop configuration must specify one of the following properties: 'mandatorySuffix', 'mandatoryPrefix', or 'mandatoryAffixes'

Yes, you can google the message but that only brings you to pages that describe the message, not how to fix it.

It appears to be easy so I wanted to spare others the time.