Mit diesem Formular können Sie fehlende, unklare oder fehlerhafte Inhalte in der Dokumentation melden und Verbesserungsvorschläge machen. Ihr Feedback hilft uns, die Qualität und Vollständigkeit kontinuierlich zu verbessern.
Struktur einer Extension im Workspace
Im Folgenden wird die Struktur eines Ordners sowie ausgewählter darin enthaltener Dateien für die Entwicklung einer einzelnen Extension beschrieben. Sofern nicht ausdrücklich erlaubt ist diese Struktur in der Entwicklung einzuhalten.
Extensions werden in einem gemeinsamen Workspace entwickelt. Siehe dazu auch Visual Studio Code.
Ordnerstruktur
Jede Extension existiert als ein eigener Ordner im Repository unter
\extensions\
In diesem Ordner wird folgende Struktur verwendet:
.vscode\
(launch.json)
settings.json
src\
Unterordner\
Unterordner\
[..]
translations\
app.json
gob.json
Aller AL-Quellcode liegt innerhalb des Ordners src. Die Struktur im Ordner src wird von den Entwicklern entschieden. Dabei gilt als Leitgedanke die Ablage von Quellcode in logische/funktionelle Strukturen. Es soll anderen Entwicklern durch die Struktur das Verständnis und die Pflege erleichtert werden.
Beispiel: Eine Extension besteht aus mehreren Funktionen, jede dieser Funktionen liegt in einem Unterordner. Ich finde den Code zu einer Funktion in der Regel schon anhand der Ordnerstruktur.
launch.json - Verbindungsmanifest
launch.json
Diese Datei ist nur lokal relevant und optional. Im Entwicklungsprozess wird sie benötigt um Symbols laden zu können und die App selber in die Entwicklung zu laden und zu debuggen. Darüber hinaus wird eine solche Datei für Snapshot-Debuggen von Produktivsystemen benötigt.
app.json - Extension-Manifest
app.json
Diese Datei ist obligatorisch und enthält das Manifest der Extension. Die jeweils aktuelle Vorgabe kann aus der App .sample im Repository abgelesen werden. Qualitativ ist v. a. auf folgende Punkte zu achten:
- Alle AL Entwicklung - auch explizit bei on-premises Kunden - muss cloud-konform sein. Das bedeutet das
"target": "Cloud"gesetzt sein muss. Es ist nicht gestattet, das target umzustellen. Diese Regel kann nur in Abstimmung zwischen Projektleitung, Leitung Infrastruktur, Vertriebsleitung und v.a Kunde verändert werden. Der Grund sind empfindliche Lizenzgebühren für den Kunden ab 2023 für nicht cloud-konformen Code in Business Central Umgebungen. - Es werden Translation Files verwendet und implizites
with()ist zu unterbinden. Siehe"features" - Abhängigkeiten werden nicht durchgereicht, siehe
"propagateDependencies"
"propagateDependencies": false,
"features": [
"TranslationFile",
"NoImplicitWith"
],
"resourceExposurePolicy": {
"allowDebugging": true,
"includeSourceInSymbolFile": true,
"allowDownloadingSource": false
},
"target": "Cloud"
Wichtig
Mit der cloud-konformen Entwicklung geht der Verzicht auf .NET-Interop sowie der Verzicht auf programmatischen Zugriff auf interne Strukturen von BC und anderen Extensions einher. .NET-Interop kann in der Regel durch native AL Konstrukte, Azure Functions (oder Äquivalent) und JavaScript-Addins ersetzt werden. Zugriff auf interne Strukturen ist ohnehin schlechte Praxis und kann in der Regel durch andere programmatische Ansätze und bei Bedarf auch durch die Anforderung von Anpassungs-Einstiegspunkten bei dem jeweiligen Hersteller gelöst werden.
Logo der Extension
Jede Extension wird mit einem generischen Logo ausgestattet, damit unsere Anpassungen deutlich in der Kundeninstallation herausstechen.
Das Logo liegt zentral im Workspace und wird von dort referenziert. Zur Syntax kann in der app.json der .sample Extension ein Beispiel eingesehen werden.