AL Programmieren in Visual Studio Code

"Wo ist meine tolle Entwicklungsoberfläche hin?" oder "Ich sag da nur: Back to the roots!" waren die ersten Reaktionen der Entwickler auf die neue Entwicklungssprache AL.

AL unterscheidet sich zu C/AL dahingehend, dass der NAV Developer Client für die Enwicklung entfällt, synaxtechnisch sind beide Sprachen jedoch kaum voneinander zu unterscheiden. Für die AL Entwicklung wird jetzt Visual Studio Code verwendet, welches das Erstellen von Extensions ermöglicht.

Ein weiterer Unterschied ist, dass mit AL das Programmieren in NAV Standardobjekten untersagt wird, alles muss unter einer Extension laufen.

Begriffserklärung "Extensions"

Eine Extension ist meist eine kleine Anwendung, welche die Hauptanwendung Microsoft Dynamics 365 Business Central um zusätzliche Funktionalitäten erweitert.

AL Language

Um in AL programmieren zu können, muss eine AL Language Extension für Visual Studio Code installiert werden. Diese findet man meistens unter dem Installationsverzeichnis von BC, oder im Falle von Docker und einem existierenden Container, kann man diese über eine WebSite runterladen:

http://CONTAINERNAME:8080/

Extension erstellen

Um eine neue Extension zu erstellen, muss folgender Befehl in Visual Studio Code ausgeführt werden (mit F1):

AL Go

Visual Studio Code fragt nach einem lokalen Repo Pfad, in welchem die Extension hinterlegt werden soll.

Bereits existierende Extension in DevOps

Um eine Extension aus DevOps zu holen, muss die gewünschte Repo geklont werden, siehe Hilfe zu DevOps.

AL Download Symbols

Damit in einer Extension programmiert werden kann, müssen zuerst die Symbole aus der Business Central runtergeladen werden.

Damit der Befehl...

AL Download Symbols

erfolgreich abläuft, muss gecheckt werden, ob die launch.json im .vscode Verzeichnis richtig eingerichtet ist.

Folgende Parameter müssen gepflegt sein:

"server": "http://Cronus/",
"serverInstance": "nav",
"authentication": "Windows",

Im Falle eines Containers kommt in der Parameter server der Containername rein, und die serverInstance ist meist "nav", falls dies abweicht, kann man den Namen ganz einfach abfragen, siehe Hilfe zu Docker Befehlen.

Damit muss der Befehl AL Download Symbols erfolgreich ablaufen, vorausgesetzt der Container läuft schon.

Neues AL Objekt anlegen

Bei der Bennenung von AL Dateien müssen die akuellsten Guidelines von Microsoft berücksichtigt werden. Microsoft Guidelines

Neue Tabelle anlegen

Um eine neue Tabelle anzulegen, muss zuerst eine .al Datei erstellt werden. Diese soll nach den Microsoft Guidelines benannt werden.

Da wir in AL keine einsteigerfreundliche Oberfläche wie in C/AL haben, startet man hier in einer leeren Datei. Damit diese Datei als Table deklariert werden kann, kann ein Snippet verwendet werden:

ttable

Es gibt allerhand Snippets, die dem Entwickler das Programmieren einfacher machen sollen. Vom erstellen von Tabellen, bis hin zu Funktions- und Feld-Snippets. Snippets können über IntelliSence aufgerufen, diese beginnen immer mit einem t. Weitere Beispiele für Snippets:

tfield
tpage
tpagefield
tprocedure

Wenn das Snippet ttable ausgewählt wurde, muss zu aller erst die Tabellen-ID eingefügt werden, wie auch den Tabellen Namen. Mit TAB springt man von Highlight zu Highlight und kann die Werte ersetzen.

Da wir hier keine Übersicht der Properties von Tabelle und Feld bekommen, kann man hier das IntelliSence für nutzen. Wenn man mit dem Cursor in einem Property-Bereich steht, kann man mit

Strg + Leertaste

IntelliSence aufrufen. Dieser schlägt dann alle verfügbaren Properties vor, die die Tabelle oder das Feld besitzen.

Tabellenstruktur

Nachdem die Tabelle und die Properties gepflegt wurden, folgt immer der Bereich der Felder. Dieser muss ajuch explizit gekennzeichet werden. Der Bereich wird mit

fields
{
    ...
}

definiert.

Nach den Feldern folgen die Keys. Diese werden folgendermaßen deklariert:

keys
{
    ...
}

Nach den Keys folgen die globalen Variablen, welche auf derselben Ebene folgend beginnen:

var
    MyVar: Integer;

Danach folgen die typischen Trigger für die Tabelle und die Felder, diese sehen wie folgt aus:

trigger MyTrigger()
begin
    ...
end;

Wenn man nun Funktionen hinzufügen will, muss das wie folgt aussehen:

local procedure MyProcedure(Parameter1, ...)
var
    myVar: Integer;
begin
    ...
end;

Bei einer globalen Funktion fällt das local weg:

procedure MyProcedure(Parameter1, ...)
var
    myInt: Integer;
begin
    ...
end;

Programmieren in einem Objekt.

Das Programmieren in einem Objekt ist identisch zu der Programmierung in C/AL. Es hat sich kaum was geändert, hauptsächlich fallen Variablentypen weg und es kommen neue hinzu, bspw. um bei Listen kein dotNet mehr verwenden zu müssen, wurde der Variablentyp List neu hinzugefügt. Außerdem versucht Microsoft, den Typ Option mit Enums auszutauschen.

Es folgen Beispiele für die Deklaration von Variablen:

myBool: Boolean;
myInt: Integer;
myRec: Record "Item";
myEnum: Enum "CB Colors";
myRecRef: RecordRef;

Weiterhin sollen Keywords, die für die AL Sprache reserviert wurden (bspw. begin end, if then, case, etc.) immer klein geschrieben werden, im gegensatz zu C/AL, wo diese immer groß geschrieben werden.

Es is noch zu beachten, dass Funktionen, welche aufgerufen werden, immer mit Klammern beendet werden müssen, auch wenn die Funktion keine Übergabeparameter besitzt.

if myBool then
    myProcedure();

Neue Page Extension

Extensions verhalten sich ähnlich wie normale Objekte, jedoch verweisen diese auf eine bereits vorhandene Page. Folgendes Snippet erstellt in einem neuen Objekt eine Page Extension:

tpageext

Neues Feld / Action einfügen

Um ein neues Feld/eine neue Action einzufügen, muss zuerst bestimmt werden, wo sich das neue Feld/die neue Action befinden soll. Dies tut man wie folgt:

addafter(AnyField)
{
    field(MyField; NewField)
    {
        ...
    }
}

Neuen Report anlegen

Um einen neuen Report anzulegen, gibt es folgenden Snippet:

treport

Damit ein Report ein RDL bekommt, muss folgende Property gepflegt werden:

RDLCLayout = `Extension\Report\TestReport.rdl`;

Beim AL Package erstellt VSCode dann automatisch eine RDL-Datei in dem angegebenen Pfad. Diesen kann man dann auch mit Visual Studio oder dem SQL Report Designer aufgerufen werden.

Reportstruktur

Nach den Report-Properties folgt das dataset. Das dataset sollte dann mit dataitems bestückt werden. In den dataitems werden zuerst die Properties beschrieben und danach folgen die columns.

Wichtig ist, dass die dataitem trigger erst nach den columns geschrieben werden. Bedeutet, dass die drei Trigger OnPreDataItem,OnAfterGetRecord,OnPostDataItem immer unter den columns des dataitems stehen müssen. Dies kann jedoch zu Problemen in der Übersichtlichkeit kommen, wenn der Report größer wird.

Nach dem dataset folgt die requestpage. Eine RequestPage verhält sich äquivalent zu einer Page.

Hier gibt es wieder Properties, das layout, ein area, eine group und darin dann spezifische Felder.

Globale Variablen folgen in einem Report immer zum Schluss.

Wenn Text Konstante in Reports genutzt werden sollen, sollte man dafür Labels nutzen. Denn Labels werden mit in die TranslationFile gepackt, in welchen man diese dann global übersetzen kann.

Zurück zur Startseite