Willkommen zu einer weiteren Episode der Microsoft Knowledge Nackt. Ich bin Ihr Gast, Gilbert Miro-Peter. Also hier ist das Szenario. Sie arbeiten in Business Central und benötigen eine kleine Änderung. Vielleicht ein zusätzliches Feld in einem Kundendatensatz, einen anderen Genehmigungsschritt oder eine Regel, die einen Auftrag prüft, bevor jemand ihn bucht. Dann erwähnt jemand AL Extensions, Tabellen, Pages und Codeunits und plötzlich klingt diese kleine Anfrage wie eine völlig neue Sprache. Es ist eine Sprache, sicher, aber sie muss nicht geheimnisvoll wirken. Stellen Sie sich Business Central wie ein Bürogebäude vor. AL gibt Entwicklern die Anweisungen, ein Raum, ein Formular oder eine neue Regel hinzuzufügen, ohne Löcher in das Gebäude selbst zu schlagen. Das ist das heutige Wissensnugget. Am Ende dieser Folge werden Sie wissen, was AL Entwicklung bedeutet, warum es Extensions gibt und wie individuelle Anpassungen in Business Central passen.

Warum Unternehmen Business Central anpassen? Business Central erledigt bereits viele tägliche Aufgaben, Finanzen, Kunden, Verkaufsaufträge, Lagerrechnungen, alles in einem vernetzten System statt in einem Haufen Tabellenkalkulationen und separater Tools. Für viele Unternehmen deckt dieser Standardaufbau den Großteil der Arbeit ab. Aber hier ist der Punkt. Keine zwei Unternehmen arbeiten auf die gleiche Weise. Nehmen Sie einen Lebensmittelhändler, der Chargendetails benötigt, die ein anderes Unternehmen niemals nutzt. Ein Dienstleistungsunternehmen, das einen speziellen Genehmigungsprozess vor der Rechnungsstellung erfordert. Einen Einzelhändler, der Prämienstufen für Rabatte wünscht. Und jemand anderes, der ein Formular mit eigenen Formulierungen, Feldern und internen Regeln benötigt. Das Unternehmen wird seine Arbeitsweise nicht wegen eines fehlenden Feldes ändern. Und Sie möchten auch nicht, dass jede kleine Anfrage zu einer riskanten Änderung am gesamten System wird.

Das war früher ein größeres Problem. In älteren Systemen öffneten Entwickler den ursprünglichen Code und bearbeiteten ihn direkt. Und das funktionierte, bis das nächste Update kam. Dann hatte das Unternehmen die neue Version von Microsoft auf der einen Seite und seine eigenen Änderungen auf der anderen. Und jemand musste alles abgleichen, bevor das Update fortgesetzt werden konnte. Stellen Sie sich ein Büro vor, in dem jeder Mieter ohne Plan neue Kabel durch die Wände verlegt. Es funktioniert eine Weile, aber wenn das Gebäude repariert werden muss, weiß niemand, welches Kabel zu wem gehört. Business Central schlägt einen anderen Weg. Anstatt die Standardanwendung umzuschreiben, erstellen Entwickler ein separates Add-on, das sich damit verbindet. Der Standardteil bleibt erhalten, während die unternehmenseigenen Änderungen daneben existieren und über unterstützte Schnittstellen im System arbeiten.

Diese Trennung ist wichtig, wenn Updates eintreffender Microsoft seinen Teil des Gebäudes aktualisiert, während die individuellen Anpassungen in ihrem eigenen Bereich bleiben. Es gibt immer noch Tests und Korrekturen. Es sind schließlich Softwareänderungen, aber vom Entwickler wird nicht erwartet, jede Änderung im ursprünglichen Code von Microsoft zu kopieren und zu überarbeiten. Was genau passt dein Unternehmen eigentlich an? Durch Anpassung werden Daten ergänzt. Das Standardsystem speichert keine Informationen wie Lieferanweisungen, interne Risikobewertungen, Mitgliedsstufen oder Links zu externen Systemen. Zudem werden Bildschirme hinzugefügt, die Mitarbeiter in der richtigen Reihenfolge durch ein Aufgaben. Sie setzen auch Regeln durch, wie etwa das Stoppen eines Auftrags, wenn ein erforderliches Dokument fehlt. Anpassungen helfen zudem, manuelle Arbeitsschritte zu vermeiden. Stellen Sie sich vor, Mitarbeiter kopieren jeden Freitag Kundendaten aus Business Central in ein anderes Tool, prüfen Bedingungen im All-O-L und senden dann einen Bericht an den Vorgesetzten.

Eine gut durchdachte Änderung behält diese Informationen im Business Central, wendet die Regel konsequent an, und bietet dem Personal eine Schaltfläche oder Seite, die zu ihrer täglichen Arbeit passt. Räumen wir mit einem Mittag auf. Sie möchten nicht alles anpassen. Das Standard Business Central enthält bereits viele integrierte Prozesse. Etwas nur deshalb zu ändern, weil es anders aussieht als in einem alten System, sorgt später für zusätzliche Arbeit. Gute Anpassungen beginnen also mit einem klaren und geschäftlichen Rund. Vor welchem Problem stehen die Leute? Was sollte stattdessen passieren? Und kann das Standardprodukt dies bereits leisten? Wenn das Standardprodukt diesen Bedarf nicht deckt, kommt AL ins Spiel. AL konzentriert sich auf Business Central selbst, liest, fügt Datensätze auf Datenbank-Ebene hinzu und ändert diese, während es steuert, was auf Seiten in Berichten und anderen Teilen der Anwendung geschieht.

Es berechnet Werte, verschiebt Daten und zeigt Meldungen an, wenn Regeln während der Prozesse verletzt werden. Das ist eine Menge Arbeit für eine Sprache, aber AL ist kein allgemeines Werkzeug für jede Art von Software und sie würden es nicht für eine öffentliche Shopping-Website, ein mobiles Spiel oder eine eigenständige Desktop-App wählen. AL existiert für eine gezielte Aufgabe, die Gestaltung der Daten und des Verhaltens innerhalb von Business Central, damit das System zur Arbeitsweise eines Unternehmens passt. Und genau das schauen wir uns als nächstes an. AL und Erweiterungen – das sichere Add-on-Modell. AL steht für Application Language. Es ist die Programmiersprache von Microsoft für Business Central und bietet Entwicklern eine strukturierte Möglichkeit, neue Geschäftsfunktionen zu erstellen oder das Verhalten bestehender Systemteile zu ändern. Aber das Wort Erweiterung ist genauso wichtig wie AL.

Eine Erweiterung ist eine separate App, die Business Central installieren kann. Sie enthält die individuellen Anpassungen des Unternehmens, während die Standard-Business Central-Anwendung unberührt bleibt. Denken Sie weniger an das Umschreiben eines Handbuchs, sondern eher daran, genehmigte Seiten hinzuzufügen. Seiten, die den ursprünglichen Regeln folgen, ohne sie zu löschen. Das mag wie ein technisches Detail klingen, verändert aber wie Anpassungen über die Zeit hinweg bestand. Stellen Sie sich vor, ein Unternehmen benötigt einen neuen Büroraum für ein spezielles Team. Der alte Ansatz bedeutete, eine Wand im Hauptgebäude einzureißen und die Struktur selbst zu verändern. Es mag den Bedarf von heute decken, doch zukünftige Reparaturen werden zum Albtraum, da das ursprüngliche Gebäude nicht mehr seinen Bauplänen entspricht. Eine Erweiterung funktioniert anders. Das Gebäude besitzt bereits Türen, Steckdosen und Regeln für die Erweiterung von Raum.

Sie bauen den neuen Raum über diese genehmigten Anschlüsse an. Der Raum gehört zum Unternehmen, doch das Hauptgebäude kann weiterhin gewartet werden, ohne jede individuelle Wand einreißen zu müssen. Genauso funktionieren Business Central-Erweiterungen. Die Basisanwendung enthält den Standard, den Microsoft bereitstellt. Eine Erweiterung kann eigene Felder, Masken, Schaltflächen, Regeln, Berichte und sogar Verknüpfungen zu anderen Systemen hinzufügen. Sie kann auf bestimmte Geschäftsereignisse reagieren. Dies geschieht jedoch über unterstützte Verbindungsmöglichkeiten zur Standardanwendung. Grenzen sind also fest und die Regeln. Das ist eine gute Sache. Ohne Grenzen kann eine kleine individuelle Anpassung tief in Bereiche eindringen, die sie nicht berühren sollte. Mit Erweiterungen arbeitet der Entwickler mit klaren Objekttypen und definierten Schnittstellen, was den Code verständlicher macht, wenn ihn später jemand anderes lesen muss.

Dieser Ansatz passt zudem perfekt zur Cloud-Version von Business Central. Microsoft aktualisiert den Dienst regelmäßig. Ein Unternehmen muss seine Erweiterung nach Änderungen dennoch testen, besonders wenn sie von Teilen des Produkts abhängig demodifiziert wurden. Software erfordert immer einen gewissen Pflegeaufwand. Doch die Trennung von individuellem Code verringert das Risiko, das jedes Update zu einer umfassenden Überarbeitung alter Modifikationen führt. Vielleicht hören Sie Leute von CILAL sprechen, wenn sie sich auf ältere Dynamic Sense-Systeme beziehen. CL stammt aus einem früheren Entwicklungsmodell, bei dem Entwickler oft die ursprünglichen Anwendungsobjekte direkt änderten. Viele Unternehmen betrieben jahrelang erfolgreiche Systeme auf diese Weise, aber es koppelte individuelle Anpassungen viel enger an den Standardcode und Updates erforderten viel Vergleichs- und Reparaturarbeit.

AL hat Business Central in Richtung App-basierte Entwicklung bewegt. Das bedeutet nicht, dass jede Erweiterung groß oder kompliziert ist. Eine Erweiterung fügt vielleicht nur ein Feld zu einem Kundendatensatz hinzu und zeigt es in einer vertrauten Maske an. Eine andere könnte eine vollständige Lösung für eine bestimmte Branche mit eigenen Datensätzen, Prozessen, Seiten und Berichten enthalten. Beide folgen demselben Grundgedanken. Die individuelle App existiert neben Business Central, anstatt eine neue Fassung davon zu verbergen. Sie können auch mehr als eine Erweiterung installieren. Ein Unternehmen könnte eine Erweiterung eines Softwarepartners für die Lohnabrechnung nutzen, eine weitere für den Versand und eine kleine interne Erweiterung für Regeln, die nur für dieses Unternehmen wichtig sind. Business Central führt sie im selben Arbeitssystem zusammen, solange sie den Regeln der Plattform folgen und nicht in Konflikt stehen.

AL ist also nicht nur eine Art, Code zu schreiben. Es ist die Sprache, die Entwickler verwenden, um diese Add-on-Apps zu erstellen. Und Erweiterungen sind der Container, der diese Änderungen in Business Central einbringt. Dieses Modell ermöglicht es einem Unternehmen, das System anzupassen und gleichzeitig das Standardprodukt überschaubar und wartungsfreundlich zu halten. Öffnen wir nun eine dieser Erweiterungen und betrachten wir die darin enthaltenen Bausteine. Die wichtigsten Eilbausteine innerhalb einer AL-Erweiterung? Entwickler arbeiten mit Objekten. Ein Objekt ist ein benannter Teil der Anwendung mit einer klaren Aufgabe, wie dem Speichern von Informationen, der Anzeige eines Bildschirms, der Ausführung einer Regel oder der Erstellung eines Dokuments. Sobald man diese Aufgaben getrennt betrachtet, wirkt AL viel weniger wie eine undurchdringliche Codewand. Beginnen wir mit dem Ort, an dem Geschäftsinformationen gespeichert werden.

Tabellen speichern Daten in Business Central. Dählen Sie sich eine Tabelle wie einen digitalen Aktenschrank für eine bestimmte Art von Datensatz. Ein Schrank könnte Kunden enthalten, ein anderer Artikel und ein weiterer Verkaufsaufträge. Jeder Datensatz ist eine Datei in diesem Schrank. Eine Kundentabelle enthält einen Datensatz für jeden Kunden. Eine Artikeltabelle enthält einen Datensatz für jedes Produkt. Wenn Ihr Unternehmen Informationen benötigt, die Business Central im Standard nicht speichert, kann eine Erweiterung eine eigene Tabelle erstellen, etwa für Belohnungsstufen, Geräteprüfungen oder Projektfreigaben. Felder sind die beschrifteten Bereiche innerhalb jedes Datensatz. Ein Kundendatensatz kann einen Namen, eine Adresse, eine Zahlungsbedingung und eine Telefonnummer enthalten, da die Kundentabelle Felder für diese Details aufweist. Felder können Text, Daten, Beträge, Ja oder Nein antworten oder eine Auswahl aus einer Festenliste enthalten.

Ein Feld kann auch auf einen anderen Datensatz verweisen. Zum Beispiel könnte ein Kunde ein Feld für eine Belohnungs-ID enthalten. Anstatt beliebigen Text einzugeben, wählen Mitarbeiter eine Belohnungsstufe aus einer separaten Belohnungstabelle aus. Diese Verknüpfung hält die Daten sauber, da jeder aus der gleichen bekannten Liste auswählt. Tabellen enthalten also die Fakten. Aber wie sehen die Leute diese Fakten und arbeiten mit ihnen? Seiten. Eine Seite ist der Bildschirm, den Sie in Business Central öffnen. Die Kundenkarte ist eine Seite. Eine Liste von Verkaufsaufträgen ist eine Seite. Eine Seite steuert, was Benutzer Anzeigen eingeben, suchen und bearbeiten können. Unterschiedliche Seiten eignen sich für unterschiedliche Augen. Eine Kartenseite konzentriert sich auf jeweils einen Datensatz wie einen Kunden oder einen Artikel. Eine Listenseite zeigt viele Datensätze in Zeilen an, was nützlich ist, wenn man etwas schnell scannen, filtern oder finden möchte.

Eine Arbeitsblattseite unterstützt Aufgaben, bei denen Benutzer mehrere Informationszeilen zusammen eingeben oder verarbeiten. Die Tabelle speichert die Informationen. Die Seite präsentiert sie dem Benutzer. Diese Trennung ist hilfreich, da Sie den Bildschirm ändern können, ohne den Speicherort der Daten zu beeinflussen oder dieselbe Tabelle auf mehreren Seiten wiederverwenden können, wenn verschiedene Teams unterschiedliche Ansichten derselben Datensätze benötigen. Was aber, wenn die Daten bereits zu einem Standarddatensatz in Business Central gehören? Normalerweise stellt man keine Ersatzkundentabelle, nur weil man ein zusätzliches Feld benötigt. Man verwendet eine Tabellenerweiterung. Eine Tabellenerweiterung fügt Ihr Feld zur bestehenden Kundentabelle hinzu. Der Standardkundendatensatz bleibt erhalten, während Ihre Erweiterung die spezifischen Firmendetails neben den Standardfeldern ergänzt.

So, das könnte eine Bonus-ID, ein Lieferschein, ein Kundenbetreuer oder ein Feld sein, das eine Verbindung zu einem anderen Unternehmensbereich herstellt. Doch das Hinzufügen des Feldes zur Tabelle bringt es nicht automatisch auf den Bildschirm. Dafür verwenden Sie eine Seitenerweiterung. Eine Seitenerweiterung fügt einer bestehenden Seite ein Feld, eine Gruppe oder eine Aktion. Wenn Mitarbeiter beim Anzeigen eines Kunden eine Bonusstufe wählen müssen, kann die Seitenerweiterung das Bonus-ID-Feld direkt auf der Debitorenkarte dort platzieren, wo die Mitarbeiter bereits arbeiten. Das sorgt für eine vertraute Arbeitsumgebung. Anstatt Ihr Benutzer für ein einfaches Detail auf eine separate benutzerdefinierte Seite zu schicken, fügt die Erweiterung das Detail der Seite hinzu, die Sie bereits kennen.

Beispiel könnte eine Debitorenkarte eine Bonusaktion enthalten, die die Bonusliste öffnet. Hinter der Oberfläche benötigen Sie einen Ort für die Geschäftsregel. Dieser Ort ist häufig eine Code-Unit. Eine Code-Unit enthält AL-Prozeduren. Das sind benannte Code-Abschnitte, die eine bestimmte Aufgabe ausführen. Stellen Sie es sich wie das Backoffice-Team vor, das eine Aufgabe erledigt, wenn eine Seite, ein Bericht oder ein anderer Prozess um Hilfe betetet. Angenommen, die Bonusstufe bestimmt, welcher Rabatt für einen Kunden gilt. Die Rabattberechnung gehört in eine Code-Unit, nicht auf die Debitorenkartenseite selbst. Dann können ein Verkaufsprozess ein Bericht oder eine zukünftige Seite dieselbe Regel nutzen, ohne sie an mehreren Stellen kopieren zu müssen. Eine Regel, eine Stelle zur Pflege. Business Central enthält auch andere Objekttypen für verschiedene Aufgaben. Berichte sammeln Daten und präsentieren sie in einem Dokument oder Layout wie bei einer Rechnung oder einem Verkaufsbericht.

Abfragen stellen gezielte Fragen an Daten. Welche Kunden einen bestimmten Artikel in einem Zeitraum bestellt haben. XML-Ports helfen beispielsweise dabei, Daten in einem strukturierten Format zu importieren oder zu exportieren, oft wenn ein anderes System Informationen mit Business Central austauschen muss. Wenn man diese Teile zusammenfügt, kann man sich eine kleine Kundenbonuserweiterung vorstellen. Eine Bonustabelle speichert jede Stufe und den dazugehörigen Rabattprozent. Bonusseiten ermöglichen es den Mitarbeitern, diese Stufen zu verwalten. Eine Tabellenerweiterung für Debitoren fügt jedem Kunden eine Bonus-ID hinzu, während eine Seitenerweiterung der Debitorenkarte diese anzeigt. Eine Seitenaktion öffnet die Prämienliste und die CodeUnit berechnet die Rabattregel. Jedes Objekt übernimmt einen Teil der Aufgabe. Das macht die Erweiterung leichter lesbar, testbar und änderbar, wenn sich die Geschäftsregel nach sechs Monaten ändert.

Doch eine Geschäftsregel muss oft genau im richtigen Moment ausgeführt werden, etwa wenn jemand einen Auftrag bucht. Wir kommen Trigger und Events ins Spiel. Events, Trigger und Geschäftsregel. Sie haben also ein Feld für Kundenprämien hinzugefügt. Hier ist die eigentliche Frage. Wann sollte Business Central dieses Feld tatsächlich nutzen? Stellen Sie sich vor, sich den kurz davor einen Verkaufsauftrag zu tun. Bevor das System die endgültigen Einträge erstellt, möchten Sie eine zusätzliche Prüfung. Vielleicht benötigt der Kunde eine genehmigte Prämienstufe, bevor ein Rabatt greift. Oder vielleicht muss ein erforderliches Lieferdokument

zum richtigen Zeitpunkt. Aber Sie wollen nicht den gesamten Buchungsprozess in Ihrer Erweiterung kopieren, nur um eine Regel hinzuzufügen. Dieser Prozess erledigt bereits viel im Hintergrund. Wenn Sie ihn kopieren, muss Ihre Erweiterung alle zukünftigen Änderungen pflegen. Nicht ideal. AL bietet Entwicklern da verschiedene Möglichkeiten, Code auszufügen. Welche Sie wählen, hängt davon ab, was passieren soll. Zuerst Trigger. Ein Trigger ist ein benannter Punkt in einem AL-Objekt, an dem Code ausgeführt werden kann. Wenn jemand einen Wert in einem Tabellenfeld ändert, löst der Trigger-Code aus. Wenn eine Seite geöffnet oder geschlossen wird, löst der Trigger-Code aus. Berichte, Abfragen, XML-Ports, Tabellen, Erweiterungen, sie alle, haben diese Stellen, an denen ein Entwickler Regeln hinzufügen kann. Nehmen wir das Feld für die Prämien-ID bei einem Kunden. Wenn ein Benutzer eine Prämienstufe auswählt, kann ein Validierungstrigger ausgeführt werden.

Der Code prüft, ist der Kunde gesperrt? Existiert die Prämienstufe? Muss ein anderes Feld aktualisiert werden? Die Prüfung erfolgt direkt bei der Wertänderung. Nicht erst später, wenn jemand einen Fehler entdeckt. Trigger funktionieren gut, wenn die Regel eng mit diesem Objekt verknüpft ist. Aber Business Central verwendet auch Events. Eine Wendebenachrichtigung, ein Teil der Anwendung, sendet sie, wenn etwas geschieht. Es könnte ankündigen, dass ein Datensatz eingefügt werden soll, ein Dokument gebucht wird oder ein Prozess abgeschlossen ist oder ein Prozess abgeschlossen ist. Ihre Erweiterung kann auf diese Benachrichtigung. Der Code, der zuhört, wird Event-Abonnent genannt, erwartet auf ein spezifisch benanntes Ereignis. Wenn Business Central dieses Ereignis auslöst, führt der Abonnent seine eigene Prozedur aus. Der Standardprozess behält dabei die Kontrolle. Wenn Business Central zum Beispiel beginnt, einen Verkaufsauftrag zu buchen, löst es ein Ereignis aus, bevor es fortfährt.

Ihre Prämienerweiterung empfängt diese Benachrichtigung. Sie prüft die Prämien-ID und die Rabattregel des Kunden. Anschließend lässt sie den Vorgang entweder fortfahren oder stoppt ihn mit einer klaren Meldung. Der Standardbuchungsprozess verbleibt bei Business Central. Ihre Erweiterung fügt an diesem Verbindungspunkt lediglich ihre firmenspezifische Regel hinzu. Sie werden oft Ereignisnamen wie On Before oder On After hören. On Before bedeutet, dass ihr Code ausgeführt wird, bevor eine Aktion abgeschlossen ist. Das ist ideal für eine Prüfung, die den nächsten Schritt verhindern kann. Zum Beispiel, um einen Verkaufsauftrag zu stoppen, wenn eine Bedingung nicht erfüllt ist. After bedeutet, dass die Aktion bereits stattgefunden hat. Können darauf reagieren. Erstellen sie einen zugehörigen Datensatz, aktualisieren sie eine Notiz oder starten sie eine weitere Aufgabe. Die Namen verraten ihnen den Zeitpunkt und das Timing ist entscheidend.

Eine Regel, die nach der Buchung ausgeführt wird, kann dies mehr fehlen. Eine Regel, die zu früh ausgeführt wird, verfügt möglicherweise nicht über die benötigten. Daher wählen Entwickler das Ereignis basierend darauf, was die Geschäftsregel tun muss. Code kann auch durch eine Aktion gestartet werden. Ein Benutzer klickt auf eine Schaltfläche wie Prämienstatus prüfen und diese Aktion ruft eine Prozedur auf. Code kann auch ausgeführt werden, wenn ein Objekt ein anderes über eine Variable aufruft. Das klingt technisch, ist aber einfach. Ein Teil der Erweiterung bittet einen anderen, eine Aufgabe auszuführen. Variablen helfen dabei. Eine Variable ist ein benannter Ort, der einen Wert speichert, während Code ausgeführt wird. Es kann eine Zahl, ein Text, ein Datum oder sogar ein Business Central Datensatz wie der aktuelle Kunde sein. In AL deklarieren Sie diese mit wahr. Beispielsweise könnte eine Prämienprozedur eine Variable namens Customer verwenden, um den aktuellen Kundendatensatz zu speichern.

Eine andere Variable namens Discount Percent speichert den Rabattsatz. Dies sind keine dauerhaften Datensätze. Es sind lediglich Arbeitswerte für diesen Codeabschnitt. Hier ist das Wichtigste zum Speicherort von Code. Wenn eine Regel von mehr als einem Ort aus verwendet werden könnte, legen Sie sie in eine Code. Auf diese Weise können die Debitorenkarte ein Verkaufsprozess und ein Bericht dieselbe Rabattprozedur aufrufen, anstatt jeweils

Bildschirm wendet 10% Rabatt an, ein anderer 5% und niemand weiß, welcher Regel man vertrauen kann. Das Speichern gemeinsamer Geschäftsregeln in der Codeunit bietet der Erweiterung eine zentrale Quelle für diese Entscheidung. Triggerhand haben also Regeln, die eng mit einem Objekt verknüpft sind. Ereignisse ermöglichen es einer Erweiterung auf die Prozesse von Business Central selbst zu regeln. Codeunits halten gemeinsame Logik zusammen. Sobald diese Teile verbunden sind, stellt sich die nächste Frage, wo schreiben, testen und prüfen Entwickler all diesen AL-Code? Die AL-Entwicklung findet normalerweise im Visual Studio Code statt, oft einfach VS Code genannt. Es ist der Arbeitsbereich zum Schreiben von AL-Data. Es hält ihre Erweiterung organisiert. Es hilft ihnen, Probleme zu finden und sendet die fertige App zum Testen an eine Business Central Umgebung. Aber VS Code allein ist nur ein allgemeiner Code-Editor.

Es benötigt die AL-Spracherweiterung von Microsoft. Diese Erweiterung bringt VS Code bei, wie Business Central funktioniert. Sie kann Objektnamen während der Eingabe vorschlagen. Sie weist da Fehler hin, bevor sie veröffentlichen. Sie hilft ihnen beim Durchsuchen von Feldern und Prozeduren. Und sie verbindet ihr Projekt mit einer Business Central Umgebung. Das spart viel Rätsel an. Wenn Sie ein neues AL-Projekt starten, können Sie den Befehl AL-Go in VS Code ausführen. Er stellt den grundlegenden Projektordner und die Einstellungsdateien für den Erweiterungsnamen, den Herausgeber, die Version und die zu verwendende Business Central Umgebung. Betrachten Sie diesen Projektordner als die Werkbank für Erweiterung. Jede alte Datei gehört dorthin. Eine Datei kann in Tabelle enthalten, eine andere eine Seitenerweiterung, eine Code-Unit kann ihre eigene Datei haben. So findet jemand, der das Projekt öffnet, den richtigen Teil, ohne durch ein riesiges Dokument scrollen zu müssen.

Wenn der Code zum Testen bereit ist, kompiliert VS Code ihn in ein App-Paket. Das ist die installierbare Version der Erweiterung. Business Central liest dieses Paket und fügt die Erweiterung der Umgebung hinzu. Wenn ein Feld fehlt, ein Rechtschreibfehler vorliegt oder ein anderes Problem wie ein App-Bild verhindert, teilt Ihnen VS Code dies mit, bevor das Paket Business Central überhaupt erreicht. Tests sollten zuerst in einer Sandbox durchgeführt werden. Eine Sandbox ist eine separate Business Central Umgebung, in der Sie Änderungen ausprobieren können, ohne das Live-Geschäft zu gefährden. Sie veröffentlichen die Erweiterung, öffnen die Seiten,

diese Trennung ist wichtig. Sie möchten nicht feststellen, dass eine neue Validierungsregel Verkaufsaufträge blockiert, während die Mitarbeiter ihre Arbeit erledigen. In einer Sandbox können Sie Fehler machen, Testdaten entfernen, Code ändern und erneut veröffentlichen, ohne Live-Datensätze zu beeinträchtigen. Manchmal läuft der Code, aber das Ergebnis sieht trotzdem falsch aus. Dann hilft das Debugging. Sie setzen einen Haltepunkt im Code, starten den Prozess und die Erweiterung hält während des Laufs an. An diesem Haltepunkt können Sie Werte untersuchen, wie den aktuellen Kunden die gewählte Prämienstufe oder den Rabattprozentsatz, den die Prozedur berechnet hat. Anstatt zu raten, worum ein Regel fehlgeschlagen ist, können Sie genau sehen, was der Code erhalten hat. Entwicklungsteams verwenden außerdem Git, um eine Historie ihrer Arbeit zu führen. Git zeichnet Änderungen an den Projektdateien im Laufe der Zeit auf.

Wenn jemand eine Regel ändert und ein Problem verursacht, kann das Team-Version vergleichen, sehen, was geändert wurde und bei Bedarf rückgängig machen. Es hilft auch, wenn mehr als ein Entwickler an derselben Erweiterung arbeitet. Für Anfänger ist es am besten, klein anzufangen. Machen Sie sich zuerst mit Business Central vertraut und erstellen Sie dann eine Tabelle und eine Seite. Erweitern Sie danach eine Standardseite, fügen Sie eine einfache Geschäftsregel hinzu und lernen Sie, wie Ereignisse und Installationsdaten in das Projekt passen. Als nächstes verknüpfen wir diese Teile durch ein kleines Add-on, das ein Unternehmen tatsächlich nutzen könnte.

Ein einfaches Beispiel, die Erstellung eines Kundenbonus-Add-ons. Wie sieht eine echte Eilerweiterung eigentlich aus? Tauchen wir in ein einfaches Beispiel ein. Denn Sie sich vor Ihr Unternehmen möchte Kundenbonusstufen, jede mit Ihrem eigenen Rabatt. Sie beginnen mit der Erstellung einer Bonustabelle. Betrachten Sie sie als einen digitalen Aktenschrank, in dem jede Akte einer ID, Schreibung und einen Rabattprozentsatz enthält. Gold erhält zum Beispiel 10% Rabatt. Ihre Mitarbeiter müssen diese Stufen verwalten, ohne technische Tools zu berühren. Also fügen Sie zwei Seiten hinzu. Eine Bonuslistenseite, um alle Stufen zu sehen und eine Bonuskartenseite, um eine zu bearbeiten oder zu erstellen. Sie können eine neue Stufe hinzufügen, einen Prozentsatz anpassen oder das vorhandene Überprüfen, ohne eine Entwicklungsumgebung zu öffnen. Als nächstes erweitern Sie die Kundentabelle um ein neues Feld namens Bonus-ID.

Dieses Feld verknüpft jeden Kunden mit einem Bonusdatensatz und Sie platzieren dieses Feld direkt auf der Kundenkartenseite, wo Mitarbeiter bereits Kundendetails verwalten. Dann fügen Sie eine Bonusaktion hinzu, damit Sie die Bonusliste direkt von der SEM-Karte aus öffnen können. Die Rabattregel selbst befindet sich innerhalb einer Code-Unit. Wenn ein anderer Prozess den Rabatt eines Kunden benötigt, ruft er diese Code-Unit auf, anstatt ihn immer wieder auf jeder Seite neu zu berechnen. Das ist effizient. Eine Installations-Code-Unit fügt beim ersten Installieren Ihrer Erweiterung Startbonusstufen hinzu. Und ein Ereignis-Abonnent prüft die gewählte Bonusstufe während eines Verkaufsprozesses und wendet Ihre Unternehmensregel genau zum richtigen Zeitpunkt an. Das ist eine kleine Erweiterung, aber beachten Sie, was sie enthält. Datentabellen, Benutzerbildschirme, Navigationsaktionen, Einrichtungslogik und Geschäftsregeln.

Alles arbeitet zusammen. Das ist die wahre Stärke von R. Fazit, Ihr Ausgangspunkt für die AL-Entwicklung. Hier ist also das Wichtigste zu mir. Die AL-Entwicklung ermöglicht es Ihnen, Business Central um spezifische Funktionen zu erweitern, die Ihr Unternehmen benötigt, ohne die Kernanwendung zu verändern. Und Sie müssen nicht alles auf einmal bauen. Beginnen Sie mit einem Feld, einer Seitenerweiterung und einer klaren Regel. Das ist Ihr erster Baustein. Wenn Du diesen Business Happen hilfreich fandest, abonniere uns auf Deiner bevorzugten Podcast-Plattform und teile ihn mit jemandem, der gerade erst mit der Business Central Entwicklung beginnt. Sei beim nächsten Mal wieder dabei, wenn wir ein weiteres Puzzleteil entzugen. Ich bin Merkur Peters und das war eine weitere Folge der Microsoft Business Happen auf M360 FM.