Entwicklerjournal · Grundlagen und Praxis
Business Central in der Praxis: AL-Entwicklung, Prozesse und Migrationen
1. Warum Business Central mehr als Programmierung ist
Ein ERP-System verbindet Einkauf, Lager, Verkauf, Finanzbuchhaltung und häufig Fertigung. Eine Änderung an einer Seite wirkt möglicherweise beim Buchen, in Berichten oder in angeschlossenen Systemen weiter. Gute Business-Central-Entwicklung beginnt daher mit der fachlichen Frage: Welcher Prozess soll zuverlässiger oder einfacher werden?
2. Business-Central-Architektur verstehen
Die Standardanwendung liefert Tabellen, Pages, Codeunits und Reports. AL-Erweiterungen ergänzen vorhandene Objekte über TableExtensions, PageExtensions und Events. Im SaaS-Betrieb kommen Erweiterungsverwaltung, Mandantenkonfiguration und Telemetrie hinzu. Prüfe stets die Version und verfügbare Schnittstellen des Standards.
3. Vom Geschäftsprozess zur Anforderung
Beispiel: Eine Einkaufsbestellung soll einen zusätzlichen externen Referenzwert bekommen. Definiere zuerst, wer den Wert erfasst, wer ihn ändern darf und in welche gebuchten Belege er übernommen werden muss. Ein neues Eingabefeld allein ist noch keine vollständige Lösung.
4. Ein kleiner AL-Einstieg
Die folgende TableExtension ergänzt einen Demo-Referenzwert an der Verkaufszeile. Sie ist ein isoliertes Lernbeispiel und implementiert noch keine Übernahme in gebuchte Datensätze.
tableextension 50100 "Sales Line Demo" extends "Sales Line"
{
fields
{
field(50100; "External Reference Demo"; Code[50])
{
Caption = 'External Reference';
DataClassification = CustomerContent;
}
}
}
5. Ereignisse statt Kerncode verändern
Suche vor Eingriffen in den Standard nach vorhandenen Integration Events und Business Events. Event Subscriber können fachliche Logik entkoppeln. Prüfe die Signatur und den Zeitpunkt des jeweiligen Events in der konkreten BC-Version. Ein scheinbar passendes Event kann vor oder nach dem relevanten Buchungsschritt liegen.
6. Datenmigration planen
Eine Migration beginnt mit der Bestandsaufnahme: Debitoren, Kreditoren, Artikel, Dimensionen, offene Belege und Bestände. Definiere Feldmapping, Datenqualität, Reihenfolge, Testläufe, Delta-Übertragung und fachliche Abnahmekriterien. Vergleiche nach dem Import nicht nur Datensatzmengen, sondern auch Summen und referenzielle Zusammenhänge.
7. APIs und Azure integrieren
Standard-BC-APIs, individuelle API Pages und AL-HttpClient ermöglichen Datenflüsse. Azure Logic Apps eignen sich zur Orchestrierung, Azure Functions zur spezialisierten Verarbeitung und Queues zur Entkopplung. Entscheidend sind eindeutige Vorgangskennungen, Authentifizierung, begrenzte Retries und sichtbare Fehlermeldungen.
8. AL-Reports und Beleglayout
Ein Report besteht aus Dataset und Layout. Prüfe Filter, Summen und Seitenumbrüche mit realistischen Daten. Bei rechtsverbindlichen oder finanzrelevanten Berichten müssen die Inhalte fachlich gegengeprüft werden. Die Darstellung allein ist kein Nachweis korrekter Zahlen.
9. Qualität und Deployment
Lege Code in Versionsverwaltung ab, verwende nachvollziehbare Benennung und analysiere Compiler- sowie Analyzer-Warnungen. Veröffentliche zunächst in einer Sandbox und plane Freigaben, automatisierte Tests, Abhängigkeiten und Rückfallstrategie. Secrets gehören nicht in Quellcode oder Konfigurationsdateien im Repository.
10. Was ich aus Projekten mitnehme
Die wichtigsten Muster sind wiederkehrend: Standard vor Eigenentwicklung, verständliche Fachregeln, saubere Stammdaten, frühe Tests mit schwierigen Beispielen und transparentes Monitoring. Für Kundenprojekte sollten Details anonymisiert bleiben; ein öffentliches Tutorial benötigt keine produktiven Kundennummern oder vertraulichen Prozesse.
11. Lernpfad für den Einstieg
Starte mit Tabellen und Pages, lerne dann die Belegbuchung kennen und ergänze Events, Reports und API Pages. Erst danach würde ich komplexe asynchrone Integrationen und größere Migrationen als zusammenhängende Projekte angehen.
Kommentare (0)
Noch keine Kommentare. Schreibe den ersten Beitrag zur Diskussion.