Moving Existing ISV Solutions to the New Extension Model

In this chapter, we'll focus on existing ISV solutions for Dynamics NAV (mainly based on the C/AL language). We'll also look at tips, tricks, and best practices to adopt when moving these solutions to Dynamics 365 Business Central and to the new extension programming paradigm.

The topics we will cover in this chapter are as follows:

• Architectural best practices for moving a C/AL solution to an extension-based one
• Converting existing C/AL code into AL
• Things to check and remember during a solution redesign for SaaS environments

By the end of this chapter, you will have a better understanding of what steps are required to move an existing C/AL solution to AL, the architectural choices when converting a monolithic C/AL solution into extensions (this will affect your final application and how you will sell it...

Preparing the transition from C/AL to AL and extensions

Without a doubt, Dynamics NAV was one of the ERPs in the international market that had the most active community of partners and users. If you are a customer that would like to implement Dynamics NAV, it is really quite easy to find a custom solution that fits and is tailored to your business needs. To do this, just search through one of several add-ons that have been developed by partners or Independent Software Vendors (ISVs) over the years.

All these solutions are written using the C/AL language. Normally, they contain the following:

• New objects (objects that are created to satisfy a customer's business case)
• Modified standard objects (objects from the standard application base code that have been modified to satisfy a customer's need)

These solutions are always a monolithic solution (everything is packaged...

Planning the number of extensions to code

As we mentioned in Chapter 5, Developing a Customized Solution for Dynamics 365 Business Central, extension A cannot reference objects and methods exposed by extension B. This is only possible if extension A explicitly declares a dependency on extension B.

When moving an existing solution to extensions, you have two main choices:

• Create a single monolithic extension
• Create N dependent extensions

Let's explore these concepts in more detail.

A single monolithic extension is an easier choice since developers don't have to think about independent modules. Instead, they just create all the objects and business logic in a single giant AL extension project. In the end, there will be a single .app file that does the following:

• Adds new objects
• Extends standard objects
• Adds new business logic
• Raises events
• Subscribes to events...

Converting existing solutions into AL

Many Microsoft partners that actually work with Dynamics NAV have developed a lot of custom solutions over the years (add-ons, customer solutions, and so on). In order to be ready for the new Dynamics 365 Business Central platform, these must be migrated to AL code.

If you have an existing codebase or an existing solution in place, the first thing you can do when it comes to moving this solution to the extensions world is to try to convert your C/AL objects into AL.

Please keep in mind that conversion is not always the best thing to do, but just a starting point (you can convert all new objects as-is, but you should pay attention and refactor the modified standard objects that your existing solution will certainly have).

So, how can you convert your C/AL solution into AL?

As we mentioned in Chapter 7, Report Development with...

Handling customer-specific personalization's

You've worked hard so far, and now your solution has finished moving from the old C/AL to the new extension's architecture. Now, a common business scenario occurs when you sell your solution to a customer: they want some specific customizations of your solution to satisfy their particular business needs. Here, we immediately have a problem: how can you handle customizations for your customers?

The extension model has some rules, and you need to absolutely avoid the situation represented in the following diagram:

In the preceding diagram, we can see that EXT BASE is the standard solution and its base code is modified for every customer that acquires the solution.

You don't need to directly customize your extension code for every customer you have. Forking your solution's base code is absolutely a bad practice...

Other things to remember

When moving a solution to extensions, there are other things to remember and aspects that you need to handle or rethink. In the upcoming sections, you will find a summary of some of the most common ones.

Handling the MenuSuite

With Dynamics NAV, pages and reports can be searched in the web client by adding them to a MenuSuite object (a standard object that defines the functional menu of the application). With Dynamics 365 Business Central, the MenuSuite object is not supported, and pages and reports can be searchable and visible by setting the UsageCategory and ApplicationArea properties.

If you convert objects from C/AL, you need to set these properties on the converted objects. You can automate...

Dynamics 365 Business Central wave 2 release changes

Dynamics 365 Business Central Wave 2 release (platform 15) is AL- and web-client-only. You will not find support for C/AL and CSIDE anymore. Instead, if you go to the Extensions Management page in Dynamics 365 Business Central platform 15, you will find the following two Microsoft extensions:

• Base Application (version 15.0.<build>.0): This extension contains all the business logic that was moved to AL.
• System Application (version 15.0.<build>.0): This extension handles the system layer.

In addition to simplifying the entire codebase, the main benefits of this new structure are that you can move away from code customizations and start making vertical or horizontal solutions based on the Dynamics 365 Business Central platform. You can set up a staging environment and practice...

Summary

In this chapter, we looked at the best practices of moving an existing monolithic C/AL solution to the new extension architecture and to the AL language. We also saw the best practices of architecting your solution, such as how to convert existing C/AL code into AL in a semi-automatic way, and how to handle common problems during the migration phase of your existing solution.

Toward the end of this chapter, you learned how to migrate to the new Dynamics 365 Business Central platform and the best practices to adopt when starting a project for a new solution. Now, you have a clear vision of the tools to use to migrate existing code to AL and the steps that are required to start this migration activity.

In the next chapter, we'll learn how third-party tools can help us work with AL and extensions, and also help us move our existing solutions to the new Dynamics...