Geschäftslogik in Dynamics 365 - eine Entscheidungshilfe

Für die Erbringung einer eigenen Geschäftslogik in Dynamics 365 existieren eine Vielzahl verschiedener Möglichkeiten und Technologien. Ubiquitär sind hier unter anderem Plugins, Geschäftsregeln oder JavaScript. Aber auch Azure und die Power Plattform bieten Werkzeuge zur Erweiterung und Integration an. Dazu zählen etwa die mittlerweile fest integrierten Power Automate Flows, Logic Apps oder auch Azure Functions.

Ich wurde daher schon des Öfteren mit der Frage konfrontiert, wann denn nun genau die Indikation für eine bestimmte Technologie gegeben ist – etwa für die Anfertigung eines Plugins gegenüber eines Power-Automate-Flows. Und wann wird überhaupt JavaScript verwendet oder ist das eigentlich immer schlecht?

In diesem Artikel möchte ich euch zu den verschiedenen Möglichkeiten zur Umsetzung von Geschäftslogik in Dynamics 365 einen Überblick geben und dazu eine allgemeingültige Entscheidungsmatrix vorstellen. Diese soll euch bei der Wahl der richtigen Technologie für euren nächsten Anwendungsfall unterstützen.

TL;DR

Server-seitig ist besser als Client-seitig – aber JavaScript ist nicht immer schlecht.

Low-Code ist besser als viel Code – aber kritische Prozesse erfordern manchmal komplexe Umsetzungen.

Lex specialis derogat legi generali – Das speziellere Gesetz verdrängt das allgemeine.

                     |

Server- vs. Client-seitige Logik

Grundsätzlich sollte zunächst immer eine Differenzierung bezüglich der Ausführungsumgebung der Geschäftslogik erfolgen. Das bedeutet konkret, ob der Code auf der Cloud-Plattform (Server-seitig) oder beim Endanwender im Browser (Client-seitig) ausgeführt werden soll.

Kritische Geschäftslogik – also solche, die unternehmensrelevante oder für die Konsistenz des Systems wichtige Prozesse umsetzt – sollte immer Server-seitig implementiert werden. Denn nur dort kann eine sichere, stabile und deterministische Ausführung garantiert werden. Der Code liegt dem Endanwender unzugänglich und manipulationssicher in kompilierter Form vor. Zu Server-seitiger Logik zählen zum Beispiel Plugins oder Geschäftsregeln.

Unkritische Geschäftslogik im Gegenzug kann bei Bedarf Client-seitig erbracht werden. Das prominente Beispiel hierzu ist die Interpretation von JavaScript im Browser des Endanwenders, etwa für die Anpassung von Formularen oder dem Ribbon-Menü. Wird hier ein nicht-unterstützter Browser verwendet oder der Code manipuliert, so dass etwas schiefläuft, hat dies in der Regel keine weiteren schlimmen Auswirkungen auf den internen Zustand des Systems. Eine Aktualisierung der Seite oder das Löschen des Browser-Caches behebt dann fast immer potenziell entstandene Probleme.

Programmierung vs. Low-Code

Unter Low-Code-Lösungen können Softwareanwendungen verstanden werden, die nach dem Baukasten-Prinzip aus vorgefertigten Komponenten visuell erstellt werden können. In diese Kategorie fallen zum Beispiel Geschäftsregeln, Power Automate Flows oder Logic Apps. Solche Low-Code-Lösungen sollten grundsätzlich der Programmierung vorgezogen werden. Der Vorteil bei diesen liegt in der schnellen und unkomplizierten Erstellung der Anwendungen – gerade auch für Nicht-Programmierer. Gegenüber selbstgeschriebenem Code unterliegen Low-Code-Lösungen außerdem einem verminderten Wartungs- und Bereitstellungsaufwand. Die Implementierungsdetails sind in den Komponenten verborgen und Updates, Bugfixing oder Erweiterungen werden von den jeweiligen Anbietern übernommen.

Aber aufgepasst: Handelt es sich bei eurem Anwendungsfall um komplizierte, algorithmische und tief verschachtelte Geschäftslogik, kann ein Low-Code-Ansatz erfahrungsgemäß schnell unübersichtlich bis unmöglich werden. Die Erstellung und spätere Anpassungen kosten dann eine Unmenge an Zeit. In solchen Fällen ist ein Entwickler gefragt, der die Geschäftslogik effizient und flexibel in Programmcode abbilden kann – zum Beispiel in Form eines Plugins oder einer Azure Function.

Integrationslösungen

Begleitend zum reinen Customizing auf der Dynamics-365-Plattform müssen oft Integrationslösungen angefertigt werden. Meist sollen dazu zeitgesteuert oder ereignisorientiert bestimmte Aktionen ausgeführt werden. Dabei kann es sich um das einfache Versenden von Benachrichtigungen, aber auch einer Datensynchronisation aus Fremdsystemen handeln. Je nach konkretem Anwendungsfall bieten sich hier Power Automate Flows, Logic Apps oder Azure Functions an.

Gerade Power Automate Flows, als moderner Ersatz für die konventionellen Workflows, decken hier ein breites Spektrum ab. Sie lassen sich einfach entwickeln und bereitstellen. Deren Einsatz sollte daher immer zuerst evaluiert werden.

Wie das Salz in der Suppe …

Nein, JavaScript ist nicht böse. Und ja, es sollte trotzdem so spärlich wie möglich im Customizing von Dynamics-365-Umgebungen eingesetzt werden. Es unterliegt der bereits oben angesprochenen Problematik aller programmierten Lösungen, dass der Code eigenhändig entwickelt und gewartet werden muss. Was bei JavaScript erschwerend hinzu kommt, ist der instabile Kontext. Unterschiedliche Browser, Endgeräte und ECMAScript-Versionen sowie die dynamisch-typisierte Natur der Sprache erhöhen die Wahrscheinlichkeit von Laufzeitfehlern, deren Auswirkungen dem Endanwender oft direkt ersichtlich sind. Dass die Wartung und Migration einer großen JavaScript Code-Basis sich als aufwändig erweisen kann, haben wir spätestens bei der Umstellung auf das Unified Interface mit der neuen Client-API feststellen müssen.

Allerdings gibt es auch Anwendungsfälle, bei denen der Einsatz von JavaScript nicht nur gerechtfertigt ist, sondern auch kein Weg daran vorbeiführt. Hier sollte dann frei von Vorurteilen einfach gewissenhaft entwickelt werden. Einen solchen Fall werde euch in einem meiner kommenden Artikel noch präsentieren.

Ein Schlusswort

Ich habe heute einige Kriterien aufgezählt, die bei der Entscheidungsfindung zur Wahl des richtigen Werkzeuges für die Erbringung von Geschäftslogik in Dynamics 365 beachtet werden sollten. In der Praxis spielen allerdings noch viele weitere Faktoren eine Rolle, die von Fall zu Fall evaluiert werden müssen. Die Entscheidungsmatrix kann und soll dabei kein Schema F abbilden, sondern vielmehr als Wegweiser dienen.

Wie seht ihr das?

Habt ihr auch Faustregeln für euch entwickelt oder habt schon mal eine Entwurfsentscheidung im Nachhinein bereut? Ich würde mich freuen, wenn ihr eure Erfahrungen mit mir auf Twitter teilt!