Dynamics 365 BC Wave 2 Release: What Happens Now?

Stefano Demiliani Microsoft MVP for Business Applications

Microsoft Dynamics 365 Business Central is the latest Microsoft’s ERP solution, available on-premise and on Cloud as a SaaS service. Microsoft Dynamics 365 Business Central is actually released as platform version 14.X. and this platform permits you to adopt two different programming models for creating customizations:

Using old C/AL code (available only for on-premise scenarios), with customizations created in C/SIDE as in the old NAV platform.
Using AL code and the extension’s model (available for on-premise and the only supported way for the SaaS platform), with extensions created by using Visual Studio Code.

Important features and changes of Wave 2 release

As you all probably already know, starting from October Microsoft will release a new Dynamics 365 Business Central release which you may call October release, Wave 2 release or (I think it’s more clear) platform 15 release.

Wave 2 release introduces important features and (especially) important changes for customers and partners:

new user interface features;
new platform features (multiple production environments, the possibility to handle backups, etc);
no more Windows Client (Wave 2 release is Web Client only);
no more C/AL and C/SIDE: all customizations must be done by using AL language and extensions.

With the Wave 2 release, Microsoft has converted the monolithic C/AL application to AL. Also, they have started to implement an important feature that will be valuable in the future: splitting the application’s code into N separate extensions.

In the October release, you will find two Microsoft’s extensions:

Base Application: this contains all the ERP entities and business logic;
System Application: this is is the interface to the Business Central platform and cloud ecosystem and it contains all the system-related entities and functions.

However, in the future expect to see more than two apps.

When you create new extensions for the Wave 2 release, your extension’s code must be dependent on those two Microsoft’s apps (dependencies will be automatically added to the app.json file when you create a new AL project that targets the Wave 2 release).

The Base Application is a pure code conversion of the old C/AL code to AL.

The System Application is actually where Microsoft has put their hands on in a consistent way. The extension’s code is publicly available on GitHub here.

As you can see from this repository, the System Application contains a huge set of modules:

Each module has the following architectural schema:

To ensure low coupling and high cohesion, every module is a separate entity equipped with a publicly accessible interface (facade), while the internal implementation of each module is hidden to the outside (public access).

As an example, here is the implementation of the Cryptography module in the System Application:

The module’s publicly accessible interface is defined in a codeunit called Cryptography Management and defined with Access = Public.

This codeunit contains all the publicly exposed functionalities (for example Encrypt, Decrypt, etc.).

The details of each functionality are defined in a separate codeunit, called Cryptography Management Impl. This codeunit contains all the internal implementation for each functionality and it’s defined as Access = Internal:

You can learn more about Access Modifiers in Dynamics 365 Business Central Wave 2 release by reading this article.

To summarize the logic, by setting Access = Public the object can be accessed by any other code in the same module and in other modules that reference it.

Instead, by setting Access = Internal an object (here a codeunit) can be accessed only by code from the same extension but not from another extension.

This logic is implemented and respected in every module into the System Application. Usually, module can be extended, but in cases that module can’t be extended by design, Microsoft uses the Extensible property on tables, pages, and enums set as false. Here is an example that you can find in the Language module:

Creating separate modules with a defined pattern is absolutely a great thing for many aspects:

separation of concerns;
encapsulated complexity;
stable APIs exposed through a public interface;
each module can be developed, tested and updated separately;
security: N modules means a smaller attack surface and so more easy to secure.

And last (but not least) there’s also a new interesting aspect to consider now for every partner: we’re going for an open-source contribution model!

Having a separation of the standard application’s base code in two apps (System Application and Base Application) means also another extremely important aspect for partners and ISVs: if you want to create a custom business solution that does not require interactions with the standard ERP entities and business logic, you can now create a new Dynamics 365 Business Central extension by adding dependencies from the System Application only (no more needs to references the Base Application).

A detailed article about this possibility you can find here.

Future scenarios of the Wave 2 release

Here, I’ve turned on the light for a possible future scenario for partners: hosting custom applications inside the Dynamics 365 Business Central platform, without using (and exposing) the standard ERP logic! With a proper licensing model, I think that it could be a new power on your hand as a partner (you could develop and deploy custom applications inside a business platform managed by Microsoft). Have you ever heard about the xRM concept? That is the same possible scenario here, with the power of AL and the Dynamics 365 Business Central platform.

Another myth to clarify: with Wave 2 and AL-only, can I still modify the base code for on-premise?

The answer is YES! I will never stop to say that this must be seen as a worst practice and please try to avoid this as much as possible, but for the on-premise world, you will be able to modify the base code by directly editing the base .al files created by Microsoft, and then creating your custom Base Application.

If you will do that, please always remember the following sentence: ‘in the future, on-premise will follow cloud rules’!

In this article, I’ve described the main changes inside the Dynamics 365 Business Central architectures with the Wave 2 release. Now that Wave 2 (or V15) release will be out, what should I do with my applications? What is the impact of this code refactoring? Will Microsoft breaks my extensions?

The answer is: no! Microsoft guarantees that for 1 year to come there won’t be any breaking changes and everything will be handled by deprecating obsolete objects to guarantee backward compatibility.

What does it mean?

In other words, in your extensions (that works on the latest 14.X platform) you could have parts in your code that must be adapted to the new application’s structure. To give a quick example of this, imagine having a procedure that references the TempBlob table.

If you use this extension’s code for the new Wave 2 (or platform 15) release, you will receive this warning:

This means that you can still use your old code, but shortly Microsoft will remove that table.

For version 15, you will need to use the BLOB Storage Module, alias the new modules available in the System Application extension. For version 15, this code should be refactored in the following way:

More clean isn’t it?

Are you excited for the Dynamics 365 Business Central Wave 2 release? See you at Directions EMEA 2019, where you will hear more about all the huge work that Microsoft has done on this new Dynamics 365 Business Central October release.