Business Central 14: Was ich bei der Entwicklung in einer On-Premise-Umgebung gelernt habe

Business Central 14 ist eine Übergangsversion zwischen klassischer C/AL-Entwicklung und AL-Erweiterungen. Dieser Leitfaden zeigt, wie du eine bestehende On-Premises-Installation systematisch analysierst, Fehler eingrenzt und Änderungen sicher testest.

1. Die Architektur verstehen

Ein BC14-System besteht aus Datenbank, Business-Central-Serverinstanz, Webclient sowie Entwicklungswerkzeugen. Vor jeder Anpassung prüfst du Version, Buildstand, Mandantenkonfiguration und vorhandene Erweiterungen. Bei BC14 können kundenspezifische C/AL-Objekte und AL-Erweiterungen gleichzeitig existieren. Deshalb ist die Frage „Wo liegt die Logik?“ wichtiger als das bloße Auffinden eines Feldes.

2. C/AL und AL richtig einordnen

Traditionelle Anpassungen können in C/SIDE-Objekten hinterlegt sein; moderne AL-Extensions nutzen Event Subscriber und erweiterbare Objekte. Prüfe zunächst, welche Version des Standardobjekts eingesetzt wird, ob bereits Events existieren und welche Drittanbieter-Erweiterungen dieselben Abläufe verändern. Direkte Änderungen am Kern erschweren spätere Updates und sollten nicht vorschnell erfolgen.

3. Entwicklungsumgebung vorbereiten

1. Ermittle den Servernamen, die Instanz und den korrekten Entwicklungsendpunkt.
2. Überprüfe Berechtigungen des Entwicklerkontos und die erreichbaren Ports.
3. Konfiguriere launch.json passend zur Instanz und zum Authentifizierungsmodell.
4. Lade passende AL-Symbole herunter und kontrolliere die Referenzen.
5. Erstelle eine Testkopie der Datenbank, bevor du objekt- oder tabellenrelevante Änderungen vornimmst.

Eine illustrative launch.json für eine On-Premises-Entwicklungsinstanz könnte so aussehen. Server, Instanz, Ports und Authentifizierung hängen von der tatsächlichen Konfiguration ab:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "BC14 test environment",
      "type": "al",
      "request": "launch",
      "environmentType": "OnPrem",
      "server": "https://bc-test.example.com",
      "serverInstance": "BC140",
      "authentication": "Windows",
      "startupObjectType": "Page",
      "startupObjectId": 22
    }
  ]
}

4. Typische Ursachen für Symbolfehler

Wenn Symbole fehlen, liegt der Fehler nicht zwingend im AL-Code. Prüfe die Erreichbarkeit des Entwicklungsdiensts, gültige Berechtigungen, die passende Versionskombination sowie die Existenz der benötigten Apps. Bei einer aktualisierten Datenbank können alte Symbolpakete zu irreführenden Compilerfehlern führen. Dokumentiere Änderungen der Serverkonfiguration, statt bei jedem Fehler alle Einstellungen gleichzeitig zu verändern.

5. Einen eigenen Report schrittweise prüfen

Beginne mit dem Dataset: Welche Belegfelder liefert das System, welche zusätzlichen Felder müssen aus angrenzenden Tabellen geladen werden, und welche Filter gelten? Erst danach bearbeitest du RDLC oder Word. Bei einem Frachtbrief können beispielsweise Lieferadresse, Transportdienstleister, Sendungsnummer, Gewicht und Positionen nötig sein. Teste leere Werte, mehrere Zeilen und lange Adressen – nicht nur einen idealen Testbeleg.

6. Felder durch den Buchungsprozess verfolgen

Ein neues Feld auf einer Einkaufsbestellung ist noch keine vollständige Erweiterung. Bestimme, an welchen Stellen es beim Buchen weitergegeben werden soll, etwa in gebuchte Einkaufsrechnungen, Wareneingänge oder zugehörige Posten. Prüfe relevante Standardereignisse und fachliche Übernahmezeitpunkte. Bestehende Buchungsposten dürfen nicht ohne gezielte Migration verändert werden.

7. Vorgehen bei Fehlern in produktionsnahen Umgebungen

1. Fehler mit einem kleinen reproduzierbaren Testfall eingrenzen.
2. Betroffene Standard- und Erweiterungsobjekte identifizieren.
3. Logs und genaue Versionsstände sichern.
4. Änderung isoliert in einer Testumgebung durchführen.
5. Fachliche Regressionstests für Einkauf, Verkauf, Buchung und Reporting durchführen.
6. Deployment und möglichen Rollback dokumentieren.

8. Wann ist eine Modernisierung sinnvoll?

Bewerte nicht nur den technischen Aufwand einer C/AL-zu-AL-Umstellung, sondern auch Anpassungsmenge, Drittanbieter-Abhängigkeiten, Infrastruktur, Integrationen und den Supportlebenszyklus. Eine direkte Cloud-Migration ist nicht in jeder Umgebung ein Ein-Schritt-Projekt. Teile das Vorhaben in Bestandsaufnahme, Bereinigung, Erweiterungsmodernisierung, Testmigration und Produktivwechsel.

Fazit: BC14 bleibt beherrschbar, wenn Umgebung, Objektabhängigkeiten und fachliche Prozesse nachvollziehbar dokumentiert sind. Die wichtigste Gewohnheit ist, vor einer Codeänderung den vollständigen Ablauf zu verstehen.

Weiterführende Dokumentation

Microsoft: Business Central Development