A developer’s overview of Business Central

From the point of view of a developer, Business Central consists of a set of applications with thousands of potentially extensible, off-the-shelf program objects written in the AL programming language. Visual Studio Code, as the integrated development environment (IDE), in combination with the AL Language extension, allows us to work with existing objects and create new ones. Our AL code will compile into a *.app file as yet another application to publish and install.

Note

This book provides an overview of Business Central, including the basics, so that you have a quick hands-on start. To find the complete developer documentation, please refer to Microsoft Docs at https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/#resources-for-a-developer.

Business Central applications

As a developer, we need to be aware of the following applications that form the Business Central application. They have been listed in their dependency hierarchy from top to bottom:

• Base Application: This provides core business processes such as sales and purchasing, customer and vendor management, plus complex processes, such as assembly, manufacturing, service, and directed warehouse management – simply put, the business logic.
• Business Foundation (since version 24): This serves as a foundation for developing business applications, such as No. series management or dimension management. The standard functionality is used globally and not tied to a specific area. Before version 24, the content resided in the Base Application.
• System Application: This contains objects to serve mere technical purposes, such as emailing, OAuth, and RegEx, and provides mathematical functions. These objects support the base application and its interaction with the platform and Microsoft ecosystem.
• System: This provides system objects and virtual tables. We will discuss some of these objects at the end of Chapter 2.

Tip

The Business Central source code is being developed at https://github.com/microsoft/BCApps. The repository is a contribution project. At the time of writing this book, the repository consisted of the System Application, the Business Foundation, and various tools. The Base Application will be added in the future. Please refer to the repository’s README file for more current information.

Business Central object types

Let’s start with basic definitions of the Business Central object types that will be covered in this book. This is meant to act as a rough overview – we will cover them later in this chapter again:

• Table: Tables serve both to define the data structure and to contain the data records.
• Table extension: Table extensions allow for the creation of companion tables that are linked to tables defined by Microsoft in the base product or by other solutions.
• Page: Pages are the way data is formatted and displayed appropriately for each of the client types and user roles.
• Page extension: Page extensions allow controls in existing pages to be added or hidden.
• Report: Reports are provided to display data to the user in hard copy format, computer file format (PDF, Microsoft Word, or Excel), on-screen (preview mode), or via a printing device. Report objects can also update data in processes with or without data display.
• Report Extension: Report extensions allow you to add columns to existing reports’ datasets, add new data items, extend trigger logic, provide additional fields and logic to request pages, and define new layouts.
• Codeunit: Codeunits are containers for code that are utilized by other objects. Codeunits are always structured in code segments called procedures.
• Query: Queries support extracting data from one or more tables, making calculations, and outputting them in the form of a new data structure. Queries can output data directly into charts, Excel, XML, and OData. They can be used as an indirect source for pages and reports.
• XMLport: XMLports allow you to import and export data to/from external files. The external file structure can be in XML or other file formats.
• Profile: Profiles allow you to define Role Centers and group page customizations.
• Enum: Enums (enumerated lists) are extendable options that can be connected to tables and interfaces.
• Enum extension: Enum extensions are extra options that are added to Enums from either the Microsoft Business Central Base App or other extensions.

The Visual Studio Code integrated development environment

Business Central includes an extensive set of software development tools. These Business Central development tools can be accessed through Visual Studio Code and the AL Language extension. We will install the extension soon in the Extensions section, and we will learn about the AL Language extension in the AL programming language section.

The Visual Studio Code IDE is Microsoft’s most popular free code editor and is available for Windows, Linux, and macOS. The images used in this book have been taken on a Windows system. You can download Visual Studio Code from https://code.visualstudio.com/:

Figure 1.2 – Visual Studio (VS) Code with the AL Language extension installed

Let’s explore its interface in more detail.

Visual Studio Code icons

When we open Visual Studio Code, we will see five icons. These icons appear on the left-hand side of the screen. They also determine the navigation part that appears on the left-hand side of your screen. If you click on an icon twice, the navigation part will be hidden and allow full-screen code editing. Let’s see what each of these do in detail.

EXPLORER

The EXPLORER view is the default view when you open a project. It allows you to view the files in a project and select one or more files for editing. The EXPLORER view is shown in the following screenshot:

Figure 1.3 – EXPLORER in VS Code

While the list of files is fine for smaller projects, sometimes, it is necessary to locate a file in a larger list or even text within files.

Tip

We can use Ctrl + P to search files by name.

SOURCE CONTROL

VS Code provides access to a built-in connection to SOURCE CONTROL. When source control is activated, all changes that are made to files are automatically tracked and displayed in this window:

Figure 1.4 – SOURCE CONTROL in VS Code

Further reference

The video Using Git with Visual Studio Code (https://youtu.be/i_23KUAEtUM) explains how to get started with SOURCE CONTROL in Visual Studio Code.

Debugger

You can use the built-in debugger to do basic troubleshooting for your code. The RUN AND DEBUG view is shown in the following screenshot:

Figure 1.5 – The debugger in VS Code

We will learn more about debugging in Business Central in Chapter 7, Intermediate AL.

Extensions

Out of the box, Visual Studio Code doesn’t understand the Business Central AL Language syntax. To activate the compiler, an extension needs to be installed in the EXTENSIONS window.

This extension, called AL Language extension for Microsoft Dynamics 365 Business Central (in this book, it will be referred to as AL Language extension), can be downloaded from the Visual Studio Marketplace or installed directly from Visual Studio Code using Search Extensions in Marketplace:

Figure 1.6 – The AL Language extension in VS Code

Note

The Visual Studio Code Marketplace can be found at https://marketplace.visualstudio.com/.

Microsoft does a monthly update of Business Central and the AL Language extension. Usually, you install and use the most current version released in the Marketplace. There is also a pre-release version available that allows early access to features that are being prepared for the next major version of Business Central.

SEARCH

The SEARCH view provides an advanced search and replace option within the files of your project. The SEARCH view is shown in the following screenshot:

Figure 1.7 – SEARCH in VS Code

Visual Studio Code provides an easy-to-understand toolset that’s used by many programmers. The AL compiler extension provides an entry point for you to extend and develop new areas in the Microsoft 365 Business Central application. Later, we will get into the additional benefits of its deep integration with Git and repositories to control code development between one and more developers.

AL programming language

The language in which Business Central is coded is AL. A small sample of AL code within Visual Studio Code is shown here:

Figure 1.8 – Example of AL code

AL syntax is similar to Pascal syntax. But other than Pascal, AL is not an object-oriented programming language but an object-based one. Code readability is always enhanced by careful programmer attention to structure and logical variable naming, as well as ensuring that the process flow is consistent with that of the code in the base product and that there is good documentation both inside and outside of the code.

Good software development focuses on design before coding and accomplishing design goals with a minimal amount of code. Dynamics Business Central facilitates that approach. In 2012, a team made up of Microsoft and Business Central community members began the NAV design patterns project. As defined by Wikipedia, a design pattern is a general reusable solution to a commonly occurring problem.

In 2022, long after the transition to Business Central and the AL language, the project was relaunched as Business Central design patterns and moved to another website: https://alguidelines.dev/docs/.

Note

One of the primary goals of this project is to document patterns that exist within Business Central. In addition, new best practice patterns have been suggested as ways to solve common issues we encounter during our customization efforts. Now, when we work on Business Central enhancements, we will be aided by references to the documentation of patterns within Business Central. This allows us to spend more of our time designing a good solution using existing, proven procedures (the documented patterns) and less time writing and debugging code. Please refer to the Reusing Code section of Business Central at https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-programming-in-al#reusing-code for more information.

Much of our Business Central development work is done by assembling references to previously defined objects and procedures and adding new data structures where necessary. As the tools for Business Central design and development that are provided both by Microsoft and the Business Central community continue to mature, our development work becomes more oriented toward design and less toward coding. The result is that we are more productive and cost-effective on behalf of our customers. Everyone wins.

Business Central object elements

Here are some important terms that are used in Business Central:

• Field: An individual data item, defined either in a table or in the working storage (temporary storage) of an object.
• Record: A group of fields (data items) that are handled as a unit in many operations. Table data consists of rows (records) with columns (fields).
• Control: In Microsoft Developer Network (MSDN), a control is defined as a component that provides (or enables) UI capabilities.
• Properties: These are the attributes of the element, such as an object, field, record, or control, that define some aspect of its behavior or use. Example property attributes include display captions, relationships, size, position, and whether the element is editable or viewable.
• Trigger: These are mechanisms that initiate (fire) an action when an event occurs and is communicated to the application object. A trigger in an object is either empty or contains code that is executed when the associated event fires the trigger. Each object type, data field, control, and so on may have its own set of predefined triggers. The event trigger name begins with On – for example, OnInsertRecord, OnOpenPage, or OnNextRecord. Business Central triggers have similarities to those in SQL, but they are not the same (similarly named triggers may not even serve similar purposes). Business Central triggers are locations within objects where a developer can place comments or AL code.
• Procedures: These can be defined by the developer. They are callable routines that can be accessed by other AL code from either inside or outside the object where the called procedure resides. Many procedures are provided as part of the standard product. As developers, we may add custom procedures as needed.
• Attributes: An attribute is a modifier on a procedure declaration that controls the procedure’s use and behavior.
• Object numbers and field numbers: All objects of the same object type are assigned a number that’s unique within the object type. All fields within a table object are assigned a number that’s unique within the object (that is, the same field number may be repeated within many objects, regardless of whether it is referring to similar or different data). In this book, we will generally use comma notation for these numbers (fifty thousand is 50,000). In AL, no punctuation is used. The object numbers range from 1 (one) to 49,999 and those from 100,000 to 999,999 are reserved for use by Business Central as part of the base product. Numbers from 1,000,000 (one million) to 74,999,999 are reserved for partners. Field numbers in standard objects often start with one (1). Historically, object and field numbers from 50,000 to 99,999 are generally available to the rest of us for assignment as part of extensions that are developed. Field numbers from 90,000 to 99,999 should not be used for new fields that have been added to standard tables as those numbers are sometimes used in training materials. Microsoft allocates ranges of object and field numbers to independent software vendor (ISV) developers for their add-on enhancements. Some such objects (the 14 million range in North America, and other ranges for other geographic regions) can be accessed, modified, or deleted, but they can’t be created using a normal development license. Others (such as in the 37 million range) can be executed but not viewed or modified with a typical development license. The following table summarizes this object numbering practice:

Object Number Range	Usage
1 – 9,999	Base application objects
10,000 – 49,999	Country-specific objects
50,000 – 99,999	Customer-specific objects
100,000 – 999,999	Localization-specific objects
1,000,000 – 74,999,999	Partner-created objects

Table 1.1 – BC object number ranges

• Events: Procedures can subscribe to events that are raised in the system. Business Central has both platform and manual events. Procedures can also be used to raise events.
• Work date: This is a date that’s controlled by the user operator. It is used as the default date for many transaction entries. The system date is the date that’s recognized by Windows. The work date that can be adjusted at any time by the user is specific to the workstation and can be set to any point in the future or the past. This is very convenient for procedures such as the ending sales order entry for one calendar day at the end of the first shift, and then the second shift entering sales orders dated to the next calendar day. Some settings allow you to limit the range of work dates allowed. The work date can be set by clicking on the cogwheel drop-down list next to the question mark icon and selecting the My Settings option:

Figure 1.9 – Settings in the Business Central client

Clicking on My Settings in the dropdown displays the My Settings screen. Here, we can enter a new Work Date value:

Figure 1.10 – Work Date on the My Settings screen

In addition to basic functionality, you will also encounter terminology that’s used in the functional areas that are important to understand for development purposes.

Business Central functional terminology

For various application functions, Business Central uses terminology that’s more similar to accounting than to traditional data processing terminology. Here are some examples:

• Journal: A table of unposted transaction entries, each of which represents an event, an entity, or an action to be processed. There are general journals for general accounting entries, item journals for inventory changes, and so on.
• Ledger: A detailed history of posted transaction entries that have been processed – for example, the general ledger, customer ledger, vendor ledger, and item ledger. Some ledgers have subordinate detail ledgers, typically providing a greater level of quantity and/or value detail. With minor exceptions, ledger entries cannot be edited. This maintains auditable data integrity. Business Central has a posting logic-driven data integrity that is founded on General Ledger Entries tying to all other ledgers.
• Posting: The process by which entries in a journal are validated, and then entered into one or more ledgers.
• Batch: A group of one or more journal entries, posted at the same time.
• Register: An audit trail showing a history, by entry number ranges, of posted journal batches.
• Document: A formatted page such as an invoice, a purchase order, or a payment check, typically one page for each primary transaction (a page may require display scrolling to be fully viewed).

UI

The Business Central UI is designed to be role-oriented (also called role-tailored). The term role-oriented means tailoring the available options to fit the user-specific job tasks and responsibilities.

The first page that a user will see is the Role Center page. The Role Center page provides the user with a view of work tasks to be done; it acts as the user’s home page. The Role Center home page should be tailored to the job duties of each user so there are a variety of Role Center page formats for any installation.

Someone whose role focuses on order entry will probably see a different Role Center home page than the user whose role focuses on invoicing, even though both user roles are in what we generally think of as sales and receivables. The Business Central tailorable Role Center allows a great deal of flexibility for implementers, system administrators, managers, and individual users to configure and reconfigure screen layouts and the set of functions that are visible to a particular user.

The following screenshot is the out-of-the-box Role Center for a business manager:

Figure 1.11 – Business Central – Role Center

The key to properly designing and implementing any system, especially a role-tailored system, is the quality of the user profile analysis that’s done as the first step in requirements analysis. User profiles identify the day-to-day needs of each user’s responsibilities, relative to accomplishing the business’s goals. Each user’s tasks must be mapped to individual Business Central functions or elements, identifying how those tasks will be supported by the system.

Important

A successful implementation requires the use of a proven methodology. The upfront work must be done and done well. The best programming cannot compensate for badly defined goals.

In our exercises, we will assume that the upfront work has been well done, so we will concentrate on addressing the requirements that have been defined by our project team.