Business Central Developer: Der Weg vom AL-Einstieg zur Lead-Rolle

Business Central-Entwicklung bedeutet, Microsoft Dynamics 365 Business Central mit AL, Erweiterungen, Integrationen und automatisierten Bereitstellungsprozessen an konkrete Geschäftsanforderungen anzupassen.

Die Rolle ist technischer geworden, als viele Einsteiger zunächst erwarten. Wer nur Felder auf Seiten ergänzt, bleibt nah an der Anpassungsebene; wer als Senior oder Lead wahrgenommen werden möchte, muss Datenmodell, Ereignismodell, Berechtigungen, Tests, Deployment, Telemetrie und Upgrade-Fähigkeit zusammen denken. Business Central ist ein ERP-System, und Änderungen daran berühren Finanzprozesse, Lager, Einkauf, Verkauf, Schnittstellen und Compliance.

Zuletzt aktualisiert: 2026. Editor-Notiz: Die folgenden Beispiele orientieren sich am modernen Extension-Ansatz mit AL, Visual Studio Code und Business Central Online beziehungsweise aktuellen Sandbox- und Container-Umgebungen. Veraltete Entwicklungsmodelle wie direkte Änderungen an Basisobjekten werden hier nicht als Zielbild behandelt.

Was die Rolle im Business-Central-Ökosystem ausmacht

Ein guter Business Central-Entwickler übersetzt Geschäftsprozesse in wartbare Erweiterungen. Dazu gehört mehr als das Schreiben von AL-Code. Die Arbeit beginnt häufig mit dem Verständnis einer fachlichen Lücke, etwa einer zusätzlichen Validierung im Verkaufsprozess, einer Integration mit einem Lagerdienstleister oder einer branchenspezifischen Buchungslogik.

In der Praxis arbeitet der Entwickler eng mit funktionalen Beratern, Administratoren und manchmal Resellern oder CSP-Partnern zusammen. Funktionale Berater erklären Prozessvarianten und Konfiguration. Administratoren verantworten Umgebungen, Benutzer, Berechtigungen und Betrieb. Entwickler sorgen dafür, dass individuelle Logik sauber über Events, Extensions, API Pages oder Integrationsmuster umgesetzt wird, ohne Upgrade-Pfade unnötig zu blockieren.

Der häufigste Denkfehler beim Einstieg ist ein zu starkes On-Premises-Muster: Basisobjekte gedanklich „ändern“, statt Erweiterungspunkte zu nutzen. In modernen Business-Central-Projekten wird Verhalten über Event Subscriber, TableExtensions, PageExtensions, Interfaces, Codeunits und definierte Abhängigkeiten in der app.json aufgebaut. Ebenso wichtig sind Permission Sets, Versionsbindung und eine nachvollziehbare Veröffentlichungsstrategie, weil eine funktionierende Extension im Entwicklungsmandanten noch keine betriebssichere Lösung ist.

AL-Grundlagen, die wirklich tragfähig sein müssen

AL ist die zentrale Sprache für Business-Central-Entwicklung, aber sie sollte nicht isoliert gelernt werden. Entscheidend ist das Zusammenspiel aus Objekttypen, Ereignissen, Datenzugriff, UI-Erweiterung, Berechtigungen und Paketierung. Microsoft Learn und die offizielle AL-Dokumentation liefern dafür die Referenzbasis; der eigentliche Lernfortschritt entsteht jedoch erst, wenn diese Konzepte in kleinen, realistischen Erweiterungen zusammengeführt werden.

Ein sinnvoller Einstieg ist eine überschaubare Erweiterung, die eine Seite ergänzt, auf ein Ereignis reagiert und eine einfache Validierung enthält. Dadurch wird deutlich, warum Business-Central-Code anders strukturiert ist als klassische Web- oder Backend-Entwicklung. Der Code hängt oft an Geschäftsereignissen, muss aber dennoch lesbar, testbar und upgradefähig bleiben.

Das folgende Beispiel zeigt einen Event Subscriber, der vor der Freigabe eines Verkaufsbelegs eine zusätzliche Prüfung ausführt. Es geht nicht um komplexe Fachlogik, sondern um das Muster: vorhandenes Verhalten wird nicht überschrieben, sondern über ein veröffentlichtes Ereignis erweitert.

Example — Event Subscriber für eine Verkaufsprüfung

codeunit 50100 "Sales Release Checks"
{
    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Release Sales Document", 'OnBeforeReleaseSalesDoc', '', false, false)]
    local procedure CheckExternalReference(var SalesHeader: Record "Sales Header"; PreviewMode: Boolean)
    begin
        if PreviewMode then
            exit;

        if SalesHeader."External Document No." = '' then
            Error('BCDEV001: Eine externe Belegnummer ist vor der Freigabe erforderlich.');
    end;
}

Der Lernwert liegt in der Entkopplung. Der Entwickler greift nicht in die Standard-Codeunit ein, sondern hängt sich an einen Erweiterungspunkt. In produktiven Projekten sollte eine solche Prüfung zusätzlich durch Tests, Berechtigungsüberlegungen und eine klare Fehlermeldungsstrategie abgesichert werden.

Nach den ersten Event- und PageExtension-Beispielen folgt der nächste Qualitätssprung: saubere Objektbenennung, konsistente Nummernbereiche, reduzierte Abhängigkeiten und eine app.json, die Versionen bewusst steuert. Gerade Junior-Entwickler unterschätzen oft, wie schnell unklare Abhängigkeiten später Upgrades oder parallele Entwicklung blockieren.

Von Anpassung zu Produktdenken: PTE oder AppSource?

Eine der wichtigsten Architekturentscheidungen betrifft den Veröffentlichungsweg. Eine Per-Tenant Extension, meist PTE genannt, ist für kundenspezifische Lösungen gedacht und wird direkt in einem Mandanten betrieben. Eine AppSource-App richtet sich dagegen an einen breiteren Markt und muss Validierungs-, Richtlinien- und Versionierungsanforderungen erfüllen.

Die Entscheidung sollte früh getroffen werden, weil sie Entwicklung, Tests, Dokumentation und Support beeinflusst. Eine PTE erlaubt pragmatische Nähe zu einem einzelnen Kundenprozess, bindet die Lösung aber an diesen Mandanten und dessen Release-Rhythmus. Eine AppSource-App verlangt strengere Disziplin: semantische Versionierung, keine Breaking Changes ohne sauberen Migrationspfad, klare App-Metadaten, technische Validierung und ein Wartungsmodell für mehrere Kundenumgebungen.

Aus Entwicklungssicht bedeutet das: Wer eine Lösung möglicherweise später als AppSource-App veröffentlichen möchte, sollte bereits in der PTE-Phase produktähnlich arbeiten. Dazu gehören klare APIs, Feature-Toggles, automatisierte Tests, Telemetrie, dokumentierte Breaking-Change-Regeln und eine Migrationsstrategie für Tabellen- und Feldänderungen.

Tests und Qualitätssicherung als Karrieresprung

Business-Central-Entwickler werden selten dadurch führend, dass sie möglichst viel Code schreiben. Sie werden wertvoll, wenn ihre Änderungen zuverlässig durch Releases, Updates und Prozessvarianten kommen. Testautomatisierung ist deshalb kein Zusatzthema, sondern ein Kernsignal professioneller Entwicklung.

Test-Codeunits prüfen fachliche Regeln und technische Nebenwirkungen. Standard-Testbibliotheken helfen, typische Belege, Kunden, Artikel oder Buchungsdaten kontrolliert aufzubauen. BCTest und containerbasierte Testläufe ermöglichen reproduzierbare Prüfungen außerhalb der lokalen Entwicklerumgebung. Sinnvoll ist eine Teststrategie, die nicht jede UI-Variante abbildet, sondern risikoreiche Geschäftslogik, Buchungsverhalten, Integrationen und Upgrade-Szenarien priorisiert.

Das folgende Beispiel zeigt eine einfache Test-Codeunit. In echten Projekten würde die Testdatenanlage meist über Bibliotheken oder Hilfs-Codeunits erfolgen; hier steht das Muster im Vordergrund.

Example — Test-Codeunit für eine Pflichtfeldprüfung

codeunit 50110 "Sales Release Check Tests"
{
    Subtype = Test;

    [Test]
    procedure ReleaseFailsWithoutExternalDocumentNo()
    var
        SalesHeader: Record "Sales Header";
        ReleaseSalesDocument: Codeunit "Release Sales Document";
    begin
        SalesHeader.Init();
        SalesHeader."Document Type" := SalesHeader."Document Type"::Order;
        SalesHeader."No." := 'TEST-SO-001';
        SalesHeader.Insert(true);

        asserterror ReleaseSalesDocument.Run(SalesHeader);
    end;
}

Der Test macht die erwartete fachliche Blockade explizit. Wichtig ist anschließend die Verfeinerung: stabile Testdaten, klare Assertions, kein Verlass auf zufälligen Mandantenzustand und Trennung zwischen Unit-nahen Tests und längeren End-to-End-Szenarien. Eine reife Testbasis reduziert Angst vor Refactoring und macht Release-Entscheidungen nachvollziehbarer.

CI/CD mit AL-Go, Sandbox und Release-Strategie

Wer von Junior zu Lead wachsen will, muss den Weg vom lokalen Build zur produktionsnahen Auslieferung verstehen. AL-Go for GitHub bietet dafür eine strukturierte Grundlage, weil Build, Test, Artefakte und Releases als Pipeline gedacht werden. Ergänzend bleiben Container mit BcContainerHelper für lokale Reproduzierbarkeit, isolierte Fehleranalyse und versionsnahe Tests nützlich.

Ein robuster Ablauf beginnt im Repository. Änderungen werden per Pull Request geprüft, gebaut und getestet. Danach entsteht ein Artefakt, das in einer Sandbox installiert wird. Erst wenn Smoke Tests, fachliche Abnahme und Telemetrieprüfung unauffällig sind, folgt die Freigabe für Produktion. Ein Rollback ist bei Business Central nicht einfach nur ein technischer Knopf; oft braucht es eine Strategie für Datenänderungen, Upgrade-Codeunits und Feature-Toggles, damit eine fehlerhafte Funktion deaktiviert werden kann, ohne Datenintegrität zu gefährden.

Multi-Umgebungen sind dabei kein Luxus. Entwicklung, Test, UAT, Sandbox und Produktion erfüllen unterschiedliche Zwecke. Eine Sandbox, die regelmäßig aus Produktion aktualisiert wird, zeigt Datenrealität, darf aber nicht zur ungeordneten Bastelumgebung werden. Lead-Entwickler achten darauf, dass Branching, Versionsnummern, App-Abhängigkeiten und Freigaberegeln zusammenpassen.

Performance, Telemetrie und Supportability

Performanceprobleme entstehen in Business Central oft durch unscheinbaren Code. Ein Record-Loop, der zu viele Felder lädt, ein fehlender Schlüssel, unnötige FlowField-Berechnungen oder synchrone Integrationsaufrufe in einem Buchungsprozess können eine eigentlich kleine Erweiterung teuer machen. Deshalb gehört Datenzugriffsoptimierung früh in den Lernpfad.

SetLoadFields reduziert die geladenen Felder, wenn nur ein Teil eines Records benötigt wird. SetCurrentKey unterstützt die passende Sortierung und Indexnutzung. Queries können für lesende, aggregierende Szenarien sinnvoller sein als verschachtelte Schleifen. Background Sessions eignen sich für entkoppelte Verarbeitung, müssen aber mit Fehlerbehandlung, Wiederholbarkeit und Monitoring kombiniert werden.

Example — Datenzugriff mit SetLoadFields und SetCurrentKey

procedure CountBlockedCustomers(): Integer
var
    Customer: Record Customer;
    BlockedCount: Integer;
begin
    Customer.SetLoadFields("No.", Blocked);
    Customer.SetCurrentKey(Blocked);
    Customer.SetRange(Blocked, Customer.Blocked::All);

    if Customer.FindSet() then
        repeat
            BlockedCount += 1;
        until Customer.Next() = 0;

    exit(BlockedCount);
end;

Das Beispiel zeigt zwei einfache Gewohnheiten, die in großen Mandanten einen Unterschied machen können: nur benötigte Felder laden und den Zugriff bewusst filtern. Danach sollte in realen Erweiterungen geprüft werden, ob eine Query, ein FlowField oder eine vorgelagerte Berechnung geeigneter ist.

Supportability entsteht zusätzlich durch Telemetrie. Application Insights, strukturierte Fehlercodes, aussagekräftige Logmeldungen und Feature-Toggles helfen, Probleme nach einem Release einzugrenzen. Gute Entwickler schreiben nicht nur Code, der funktioniert; sie bauen Lösungen, die im Betrieb erklärbar bleiben.

Integrationen sauber entwerfen

Business Central steht selten allein. Typische Integrationen verbinden ERP-Prozesse mit Webshops, CRM-Systemen, Versanddienstleistern, Finanzplattformen oder Data-Warehouse-Umgebungen. Technisch kommen API Pages, Standard-APIs, Webhooks, OData, OAuth2 über Microsoft Entra ID und externe Middleware zum Einsatz.

Der entscheidende Unterschied zwischen einer Demo-Integration und einer produktionsfähigen Integration liegt in Fehlerfällen. Externe Systeme drosseln Anfragen, liefern doppelte Nachrichten, ändern Antwortzeiten oder senden Ereignisse erneut. Deshalb brauchen Integrationen Retry-Strategien, Idempotenz, Korrelations-IDs, klare Statusfelder und eine Möglichkeit zur manuellen Nachbearbeitung.

API Pages sind ein gutes Mittel, um Business-Central-Daten gezielt und kontrolliert bereitzustellen. Sie sollten jedoch nicht als beliebige Datenbankfenster missverstanden werden. Ein gutes API-Design bildet fachliche Ressourcen ab, begrenzt Felder auf das Notwendige und berücksichtigt Berechtigungen, Versionierung und Erweiterbarkeit.

Example — Einfache API Page für Projektdaten

page 50120 "Project API"
{
    PageType = API;
    APIPublisher = 'contoso';
    APIGroup = 'projects';
    APIVersion = 'v1.0';
    EntityName = 'project';
    EntitySetName = 'projects';
    SourceTable = Job;
    DelayedInsert = true;

    layout
    {
        area(content)
        {
            repeater(Group)
            {
                field(number; Rec."No.") { }
                field(description; Rec.Description) { }
                field(status; Rec.Status) { }
            }
        }
    }
}

Dieses Muster veröffentlicht eine fachlich begrenzte Ressource statt einer breiten technischen Oberfläche. In produktiven Szenarien folgen Berechtigungsprüfung, Versionierungsstrategie, Validierung, Monitoring und dokumentierte Fehlerantworten.

Formale Zertifizierung richtig einordnen

Eine Zertifizierung ersetzt keine Projekterfahrung, kann aber einen Lernpfad strukturieren und nach außen sichtbar machen, dass zentrale Themen beherrscht werden. Für Business-Central-Entwickler ist MB-820 die naheliegende Microsoft-Prüfung, weil sie sich auf Entwicklung, Erweiterungen, Integration und technische Umsetzung in Dynamics 365 Business Central bezieht.

Wer sich gezielt vorbereiten möchte, sollte die Prüfung nicht als reines Auswendiglernen behandeln. Besser ist ein Arbeitsplan, der AL-Objekte, Event-Modell, Schnittstellen, Berechtigungen, Testing, Deployment und Fehleranalyse jeweils mit kleinen Implementierungen verbindet. Ein MB-820 Business Central Developer Kurs kann dabei helfen, die Prüfungsziele geordnet mit Praxisübungen zu verbinden; ergänzend lohnt der Blick auf Microsoft-Kurse, wenn angrenzende Themen wie Azure, Power Platform oder Security eine Rolle im Projektumfeld spielen.

Readynez bietet diese Einordnung als Teil eines strukturierten Microsoft-Lernpfads an, doch der wichtigste Maßstab bleibt die Anwendung im Projekt: Eine Zertifizierung gewinnt an Wert, wenn sie mit lesbarem Code, getesteten Extensions und sicherem Umgang mit Release-Prozessen zusammenkommt. Für kontinuierliches Upskilling über mehrere Microsoft-Themen hinweg kann auch Unlimited Microsoft Training relevant sein.

Wie der Aufstieg zur Lead-Rolle gelingt

Der Schritt zur Lead-Rolle ist weniger eine Frage des Titels als der Verantwortung. Ein Lead-Entwickler erkennt Risiken früh, setzt technische Leitplanken und hilft dem Team, wiederholbare Entscheidungen zu treffen. Dazu gehören Code-Reviews, Namenskonventionen, Testanforderungen, Release-Kriterien und ein bewusster Umgang mit Breaking Changes.

Besonders wichtig ist die Fähigkeit, fachliche Anforderungen zu hinterfragen. Muss eine Änderung wirklich als AL-Erweiterung umgesetzt werden, oder reicht Konfiguration? Ist eine synchrone Integration im Buchungsprozess vertretbar, oder sollte sie entkoppelt werden? Wird eine PTE gebaut, obwohl das Muster später als Produkt skaliert werden soll? Solche Fragen unterscheiden ausführende Entwicklung von technischer Führung.

Community-Arbeit unterstützt diesen Weg. GitHub-Repositories, Microsoft-Dokumentation, Dynamics-Communities und Beispiele aus AL-Go oder BcContainerHelper zeigen, wie andere Teams mit ähnlichen Problemen umgehen. Dabei sollte jedoch nicht jedes Snippet ungeprüft übernommen werden. Gute Entwickler verstehen, warum ein Muster passt, und dokumentieren, welche Annahmen dahinterstehen.

Ein belastbarer Lernpfad für Business-Central-Entwickler

Der sinnvollste nächste Schritt ist ein kleines, aber vollständiges Entwicklungsprojekt: eine Extension mit PageExtension, Event Subscriber, API Page, Permission Set, Test-Codeunit und automatisiertem Build. Dieses Projekt sollte zuerst lokal und in einer Sandbox laufen, danach über eine einfache Pipeline gebaut und versioniert werden. So entsteht ein Portfolio, das mehr zeigt als einzelne Syntaxkenntnisse.

Wer diesen Weg konsequent weitergeht, entwickelt sich vom AL-Einsteiger zum Entwickler, der Business-Central-Lösungen betreibbar und upgradefähig gestaltet. Bei Fragen zur MB-820-Vorbereitung oder zur passenden Microsoft-Lernstrategie kann Readynez über den Kontakt zum Beratungsteam weiterhelfen.

FAQ

Welche Fähigkeiten braucht ein guter Microsoft Business Central-Entwickler?

Wichtig sind AL, Visual Studio Code, das Extension-Modell, Events, Tabellen- und Seitenobjekte, Berechtigungen, API Pages, Test-Codeunits und Grundlagen von CI/CD. Hinzu kommen ERP-Verständnis und die Fähigkeit, fachliche Anforderungen in wartbare technische Lösungen zu übersetzen.

Ist MB-820 für Business-Central-Entwickler sinnvoll?

MB-820 ist sinnvoll, wenn ein Entwickler seine Kenntnisse strukturiert an den Microsoft-Prüfungszielen ausrichten möchte. Die Prüfung sollte jedoch mit praktischer Entwicklung kombiniert werden, etwa durch eigene Extensions, Tests, Integrationen und Deployment-Übungen.

Sollte eine Erweiterung als PTE oder AppSource-App gebaut werden?

Eine PTE passt zu kundenspezifischen Anforderungen in einem Mandanten. Eine AppSource-App eignet sich für eine Lösung, die an mehrere Kunden verteilt werden soll und deshalb strengere Anforderungen an Validierung, Versionierung, Dokumentation und Wartung erfüllen muss.

Wie wichtig sind automatisierte Tests in Business Central?

Automatisierte Tests sind besonders wichtig, wenn Erweiterungen Geschäftslogik, Buchungen, Integrationen oder Upgrade-Szenarien betreffen. Test-Codeunits und reproduzierbare Testläufe helfen, Regressionen früh zu erkennen und Releases sicherer zu machen.

Welche Fehler machen Einsteiger in AL häufig?

Häufige Fehler sind zu wenig Nutzung von Events, fehlende Tests, unklare app.json-Abhängigkeiten, keine Permission Sets, ineffizienter Datenzugriff und fehlende Versionierungsstrategie. Diese Punkte führen später oft zu Wartungsproblemen, selbst wenn die Erweiterung zunächst funktioniert.