Business Central-Entwicklung bedeutet heute, AL-Erweiterungen in Visual Studio Code so zu entwerfen, dass sie über einzelne Anpassungen hinaus wartbar bleiben und Updates, Mandantenunterschiede sowie Integrationen zuverlässig überstehen. Wer mit AL, Visual Studio Code und Business Central arbeitet, muss daher neben der Syntax auch verstehen, wie Erweiterungen im laufenden Betrieb gepflegt, getestet und ausgeliefert werden.
Business Central-Entwicklung beschreibt die Anpassung und Erweiterung von Microsoft Dynamics 365 Business Central mit AL, Extensions, APIs, Events, Tests und Integrationen in Dienste wie Power Automate, Power BI und Dataverse. Für Entwicklerinnen und Entwickler entsteht daraus eine Rolle zwischen ERP-Verständnis, sauberer Softwareentwicklung und betrieblicher Verantwortung: Code muss Geschäftsprozesse abbilden, ohne die Upgradefähigkeit der Lösung zu gefährden.
Warum Business Central-Entwicklung anders gelernt werden muss als klassische ERP-Anpassung
Business Central ist für viele Organisationen nicht mehr nur ein lokal betriebenes ERP-System, sondern häufig ein SaaS-Dienst mit regelmäßigen Updates und klaren Erweiterungsgrenzen. Das verändert die Entwicklungsarbeit erheblich. Direkte Eingriffe in Standardobjekte, harte Änderungen am Datenmodell oder manuelle Anpassungen außerhalb einer kontrollierten Extension-Strategie passen schlecht zu einem System, das kontinuierlich aktualisiert wird.
Der wichtigste Lernschritt besteht darin, Business Central als erweiterbare Plattform zu betrachten. AL-Code sollte möglichst über Events, Codeunits, Pages, Tables und Interfaces arbeiten, statt Standardverhalten direkt zu verändern. Diese Denkweise ist besonders für Umsteiger von C/AL wichtig, weil viele frühere Anpassungsmuster technisch oder betrieblich nicht mehr sinnvoll sind.
Auch die Wahl des Erweiterungstyps ist keine reine technische Detailfrage. Eine AppSource-App eignet sich eher, wenn Funktionalität mehrfach verteilt, versioniert und nach klaren ISV-Governance-Regeln bereitgestellt werden soll. Eine per-tenant Extension ist dagegen oft sinnvoll, wenn die Anpassung spezifisch für einen Kunden oder Mandanten ist. Bei Integrationen entscheidet nicht allein, ob Power Automate bequem ist; bei hoher Transaktionslast, strengen Fehlerbehandlungsanforderungen oder entkoppelten Prozessen können REST-APIs, Webhooks oder queue-basierte Muster robuster sein.
Die Entwicklungsumgebung: AL, Visual Studio Code und Sandbox
Die moderne Business Central-Entwicklung findet in Visual Studio Code mit der AL Language Extension statt. Entwickelt wird typischerweise gegen eine Sandbox-Umgebung oder einen lokalen Container, je nach Teamstandard und Projektanforderung. Für konkrete Systemanforderungen sollte die jeweils aktuelle Microsoft-Dokumentation herangezogen werden, weil sich unterstützte Versionen, Browser und Entwicklungswerkzeuge ändern können.
Eine produktive Umgebung besteht nicht nur aus dem Editor. Git sollte von Beginn an gesetzt sein, weil Business Central-Projekte schnell mehrere Extensions, Länderpakete, Mandantenvarianten und Abhängigkeiten enthalten. Die Datei app.json wird dabei zu einem zentralen Steuerpunkt: Publisher, Name, Version, Application-Version, Platform-Version und Dependencies entscheiden darüber, ob eine Extension sauber gebaut, aktualisiert und gemeinsam mit anderen Apps betrieben werden kann.
In Teams lohnt sich eine einfache, aber konsequente Branch-Strategie. Feature-Branches helfen bei isolierten Änderungen, Release-Branches stabilisieren Auslieferungen für bestimmte Mandanten oder Länderpakete, und Pull Requests machen Code-Reviews nachvollziehbar. Besonders wichtig ist Dependency-Management über publisher, name und version, weil unklare Abhängigkeiten später zu schwer erklärbaren Build- oder Upgradeproblemen führen.
Ein erstes Mini-Projekt: eine kleine AL-Erweiterung bauen
Ein sinnvoller Einstieg ist eine kleine Extension, die ein bestehendes Business-Central-Objekt erweitert, ohne Standardcode zu verändern. Das folgende Beispiel ergänzt die Customer Card um ein eigenes Feld. Es ist bewusst klein gehalten, zeigt aber drei Kernideen: ein Tabellenfeld hinzufügen, eine Page erweitern und die Änderung als Extension kapseln.
- Legen Sie in Visual Studio Code ein neues AL-Projekt an und verbinden Sie es mit einer Sandbox.
- Prüfen Sie die Werte in
app.json, insbesondere Name, Publisher, Version und unterstützte Plattform.
- Erstellen Sie eine Datei für die Tabellen-Erweiterung und eine Datei für die Page-Erweiterung.
- Bauen Sie das Projekt und veröffentlichen Sie es in der Sandbox.
- Öffnen Sie die Customer Card und prüfen Sie, ob das neue Feld sichtbar ist.
Das Beispiel kann mit einem Screenshot dokumentiert werden, etwa mit dem Alt-Text „Customer Card in Business Central mit zusätzlichem Feld für Kundenpriorität“. Solche Screenshots helfen bei internen Lernunterlagen, sollten aber immer den Zustand der verwendeten Sandbox zeigen und keine produktiven Kundendaten enthalten.
Example — Customer Card mit eigenem Prioritätsfeld erweitern
tableextension 50100 CustomerPriorityExt extends Customer
{
fields
{
field(50100; "Customer Priority"; Option)
{
Caption = 'Customer Priority';
OptionMembers = Standard,Important,Critical;
DataClassification = CustomerContent;
}
}
}
pageextension 50101 CustomerCardPriorityExt extends "Customer Card"
{
layout
{
addlast(General)
{
field("Customer Priority"; Rec."Customer Priority")
{
ApplicationArea = All;
ToolTip = 'Specifies the priority assigned to this customer.';
}
}
}
}
Nach dem Veröffentlichen sollte die Extension in der Sandbox installiert sein und das Feld auf der Customer Card erscheinen. Der Lerneffekt liegt weniger im Feld selbst als im Muster: Standardobjekte werden erweitert, nicht überschrieben. Wer die Grundlagen zu AL, VS Code und Projektstruktur vertiefen möchte, sollte mit der Microsoft-Dokumentation zu AL und den Beispielen auf GitHub weiterarbeiten.
Von der ersten Extension zu produktionsreifer Qualität
Viele frühe Business-Central-Projekte funktionieren in der Sandbox, scheitern aber später an Upgradefähigkeit, fehlender Fehlerdiagnose oder ungeprüften Annahmen. Produktionsreife entsteht deshalb nicht am Ende eines Projekts, sondern durch Entwicklungsgewohnheiten. Dazu gehören automatisierte Tests, klar versionierte Artefakte, Review-Prozesse und eine technische Strategie für Änderungen an Geschäftslogik.
Das Test Toolkit von Business Central hilft, fachliche Logik nachvollziehbar zu prüfen. Ein Test sollte nicht nur bestätigen, dass Code kompiliert, sondern dass ein erwarteter Geschäftsfall korrekt verarbeitet wird. Wenn eine Extension beispielsweise Rabattlogik, Buchungsregeln oder Freigabeprozesse verändert, sind Tests besonders wertvoll, weil sie beim nächsten Plattform-Update früh anzeigen, ob sich Verhalten geändert hat.
Debugging und Telemetrie sind ebenso wichtig. Der AL-Debugger hilft beim Verstehen einzelner Abläufe, während Telemetriedaten Hinweise auf Performance, Fehlerhäufigkeit und ungewöhnliche Nutzungsmuster geben können. In der Praxis wird dadurch sichtbar, ob eine Extension nur in Einzelfällen langsam ist oder strukturell zu viele Daten liest, zu viele Events auslöst oder Integrationsaufrufe ungünstig bündelt.
Eine pragmatische DevOps-Pipeline für AL muss nicht kompliziert sein. Häufig reicht ein klarer Ablauf: Container oder Sandbox bereitstellen, App kompilieren, Tests ausführen, Artefakt mit SemVer aus app.json versionieren und ein Release-Paket ablegen. Teams, die mit Docker arbeiten, nutzen dafür häufig BcContainerHelper; in Azure DevOps oder vergleichbaren CI/CD-Systemen kann dieser Ablauf reproduzierbar gemacht werden. Entscheidend ist, dass Releases nicht nur aus lokal gebauten Dateien bestehen, sondern nachvollziehbar aus dem Repository erzeugt werden.
SaaS, On-Premises und Upgradefähigkeit
Die Unterscheidung zwischen Business Central Online und On-Premises prägt Architekturentscheidungen. In SaaS-Umgebungen sind Upgradefenster, AppSource-Regeln, Berechtigungen und Erweiterungsgrenzen besonders relevant. On-Premises kann mehr technische Freiheit bieten, aber diese Freiheit ist kein Freibrief für schwer wartbare Anpassungen, weil auch dort spätere Upgrades, Datenmigrationen und Supportfähigkeit zählen.
Eine saubere Breaking-Change-Strategie gehört daher früh in den Lernplan. Tabellenfelder, öffentliche Prozeduren, Events und API-Objekte sollten nicht leichtfertig entfernt oder umbenannt werden, sobald andere Extensions oder Integrationen davon abhängen. Stattdessen werden Änderungen versioniert, veraltet markiert und in planbaren Schritten ersetzt. Das schützt Mandanten vor überraschenden Fehlern und erleichtert Partnern oder internen Teams die Releaseplanung.
Signierung, App-Paketierung und Governance unterscheiden sich je nach Bereitstellungsmodell. AppSource-Apps unterliegen anderen Erwartungen als kundenspezifische per-tenant Extensions. Wer Business Central-Entwicklung professionell betreibt, lernt deshalb nicht nur AL, sondern auch die Regeln, nach denen Erweiterungen verteilt, aktualisiert und freigegeben werden.
Integrationen: Power Platform, APIs und robuste Prozesskopplung
Business Central ist selten ein isoliertes System. Vertriebsdaten fließen in Power BI, Genehmigungen können über Power Automate laufen, Stammdaten landen in Dataverse, und externe Systeme greifen über APIs auf ERP-Daten zu. Die Kunst liegt darin, das richtige Integrationsmuster für den jeweiligen Prozess zu wählen.
Power Automate eignet sich gut für überschaubare Workflow-Automatisierung, Benachrichtigungen und Genehmigungsprozesse, bei denen Transparenz und schnelle Anpassbarkeit wichtig sind. Power BI ist stark, wenn Berichte, Kennzahlen und Visualisierungen im Vordergrund stehen. Dataverse kann sinnvoll sein, wenn Business Central mit Dynamics-365-Apps oder Power-Platform-Lösungen enger zusammenarbeiten soll.
Für transaktionskritische oder hochvolumige Integrationen reicht ein Flow-Ansatz jedoch nicht immer aus. REST-APIs, Events, Webhooks und queue-basierte Architekturen bieten oft bessere Kontrolle über Wiederholungen, Fehlerbehandlung, Entkopplung und Lastverteilung. Entwickler sollten deshalb nicht nur lernen, wie eine Verbindung technisch hergestellt wird, sondern auch, wie Latenz, Datenkonsistenz und Betriebssicherheit im Fehlerfall aussehen.
Wie die Praxis mit MB-820 zusammenhängt
Die Prüfung MB-820 Microsoft Dynamics 365 Business Central Developer richtet sich an Personen, die Business Central-Lösungen entwickeln, erweitern, testen und integrieren. Die praktische Arbeit mit AL-Projekten, Extensions, Events, APIs, Tests und Bereitstellung ist deshalb ein sinnvoller Ausgangspunkt für die Prüfungsvorbereitung. Wer nur Prüfungsfragen auswendig lernt, übersieht leicht die Zusammenhänge zwischen Objektmodell, Geschäftsprozess und Betrieb.
Ein guter Lernpfad verbindet kleine Entwicklungsaufgaben mit prüfungsnahen Themen. Eine Page-Erweiterung erklärt UI-Anpassungen, eine Tabellen-Erweiterung zeigt Datenmodellierung, eine Codeunit mit Event Subscriber führt in Geschäftslogik ein, und ein Testfall macht Qualitätssicherung greifbar. Danach werden Integration, Berechtigungen, Fehlerdiagnose und Deployment nicht als isolierte Kapitel gelernt, sondern als Teil derselben Lösung.
Wer eine strukturierte Vorbereitung sucht, kann den MB-820 Microsoft Dynamics 365 Business Central Developer Kurs als Rahmen nutzen. Ergänzend lohnt sich ein Blick auf weitere Microsoft-Kurse, wenn angrenzende Themen wie Azure, Power Platform oder Microsoft 365 für die eigene Rolle relevant werden.
Typische Fehler beim Lernen und Entwickeln
Ein häufiger Fehler ist der Versuch, frühere Anpassungsgewohnheiten unverändert in AL-Extensions zu übertragen. Direkte Datenbankzugriffe, enge Kopplung an konkrete Objektversionen, fehlende Events und unklare Dependencies führen oft erst spät zu Problemen. Besser ist ein Ansatz, der Erweiterbarkeit, Testbarkeit und Upgradefähigkeit von Beginn an als Qualitätsmerkmale behandelt.
Auch fehlende Tests werden anfangs oft unterschätzt. In Business Central hängt scheinbar kleiner Code häufig an Buchungslogik, Berechtigungen, Stammdatenqualität oder Länderfunktionalität. Ohne Tests und Telemetrie bleibt unklar, ob eine Änderung nur in der Demo funktioniert oder auch unter realistischen Datenmengen und Prozessvarianten stabil bleibt.
Ein weiterer Lernfehler ist zu frühe Spezialisierung auf einzelne Werkzeuge. Visual Studio Code, AL und Git sind Grundlagen, aber die Entwicklerrolle verlangt zusätzlich Verständnis für ERP-Prozesse, Releasezyklen, Integration, Support und Dokumentation. Wer diese Bereiche verbindet, wird in Projekten schneller produktiv als jemand, der nur Objektdefinitionen schreiben kann.
FAQ
Was sollte man vor dem Einstieg in Business Central-Entwicklung können?
Hilfreich sind Grundkenntnisse in Business Central, Datenmodellierung, Git und objektorientierten beziehungsweise ereignisorientierten Programmierkonzepten. Erfahrung mit C/AL kann nützlich sein, sollte aber bewusst auf moderne AL- und Extension-Muster übertragen werden.
Ist AL schwer zu lernen?
AL ist für viele Entwickler gut zugänglich, weil die Sprache klar auf Business-Central-Objekte und Geschäftslogik ausgerichtet ist. Die größere Herausforderung liegt häufig nicht in der Syntax, sondern im Verständnis von ERP-Prozessen, Events, Berechtigungen, Tests und Upgradefähigkeit.
Wann ist eine per-tenant Extension sinnvoll?
Eine per-tenant Extension passt oft zu kundenspezifischen Anforderungen, die nicht als wiederverwendbare App verteilt werden sollen. Wenn Funktionalität für viele Kunden gedacht ist, klare Produkt-Governance braucht oder über AppSource bereitgestellt werden soll, ist eine andere Strategie sinnvoller.
Welche Rolle spielen Power Automate und Power BI?
Power Automate eignet sich für Workflows, Benachrichtigungen und Genehmigungen, während Power BI für Analyse und Reporting genutzt wird. Bei transaktionskritischen Integrationen sollten Entwickler zusätzlich APIs, Events und robuste Fehlerbehandlung betrachten.
Bereitet praktische AL-Entwicklung auf MB-820 vor?
Ja, praktische Entwicklung ist eine wichtige Grundlage, weil MB-820 auf reale Entwickleraufgaben rund um Business Central ausgerichtet ist. Sinnvoll ist eine Kombination aus Projekten, Microsoft-Lernmaterialien, Dokumentation, Testszenarien und gezielter Prüfungsvorbereitung.
Den nächsten Lernschritt sinnvoll planen
Business Central-Entwicklung wird belastbar, wenn Lernen und Projektpraxis zusammenlaufen. Ein kleiner Einstieg über Page- und Table-Extensions ist sinnvoll, aber der nächste Schritt sollte Qualität, Integration und Deployment einbeziehen. Dadurch entsteht ein Lernpfad, der nicht bei „Hello World“ endet, sondern auf die Arbeit in Kunden-, Partner- oder internen ERP-Teams vorbereitet.
Die wirksamste Weiterentwicklung besteht darin, ein eigenes kleines Szenario vollständig umzusetzen: Anforderung formulieren, Extension bauen, Test schreiben, Release versionieren, Integration prüfen und das Verhalten in der Sandbox dokumentieren. Für kontinuierliches Microsoft-Training kann Unlimited Microsoft Training eine passende Option sein. Wenn Sie Fragen zur MB-820-Vorbereitung oder zur passenden Lernroute haben, können Sie Kontakt aufnehmen.
Quellen und weiterführende Orientierung
Für technische Details sollten Lernende die aktuelle Microsoft-Dokumentation zu Business Central, AL, AppSource-Validierung, Test Toolkit, Telemetrie und Administration heranziehen. Für lokale Entwicklungs- und CI-Szenarien ist außerdem das GitHub-Projekt BcContainerHelper eine wichtige Orientierung. Prüfungsbezogene Informationen sollten anhand der jeweils aktuellen Microsoft-Learn-Seite zu MB-820 geprüft werden, da sich Prüfungsinhalte und Gewichtungen ändern können.
