An amazing week at Antwerp with lots of workshops, sessions and talks with experts is over. My personal conclusion after my 4th year at this high level technical #deep-dive conference:

No “Big Surprises”, no “Big Changes”, but some “Promising Improvements” of Microsoft Dynamics 365 Business Central as product and a strong focus of Integration Scenarios.

In my opinion the “Big Picture” at the roadmap gets more clear and many sessions provided a sneak peek into future with a common message:

1. The development process will be automated as much as possible
   …my personal favorite 🙂
2. A new era of application architecture has begun.
3. Integration Scenarios are extremely powered by API’s, Azure and the Power-Plattform

Azure DevOps Automation

Almost every big partner have started to use DevOps and CI / CD pipelines to support the modern development process. There are mostly similar scenarios for the CI and CD processes and I’m so proud that we have made our homework at COSMO CONSULT!

Multi Stage pipelines defined in YAML are an alternative to Classic Release Pipelines. Kamil Sacek presented an approach of “One App per Business Case / Requirement”.

I have learned:

• You can include templates in yaml files
  This fact offer a much better maintainability and helps to avoid unnecessary code copies.
• Templates used together with Multi Stage Pipelines are usable for simple deployment scenarios

I’ll check this definitely out and improve my own CI / CD processes and templates!

Application Architecture

Mastering CI / CD give you an additional player to you team. But now it’s time to think about the right architecture of our Microsoft Dynamics 365 Business Central Apps.

The shown solutions had these key messages:

• All avoid another MEGA (Per-Tenant)-App
• All have created Tiny Apps as a kind of Micros-Services
• All include Test Automation from beginning

Tiny Microservice Apps

I have learned: it make sense to split and divide customer requirements into small chunks and Apps. Each App is manageable and you have full control during the roll-out process.

In huge enterprise scenarios, you can decide which requirement is implemented, tested, and is ready for deployment – because every “Micro-App” have it’s own release and dependencies.

Eric (Waldo) Wauters showed some interesting examples of dependant Apps:

He also pointed his finger to the “Dark Side” of this approach.

Splitting your solution into small chunks means, you have to manage a lot of dependencies. If you do it right, everything is fine. If not, you went into a “Dependency Hell”.

Future AL Language Improvements

Since C/Al have passed away, the AL Language and the compiler are not longer limited. Enums, Enum-Extensions and all the other cool stuff were limited in their possibilities.

Microsoft showed a new – long requested – feature which they are currently working on: Interfaces (coming soon)

// (interfaces may be provided in a future release / syntax may vary)
interface IVehicle
{
    procedure GetMaxSpeed(): Decimal;
}

// (interfaces may be provided in a future release / syntax may vary)
codeunit 50100 CarImpl implements IVehicle
{
    procedure GetMaxSpeed(): Decimal;
    begin
        exit(230);
    end;
}

Interfaces will be introduced in the future to manage the usage of Enum Extensions:

// (interfaces may be provided in a future release / syntax may vary)
enum 50100 Vehicles implements IVehicle
{
    Extensible = true;
    
    value(0; Car)
    {
        Implementation = IVehicle = CarImpl;
    }

    value(1; Truck)
    {
        Implementation = IVehicle = TruckImpl;
    }
}

// (interfaces may be provided in a future release / syntax may vary)
enumextension MyVehicles extends Vehicles
{
    value(2; Bike)
    {
        Implementation = IVehicle = BikeImpl;
    }
}

// (interfaces may be provided in a future release / syntax may vary)
codeunit 50101 TruckImpl implements IVehicle
{
    procedure GetMaxSpeed(): Decimal;
    begin
        exit(120);
    end;
}

// (interfaces may be provided in a future release / syntax may vary)
codeunit 50102 CarImpl implements IVehicle
{
    procedure GetMaxSpeed(): Decimal;
    begin
        exit(230);
    end;
}

// (interfaces may be provided in a future release / syntax may vary)
codeunit 50102 BikeImpl implements IVehicle
{
    procedure GetMaxSpeed(): Decimal;
    begin
        exit(50);
    end;
}

Can’t wait to use this design pattern 🙂

New Design Pattern are needed?!

My conclusion, this changes may leads into a new kind of Polymorphism and new Design Pattern for Business Central and Microsoft AL.

Mark Brummel explained and showed me in his Pre-Conference Workshop “AL Master Class” a lot of existing Design Pattern. Many of them were created a long time ago, where code copying was used to create own Business Application Parts like: Journals, Ledgers and Registers.

I see, the separation of App Tables and Table-Extensions with “Companion Tables”, the refactoring of the Base Application and the introduction of Interfaces makes a new approach possible. Think about this:

What, if we could derive from a Journal-Module and implement, extend or override only changes to a proven logic?

• Data is already separated in App specific Companion Tables
• Interfaces provide the needed Abstraction Layer
• Functionality can be implemented in CodeUnits in the deriving App / Module.
• Table-Extensions can modify or extend the Journal information
• …

Everything without copying all for a “Journal” needed objects to a new App. …what if we could do this in the future… 🙂

This all leads me to the conclusion: New design pattern are needed and they will appear by coming language improvements.

BTW – Mark started to share common design pattern for AL on GitHub: https://github.com/al-design-patterns

Integration Scenarios

Microsoft showed during NavTechDay’s Keynote another step of future integration with the Common Data Service (CDS). Drafts showed a new Table type “CDS” and methods to map and synchronize data between BC and CDS.

table 50100 "CDS cds_worker"
{
    ExternalName = "cds_worker";
    TableType = CDS;

    fields
    {
        // ...
    }
}

This shows me, the focus on connecting with other systems without complex “hand made” data transfer mechanism continues and is today much more present.

Business Central API’s

Waldo and Vjekoslav Babic demonstrated another Integration Scenarios by using Business Central API’s in their {ConnectApp}² session. Modern API’s and OAuth2 challenges were explained in some “mind-blowing”, “killer” demos.

The key message in this session was for me again: Include external technologies into a whole business solution by connecting!

Power Platform

PowerPlatform as well as Azure Components are more powerful and diverse than 2 years ago. Both can be used to in lots of integration scenarios together with Business Central.

Alexander Ermakov and Andrey Baludin presented awesome examples for using Power Automate (Flow), Logic Apps, Azure Service Bus and Event Grid to solve real-world business cases.

I didn’t know, how many out of the box connectors are available for Business Central SaaS and OnPrem, but Arend-Jan Kauffmann made me aware:

He shared furthermore integration examples to solve business requirements without implementing everything in Business Central.

And again, the message was: Solve Business Requirements by using present technologies like PowerPlatform.

Conclusion

This conference strengthened my focus on Azure DevOps and a modern software development process within Microsoft Dynamics 365 Business Central.

I’m pretty sure, all the new possibilities and application changes will have a deep impact on common design pattern and development methods.

Finally, modern business applications are much easier to connect than in the past.