1.1 Business Central Architecture & Extensions Model

1.1 Architecture, Components & Extensions Approach

Microsoft Dynamics 365 Business Central is an enterprise resource planning (ERP) platform built on a modern, decoupled three-tier architecture. For developers preparing for the MB-820 certification, mastering the physical and logical layers of the platform—and understanding how the AL runtime executes code without altering core binaries—is the foundational prerequisite for all development tasks.

1. The Three-Tier Architectural Topology

The Business Central architecture separates presentation, business logic execution, and data persistence into distinct tiers. This separation allows the platform to scale horizontally in Microsoft Azure while providing a consistent developer and user experience across cloud (SaaS) and on-premises deployments.

+-----------------------------------------------------------------------+
|                             CLIENT TIER                               |
|   - Modern Web Client (HTML5 / TypeScript / React)                    |
|   - Mobile & Tablet Apps (iOS / Android)                              |
|   - Microsoft 365 Integrations (Teams Tabs / Outlook Web Add-ins)     |
|   - External Web Service Consumers (REST / OData v4 / SOAP / APIs)   |
+-----------------------------------------------------------------------+
                                   │ (HTTPS / WebSockets / WCF / TLS 1.3)
                                   ▼
+-----------------------------------------------------------------------+
|                   BUSINESS CENTRAL SERVER (NST) TIER                  |
|   - Navision Server Tier (.NET Core Runtime Service Host)             |
|   - AL Metadata Compiler & Virtual Execution Engine                   |
|   - Data Access Layer (DAL) & SQL Query Generator                     |
|   - In-Memory Cache (Global Object Cache, Record & Query Cache)       |
|   - Session Manager, Background Task Scheduler & Job Queue Engine     |
|   - API & OData Web Service Endpoints                                 |
+-----------------------------------------------------------------------+
                                   │ (Encrypted TDS / SQL Connection Pool)
                                   ▼
+-----------------------------------------------------------------------+
|                              DATA TIER                                |
|   - Azure SQL Database (Cloud SaaS) / SQL Server (On-Premises)        |
|   - Base Application Tables & Data Dictionary Metadata                |
|   - Extension Companion Tables ([AppID$Table$ExtID])                  |
|   - Document Storage & Azure Blob Storage for Attachments             |
|   - Tenant-Isolated Schemas (Multi-Tenant Shared DB / Dedicated DB)   |
+-----------------------------------------------------------------------+

Tier 1: The Client Tier (Presentation)

The presentation layer consists entirely of web-based and API-driven interfaces. Unlike legacy Dynamics NAV clients (the Windows Classic and RoleTailored clients), modern Business Central clients execute no local business logic:

• Web Client: A responsive HTML5, CSS, and TypeScript application rendered by the Web Server component. It communicates with the server tier over HTTPS and WebSockets for real-time UI updates.
• Mobile & Tablet Apps: Native wrapper shells for iOS and Android that render the responsive Web Client layout customized for touch gestures and mobile form factors.
• Microsoft 365 Integrations: Deeply embedded clients within Microsoft Teams (context cards and tab views) and Microsoft Outlook (email document lookup add-in).
• External API Clients: Third-party applications, Power Platform connectors, and integration pipelines consuming standard API pages (PageType = API) and OData v4 endpoints.

Tier 2: Business Central Server (Navision Server Tier - NST)

The middle tier is a high-performance, multi-tenant .NET Core application service known historically and internally as the Navision Server Tier (NST). The NST acts as the orchestration brain of the platform:

1. AL Execution Engine: Loads compiled AL packages (.app), caches object definitions, and executes AL business logic in an optimized virtual runtime.
2. Data Access Layer (DAL): Translates high-level AL record operations (Rec.FindSet(), Rec.CalcFields(), Rec.ModifyAll()) into parameterized, optimized Transact-SQL (T-SQL) statements.
3. Caching Layer: Maintains in-memory caches of table schemas, user permissions, compiled AL bytecode, and record data (global cache and session-level cache) to minimize round-trips to the database tier.
4. Session & Job Queue Engine: Manages active user sessions, web service workers, child background sessions (TaskScheduler.CreateTask()), and automated scheduled jobs.

Tier 3: The Data Tier (Persistence)

The data layer handles physical data storage, transactional integrity (ACID compliance), and schema management:

• Cloud (SaaS): Hosted on elastic Azure SQL Database instances managed entirely by Microsoft, featuring automated backups, read scale-out replicas, and threat detection.
• On-Premises: Hosted on Microsoft SQL Server or Azure SQL Managed Instance, allowing direct database access and custom DBA maintenance plans.
• Tenant Separation: In a multi-tenant cloud environment, multiple tenant databases can connect to a shared NST cluster, or tenants share a single database containing isolated tenant schema partitions.

2. The Modern Extensions Model vs. Legacy C/SIDE

In legacy versions of Dynamics NAV (prior to Business Central 2018 / AL), customizations were developed using C/SIDE (Client/Server Integrated Development Environment) and the C/AL language. In C/SIDE, developers directly modified the base Microsoft source code. If a partner needed to add a field to the Customer table or modify a posting routine in Codeunit 80 (Sales-Post), they changed the core object directly.

The Upgrade Debt Problem of C/SIDE

Direct code modification created severe technical friction:

• Monolithic Entanglement: Upgrades required manual line-by-line code merges (using text comparison tools) across hundreds of modified objects.
• High Upgrade Costs: Upgrading to a new release took months of billable effort, leaving thousands of customers stranded on obsolete NAV versions.
• Zero SaaS Feasibility: A multi-tenant public cloud cannot allow tenants to overwrite shared base application binaries.

The Additive Modern AL Model

Modern Business Central development uses the AL (Application Language) extension model. In this paradigm, Microsoft's Base Application and System Application are completely immutable packages (.app files). Developers can never modify, overwrite, or delete lines of Microsoft source code. Customizations are strictly additive and packaged into independent, modular extensions.

Legacy C/SIDE Approach (Destructive Overwrite):  
[ Base Application Source Code ] ──> (Developer edits line 42) ──> [ Broken Upgrade Path ]

Modern AL Extension Approach (Additive & Layered):
[ Base Application (.app) ] ── (Immutable Core Engine) ──
           ▲
           │ Depends on
[ AppSource ISV App (.app) ] ── (Extends Tables, Adds Pages, Hooks Events)
           ▲
           │ Depends on
[ Per-Tenant Extension (.app) ] ── (Adds Customer-Specific Fields & Logic)

Extension Object Types in AL

AL introduces specialized extension objects that augment existing base objects without touching their definitions:

3. Database Layer Mechanics: Companion Tables

When a developer creates a tableextension in AL to add custom fields to an existing base table (such as Customer or Item), Business Central does not execute ALTER TABLE [Customer] ADD [CustomField]... on the physical database. Modifying base tables directly would lock shared schemas and break version rollbacks.

Instead, the NST creates a Companion Table in the SQL database:

• Naming Convention: [Company$BaseTableName$AppGUID] (e.g., CRONUS USA, Inc.$Customer$4378856a-1b4e-4fc1-a832-6a365287f3b5).
• Primary Key Matching: The companion table contains the identical primary key field(s) of the base table along with the newly declared custom fields.
• Transparent Joining: When AL code requests records via Rec.Get() or Rec.FindSet(), the NST Data Access Layer automatically performs an internal SQL LEFT OUTER JOIN between the base table and all installed companion tables matching the active tenant and extension set.
• Performance Optimization: If the developer uses modern AL partial record capabilities (Rec.SetLoadFields('CustomField')), the NST avoids joining unused companion tables, minimizing SQL I/O overhead.

4. Event-Driven Architecture: Decoupling Logic

Because developers cannot insert custom lines of code into base business routines (such as ledger posting routines Sales-Post or Gen. Jnl.-Post Line), Business Central relies on an Event-Driven Architecture to execute custom code.

Event Publishers vs. Event Subscribers

1. Event Publishers: Declared in base codeunits and tables using [IntegrationEvent] or [BusinessEvent] attributes. Microsoft embeds thousands of event hooks before, during, and after critical transactions.
2. Event Subscribers: Declared in custom extension codeunits using the [EventSubscriber] attribute. When the published event fires, the runtime executes all subscribed listener procedures.

// Base Microsoft Codeunit 80 ("Sales-Post") publishes an integration event:
[IntegrationEvent(false, false)]
local procedure OnBeforePostSalesDoc(var SalesHeader: Record "Sales Header"; PreviewMode: Boolean; CommitIsSuppressed: Boolean; var IsHandled: Boolean)
begin
end;

// Custom Per-Tenant Extension Codeunit subscribes to the event:
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnBeforePostSalesDoc', '', false, false)]
local procedure CheckCustomCreditHold(var SalesHeader: Record "Sales Header"; var IsHandled: Boolean)
var
    Customer: Record Customer;
    CustomCreditHoldErr: Label 'Customer %1 is placed on mandatory executive credit hold.', Comment = '%1 = Customer No.';
begin
    if SalesHeader."Document Type" = SalesHeader."Document Type"::Order then begin
        Customer.Get(SalesHeader."Sell-to Customer No.");
        if Customer."Custom Credit Blocked" then
            Error(CustomCreditHoldErr, Customer."No.");
    end;
end;

Exam Watchout — The IsHandled Pattern: Many Microsoft integration events pass a var IsHandled: Boolean parameter. If your subscriber sets IsHandled := true;, it signals to the base calling routine that custom logic has fulfilled the operation, causing the base routine to bypass its default implementation. Use this pattern cautiously to avoid breaking standard accounting integrity.

5. Per-Tenant Extensions (PTE) vs. AppSource Apps

In modern Business Central development, all custom AL code is authored as an extension package, but extensions are bifurcated into two distinct operational categories:

Extension Dependencies and Layering Rules

Extensions can establish explicit dependencies on other extensions through the dependencies array in app.json:

• An extension can depend on the System Application, the Base Application, and any number of AppSource Apps or Library PTEs.
• When Extension B depends on Extension A, Extension B has access to all public and internal (if granted via internalsVisibleTo) objects, tables, fields, and procedures declared in Extension A.
• Circular dependencies are strictly illegal: Extension A cannot depend on Extension B if Extension B directly or indirectly depends on Extension A.
• If Extension A is uninstalled, any dependent Extension B must either be uninstalled first or cascaded during the uninstallation operation.