close

Standort Krefeld

acadon AG
Königsberger Straße 115
47809 Krefeld

Tel.: +49 (0) 21 51 96 96-0
Fax.: +49 (0) 21 51 96 96-96
E-Mail: info@acadon.de

close

Support

Hotline _timber
Skype: +49 (0) 21 51 96 96-103
E-Mail: support@acadon.de

Hotline _packaging
Skype: +49 (0) 21 51 96 96-303
E-Mail: packaging@acadon.de

Hotline _venture
Skype: +49 (0) 21 51 96 96-803
E-Mail: venture@acadon.de

Extensions

Extension, die Zukunft unserer Softwareentwicklung, besonders in Bezug auf Dynamics NAV.  Das Unternehmen Microsoft hat sich dazu entschlossen in wenigen Jahren ­­­­die bisherige Entwicklung in Dynamics NAV von C/AL auf AL umzustellen. Dazu wird der Fokus auf die Cloud verlegt. Durch diese Änderung fällt die Entwicklung in C/AL und in der Entwicklungsumgebung C/SIDE weg und wird durch die neue Sprache AL sowie Visual Studio Code als Developer-Environment ersetzt.

Vorher wurden Anpassungen direkt an den Objekten (Tables, Pages, Codeunits, Reports) der Kunden vorgenommen.

Nun wird eine Extension, ein Zusatzfeature installiert. Diese Erweiterungen verändern den eigentlichen Quellcode sowie den Objektaufbau nicht und es wird sozusagen eine Maske über die vorhandenen Objekte gelegt. Diese Zusatzmodule werden auch Apps genannt. Jede Kundenlösung wird als eine App definiert und jede App basiert entweder auf der Standardlösung von Microsoft oder aber auf einer Branchenlösung, welche dann als Basis fungieren. Natürlich kann eine App auch auf einer anderen App basieren.

Grundsätzlich lässt sich fast jedes Objekt mit einer Extension erweitern oder neu aufbauen, darunter zählen Tables, Pages, Codeunits, Reports oder XML-Ports

 

Die Welt unserer Kunden

1 - Basisanwendung Microsoft + Branchenlösung

( 1 – Die Basis)

2 - Basisversion mit Erweiterungen (gelb)

(2 – Mit Extensions – in Gelb)

Für unsere Kunden ist nicht wichtig wie sich die Logik hinter der Oberfläche zusammensetzt (AL oder C/AL), es ist wichtig das es funktioniert und einfach und schnell zu bedienen ist.

So möchte zum Beispiel Herr Xylophon in seinen Datensätzen eine Aktion mit welcher er etwas löschen kann. Zusätzlich möchte er zwei neue Datensätze, welche ihm anzeigen wieviel er gelöscht hat und welcher der letzte Datensatz war.

In Bild 1 wird die Basis gezeigt, der Rohling welchen Herr Xylophon von uns bekommen hat, er stellt den Microsoft Standard zusammen mit unserer Holz Lösung dar.

Durch die Extension, in Bild 2 in gelb gezeigt, fügen wir unserem Kunden die Erweiterung ein die er gerne hätte. Dabei beeinflussen wir nicht die Basis Version und Herr Xylophon kann die App jederzeit wieder deinstallieren, wenn er auf eine neue Version updatet.

Durch eine Extension wird das vorhandene Objekt nicht überschrieben, sondern das Basisobjekt und das Erweiterungsobjekt existieren parallel. Diese werden in der Anwendung übereinandergelegt und somit wird die Basis erweitert.

 

Warum Extensions nutzten, die alte Entwicklungsart funktioniert doch auch.

Einer der größten Vorteile einer Extension, ist das einfache Updaten auf neue Versionen. Bisher mussten alle Anpassungen mit dem neuen Code verglichen werden und mögliche Konfliktsituationen behoben werden. Nach dem Update wurden die Anpassungen wieder eingefügt und auf ihre Funktionalität geprüft.

Dieser Prozess ist sehr zeitintensiv und mit viel Aufwand verbunden. Extensions werden vor einem Update deinstalliert und danach wieder installiert. Wenn Probleme auftreten lässt es sich einfacher nachverfolgen, welche App das Problem produziert. Damit kommen wir zum nächsten großen Punkt, die unkomplizierte Änderungsnachverfolgung und mit ihr auch das Zurücksetzten auf einen alten Entwicklungsstand.

Strukturierte Entwicklung mit Hilfe von Änderungsnachverfolgungsprogrammen

Zweige in der Entwicklung

Um die Entwicklung zu vereinfachen und eine parallele Entwicklung an unterschiedlichen Anforderungen zu erfüllen arbeiten wir mit dem Versionsverwaltungsprogramm GIT.

GIT ist ein Open Source Programm was es ermöglicht Projekte in jeder Größe mit Effizienz zu verwalten. Der Grundgedanke dahinter ist das Arbeiten mit Projekten als sogenannte Repositories (zentraler Speicherort für das Projekt) und in diesen mit Branches (Zweigen) zu arbeiten.

Wie bereits erwähnt basieren Extensions auf einer Basisversion, diese wird als Masterzweig betrachtet. Alle Anpassungen werden auf dem Developzweig durchgeführt und am Ende mit dem Master wieder zusammengeführt. Dadurch ergeben sich verschiedene Knotenpunkte, die jeweils eine Version darstellen. Es können beliebig viele Zweige erzeugt werden, die alle ihren eigenen Zweck haben z.B: Hotfix- oder Updatezweig.

Wenn eine Änderung veröffentlicht wird, wird diese committet, kommentiert, auf dem Server hochgeladen(gepusht), und schließlich veröffentlicht.

Durch diese Methodik der ersten drei Aktionen ist es möglich den Weg einer Anpassung nachzuverfolgen und wenn nötig zurück zu setzten.

Dieser Prozess vereinfacht die Entwicklung enorm und wir haben auch schon vor der Einführung mit AL mit diesem Prozess gearbeitet.

 

Empfehlung der Redaktion:

Es ist empfehlenswert neue Anpassungen soweit wie möglich als Extension zu programmiert, um den nahenden Umstieg zu vereinfachen.

Jeder Entwickler sollte sich mit dem Thema auseinander setzen, denn in naher Zukunft wird kein NAV Entwickler die Möglichkeit haben auf C/AL stehen zu bleiben und wird gezwungen seind das Neue zu lernen.

Microsoft gibt hierbei schon die Richtung stark voraus, denn mit der neusten Version von Business Central (neuere Version zu NAV, die auf Webclient-Only setzt) liefern diese den Standard nur noch in AL Dateien und es gibt keine Möglichkeit mehr in C/AL zu entwickeln.