In den letzten Monaten habe ich viele Schulungen und Workshops zum Thema „Erstellung von Extensions v2 für Dynamics NAV und Business Central“ gehalten. Die Fragen der Kunden und Kursteilnehmer sind zunächst meist rein technischer Natur. Sie handeln von Themen wie Docker, Visual Studio Code, Snippets oder Unterschieden zwischen den Welten Cloud und „on premise“. Erst später, wenn sich die anfängliche Euphorie über die neue Umgebung und die damit verbundenen Möglichkeiten etwas gelegt hat, beginnen die Teilnehmer sich mit praktischen Anwendungsfällen und Integrationsszenarien der eigenen Produkte zu beschäftigen.
An dieser Stelle wird es erst richtig interessant, denn schnell kristallisiert sich heraus, dass die eigentliche Schwierigkeit gar nicht die Portierung des Programmcodes in die neue Programmiersprache AL oder die neue Entwicklungsumgebung Visual Studio Code selbst darstellt, sondern vielmehr die konzeptionelle Arbeit und die Neustrukturierung der Projekte, die das Thema App-Development mit sich bringt.
Ich habe mir die Zeit genommen und im Internet zu dieser Problemstellung recherchiert. Es gibt sehr viele Blogs, Forenbeiträge und Seiten, die sich sehr technisch mit diesem Part beschäftigen oder eine Menge an Marketing-Bla-Bla enthalten. Zum Aufbau und der Konzeptionsweise der Apps findet sich jedoch kaum etwas – sinnvolles.
Um Entwicklern, Projektleitern und Produktverantwortlichen den Einstieg in die Materie zu erleichtern, habe ich mich entschlossen ein paar praxisorientierte Ansätze aufzuzeigen und meine Erfahrungen der Extension V2-Entwicklung zu teilen.
Zunächst jedoch noch ein kurzer Hinweis: Es gibt keine ultimative Lösung, die in allen Praxisfällen das beste Ergebnis erzielt. Die Anforderungen unterschieden sich je nach Problemstellung immens. Während die eine Lösung für eine Portierung einer Branchenlösung ideal funktioniert, kann es in einem individuellen Kundenprojekt kläglich scheitern. Ich werde im Folgenden auf das Für und Wider eingehen und meine persönliche Präferenz erläutern.
Wenn es um die Struktur einer App geht, gibt es grundsätzlich mehrere Herangehensweisen. Folgende Architekturen haben sich in der Praxis bereits als erfolgreich erwiesen.
(1) Wir nutzen für jeden Software Change eine eigene App!
(2) Wir erstellen alles in einer App!
(3) Wir strukturieren die Anforderungen nach funktionalen Bereichen und verwenden mehrere Apps!
Methode 1 – das tausend Apps Prinzip
Jeder Anpassungswunsch an der Applikation wird in einem eigenen Software Change abgebildet. Die Auslieferung erfolgt direkt nach dem Test. Sollte eine App fertiggestellt werden, kann sie zwar erweitert werden, für ein Höchstmaß an Modularität wird der Komplexitätsgrad jedoch so gering wie möglich gehalten.
Charakterisierend für diesen Ansatz ist die direkte Verbindung der Apps mit der NAV-Basis. Eine Interaktion zwischen Apps, um z.B. Funktionen oder Daten auszutauschen, ist grundsätzlich nicht angedacht. Insofern dies im weiteren Projektverlauf notwendig werden sollte, müsste es mitunter umständlich implementiert werden.
Man verwendet diesen Ansatz häufig im Individualkundenbereich und hat dadurch die Möglichkeit Addons aus Projekt A direkt bei einem anderen Kunden in Projekt B nutzen zu können. Gerade durch die Entkopplung der NAV-Logik und der Nutzung von separaten Übersetzungen ist das Konzept durchaus verlockend. Auf Grund des Fokus auf die Individualität findet diese Art der Entwicklung meist in NAV2018 Anklang.
Fazit
Insofern es sich wirklich um einzelne isolierte Anpassungen handelt, ist dies eine sehr gute Art seine Entwicklungen in ein Projekt zu implementieren oder zumindest lokal für sich vorzuhalten. Sollte es notwendig sein doch einmal Elemente untereinander austauschen zu müssen, tritt schnell das böse Wort „Abhängigkeiten“ in den Fokus, welches einem das Leben schwer machen kann.
Modularität
Flexibilität
Schnelle Entwicklung
Isolation der Anpassungen
Methode 2 – einer für alle – alles in eine
Hier wird das Entwicklungsparadigma der klassischen NAV-Entwicklung in Appform weitergedacht. Es werden sämtliche Anpassungen in einer App zusammengefasst, was Abhängigkeiten gänzlich überflüssig macht. Entwickler aus der alten Welt kommen mit dieser Herangehensweise sehr gut zurecht, was sicherlich auch einer der Gründe ist, warum man diese sehr häufig antrifft.
Sämtliche Funktionalität und alle in den Tabellen vorgehaltenen Daten werden innerhalb einer einzigen App gespeichert. Diese Architektur wird sowohl in der Dynamics NAV Welt, als auch in Apps für Business Central gerne verwendet. Diese Methode ist gut für Individual- und Produktapps geeignet.
Alle Daten und Funktionen stehen überall zur Verfügung. Somit müssen keine Abhängigkeiten berücksichtigt werden. Upgrades in eine neue Version können ohne Probleme durchgeführt werden.
Beachtet werden sollte jedoch der längerer Release-Zyklus. Es muss vollständig getestet und erweitert werden. Auch kann auf diese Art und Weise ein „Single Point of Failure“ entstehen, welcher auch bei kleineren Problemen in unkritischen Teilen die gesamte App lahmlegt.
Fazit
Es wird hierbei komplett konträr zur bereits vorgestellten Variante vorgegangen. Entsprechend stark sind daher die Ausprägungen ins Positive wie ins Negative zu erklären. Für Produktapps – ehemals Branchenlösungen – ist dies meist die beste Wahl. Bei individuellen Anpassungen wiegen die Nachteile teilweise doch recht schwer.
Die schiere Anzahl der aufgeführten Punkte im folgenden Fazit soll an dieser Stelle kein eindeutiger Indikator für die Bewertung der Vorgehensweise sein. Gerade der Punkt der nicht pflegbaren Abhängigkeiten sollte entsprechend gewichtet werden.
Keine Abhängigkeiten
Schnelle Entwicklung
Modularität
Single Point of Failure
Langer Release-Zyklus
Methode 3 – ziemlich beste Freunde
Bei dieser Herangehensweise werden die Apps nach funktionalen Bereichen gegliedert. So könnte es beispielsweise eine App für Verkauf, eine für Lager und eine für die Finanzbuchhaltung geben. Dieser Ansatz versteht sich als eine Mischung der Methoden 1 und 2.
Hier werden isolierte Apps verwendet, welche in der Regel einen weit größeren Umfang und einen höheren Komplexitätsgrad aufweisen, als es die modularste Lösung (Methode 1) bietet.
Der Hauptgedanke bei dieser Architekturentscheidung liegt ebenfalls klar auf der NAV Basis und dem Individualkundenprojekt. Sie kann jedoch auch für individuelle Business Central Apps adaptiert werden.
Fazit
Leider lassen sich in der Praxis funktionale Bereiche nicht so sauber abgrenzen, wie es in der Theorie so oft zu tun versucht wird. Aus diesem Grund wird eine Schnittstelle zwischen den Apps meist doch wieder notwendig, was jedoch nicht unbedingt bei der bei der Konzeptionierung berücksichtigt wurde. Entsprechend lassen sich solche Szenarien relativ schwer einfangen, da der Funktionsumfang im Vorfeld klar abgesteckt werden muss. Ist das sich nicht mehr ändernde Ziel jedoch definiert, kann mit Hilfe dieser Methodik ein sauberes Ergebnis erzielt werden.
Zusammenfassend kann gesagt werden, dass ein gewisses Maß an Flexibilität und Modularität beibehalten wird, jedoch bei weitem nicht so ausgeprägt wie im „tausend App Prinzip“. Entsprechend wird der gravierendste Nachteil, nämlich die Abhängigkeiten, versucht zu vermeiden.
Keine Abhängigkeiten
Modularität
Flexibilität
Zusätzlich zu diesen drei weit verbreiteten Architekturen, nutze ich eine weitere Methode, um die Vorteile der App-Technologie noch besser einsetzen zu können und die Nachteile so gut wie möglich auszugleichen. Diesen Ansatz teile ich häufig mit Entwicklerkollegen, um eine Alternative zu den ersten drei Lösungen aufzuzeigen und gerade in komplexeren Projekten den Überblick behalten zu können.
Methode 4 – teilen macht Spaß
Die Grundidee an dieser Stelle basiert ebenfalls auf der Aufteilung von Funktionalität und Daten in verschiedene Apps. Jedoch wird an dieser Stelle nicht versucht rein nach funktionalem NAV-Modul zu strukturieren, sondern zusätzlich nach „App-Layern“.
Der Grundgedanke an dieser Stelle ist eine gewollte Aufteilung von „Shared Data“ (Daten die in verschiedenen Bereichen benötigt werden) und „Helper-Functions“ (Funktionen die grundlegende Businesslogik zur Verfügung stellen) gegenüber des eigentlichen Businesscodes und den funktionalen Daten.
Diese Technik kann sowohl im NAV-Umfeld, als auch in Business Central verwendet werden und bietet eine gute Basis, um auch bei geänderten Anforderungen eine klare Struktur zu bieten.
Fazit
Durch die klare Trennung und Strukturierung auf Layer-Ebene sind wir in der Lage trotzdem so granular zu arbeiten wie notwendig. Es gibt eine feste Abhängigkeit (Layer 2 zu Layer1), die berücksichtigt werden muss. Sonst ist der Entwickler frei in der Gestaltung.
Ähnlich wie bei der Performance-Optimierung ist der Prozess nie wirklich abgeschlossen. Mit jeder zusätzlichen Anpassung muss erneut überlegt werden, welcher der beste Weg ist, um die neuen Anforderungen umzusetzen. Es muss ggf. umstrukturiert und Code aus einer Layer-2-App in Layer-1 zurückgespielt werden. So werden Daten erreichbar und Funktionen nutzbar gemacht.
Diese etwas komplexere Architektur und die nachträglichen Umgestaltungen bringen mitunter einen höheren Aufwand mit sich. Meiner Meinung nach lässt sich dieser jedoch durch die immensen Vorteile rechtfertigen. In den meisten Projekten ist dies der von mir favorisierte Ansatz.
Modularität
Flexibilität
Definierte Abhängigkeiten
Höherer Entwicklungsaufwand
