Bedeutung der Client Extensibility
Business Central / Dynamics NAV stellt zur Bearbeitung von Feldern in der Oberfläche einen umfangreichen Satz an UI-Controls zur Verfügung. Dennoch treten in der Praxis immer wieder Anforderungen auf, in denen Anwendern die Bearbeitung von Daten mit Hilfe spezialisierter Controls erleichtert werden soll.
Die Spannweite solcher UI-Anforderungen reicht von der Anzeige einfacher Information bis hin zur Realisierung komplexer Visualisierungen. Nachfolgende Aufstellung gibt ein paar Beispiele für den Einsatz von Client Extensibility.
- Darstellung von hierarchischen Datenstrukturen mit Hilfe von Tree Views
- Darstellung bedingt formatierter Texte
- frei platzierbare Buttons für Schnellaktionen
- Einbetten von Text-Editoren, wie z.B. Richtext-Editor oder HTML -Editor
- 2D- und 3D-Visualisierungen z.B. zur Visualisierung von Lagerabläufen und Lagerregalkonfigurationen
- komplexe Plantafeln, z.B. für die Ressourcenplanung
Technische Grundlage
In älteren Dynamics NAV-Versionen gab es zweierlei Art von Client Extensibility:
- Für den Windows Client wurde präferiert die .NET-basierte Client Extensibility eingesetzt, die auf dem Ausgestalten eines Interfaces basierte und so wie der Windows Client selbst auf der Windows Forms-Technologie aufsetzte. Alternativ konnten auch Web Addins im Windows Client mit Hilfe eines Browser-Controls dargestellt werden, die den Vorteil hatten, sowohl im Windows Client als auch im Web Client verwendet werden zu können.
- Im Web Client waren ausschließlich Web-basierte Addins basierend auf HTML, CSS, Javascript u.ä. verwendbar, während in der hinter dem Addin liegenden Anwendungslogik weiterhin .NET-Technologie verwendet werden konnte.
In heutigen Business Central-Versionen hat sich dies in verschiedener Hinsicht geändert:
- Der Windows Client wurde bereits abgekündigt, womit .NET-basierte UI-Controls im Rahmen der Client Extensibility nicht weiter unterstützt werden. Es kommt also ausschließlich Web-Technologie für die Oberfläche zum Einsatz. Notfalls besteht aber auch hier die Möglichkeit, auf Client-seitiges .NET zuzugreifen, z.B. mit Hilfe der Microsoft Blazor-Technologie.
- In der hinter dem Addin liegenden Anwendungslogik kann die Verwendung von .NET nur noch dann zum Einsatz kommen, wenn als Installationsziel der Extension der Scope OnPrem festgelegt wird. Dies liegt daran, dass Microsoft innerhalb Business Central die Erstellung fremden, .NET-basierten Codes auf Azure-Instanzen nicht zulässt. On Premises-Installation dürfen jedoch weiterhin das .NET-Framework sowie eigene .NET-Assemblies verwenden. Die dafür erforderliche Integration in die Programmiersprache AL hat sich hierbei im Vergleich zu Vorversionen sogar noch einmal erheblich verbessert. Die fehlende .NET-Unterstützung in Azure-Umgebung gleicht Microsoft hingegen dadurch aus, dass für die am häufigsten benötigten .NET-Typen entsprechende native Wrapper-Types in AL verfügbar gemacht wurden. Sollten diese in Einzelfällen nicht hinreichend sein, bleibt ferner die Verwendung von Azure Functions, client-seitigem .NET mit Hilfe von Microsoft Blazor oder gar der Aufruf von Web Services als Option.
- Abseits der zugrundeliegenden Technologien wurde das Deployment von Addins massiv verbessert und integriert sich heute nahtlos in den Deployment-Prozess der Extensions. Und auch die Entwicklung der Addins ist spürbar vereinfacht worden.
Training
Das Client Extensibility-Training vermittelt zunächst den grundlegenden Aufbau eines Client Addins, bevor ein Praxisbeispiel zum Einsatz kommt und von Anfang bis Ende komplett implementiert wird. Das gewählte Beispiel dient später als Grundbauplan für die Realisierung eigener Anforderungen. Die Trainings führe ich überwiegend für Microsoft Implementierungspartner aber auch direkt für Entwickler-Teams von Endkunden durch.