Bestimmen, wann konfiguriert und wann programmiert werden soll

Abgeschlossen 100 XP

Als Entwickler sollten Sie sich Apps auf Microsoft Power Platform aus der Perspektive nähern, dass das Schreiben von Code zum Erreichen der gewünschten Funktionalität der Geschäftsanwendung als Ausnahme von No-Code- und Low-Code-Ansätzen betrachtet wird. Qualitätsbereiche wie Verwaltbarkeit, Aktualisierbarkeit, Stabilität und Leistung sollten jedoch auch berücksichtigt werden, wenn Sie bestimmen, welcher Ansatz für ein bestimmtes Szenario am besten geeignet ist.

Es ist wichtig, zu lernen, was Microsoft Power Platform standardmäßig kann, da Sie nicht etwas erstellen möchten, das bereits vorhanden ist und nur konfiguriert werden müsste. Dies gilt auch für die in den verfügbaren Dynamics 365-Apps implementierten Funktionen. Beispielsweise sind Rechnungsberechnungen mit variablen Preislisten für mehrere Währungen komplex, aber gut implementiert und in Dynamics 365 Sales erprobt. Wenn diese Funktionalität erforderlich ist, sollten Sie die Verwendung der integrierten Funktionen von Dynamics 365 Sales in Betracht ziehen, anstatt Ihre eigene Berechnungs-Engine zu implementieren.

Sie sollten auch erkennen, dass Microsoft Power Platform häufig etwas auf eine bestimmte Art und Weise implementiert, das der Plattform zugute kommt. Dies kann anders sein, wenn Sie es gewohnt sind, dies in benutzerdefiniertem Anwendungscode durchzuführen. Es ist nicht ungewöhnlich für Entwickler, die noch keine Erfahrung beim Erstellen von Microsoft Power Platform-Lösungen haben, zu versuchen, die Plattform so anzupassen, wie sie zuvor zum Erstellen benutzerdefinierter Apps verwendet wurde. Dies sollte nach Möglichkeit vermieden werden, und Sie sollten versuchen, die Vorteile der Plattform zu nutzen, anstatt sie in etwas zu ändern, dass Sie gewohnt sind. In der Vergangenheit haben Sie möglicherweise die Sicherheit auf Spaltenebene mithilfe von benutzerdefiniertem Code implementiert. Dies ist jedoch in Dataverse nicht erforderlich. Dabei ist die Sicherheit auf Spaltenebene eine sofort einsatzbereite Funktion, die lediglich konfiguriert werden muss.

Geschäftsregeln im Vergleich zum Client-Skript

Der Vorteil von Geschäftsregeln besteht darin, dass sie für Nichtentwickler leicht zu verstehen und zu implementieren sind und als Teil einer Dataverse-Lösung für den Einsatz in der Produktion aufgenommen werden können. In Organisationen, in denen Entwicklerkenntnisse nicht leicht verfügbar sind und das Application Lifecycle Management nicht implementiert ist, sind Geschäftsregeln eine bevorzugte Methode zur Implementierung von Logik, selbst wenn einige Problemumgehungen erforderlich sind, z. B. berechnete Zwischenfelder, in denen die Werte zum Einchecken einer Regel enthalten sind.

An einem gewissen Punkt ist es jedoch nicht mehr möglich, mit Geschäftsregeln die Geschäftsanforderungen zu implementieren. Möglicherweise verursacht auch die Komplexität, die die Regeln mit sich bringen, dass Entwickler es vorziehen, die Logik in Client-Skripten zu schreiben. Ein Szenario könnte sein, wenn Sie eine komplexe verschachtelte Logik „if/then/else“ haben, die besser in einer switch-Aussage oder in einer einfachen Sequenz eines if-Blocks erreicht werden könnte. Das andere Szenario beinhaltet das Arbeiten mit dynamischen Werten, auf die eine Geschäftsregel nicht leicht zugreifen kann. Formularbenachrichtigungen und das Herausfiltern von Auswahlwerten sind beispielsweise nicht über Geschäftsregeln verfügbar.

Workflows/Power Automate-Flows im Vergleich zu Plug-Ins

Dataverse bietet verschiedene Methoden zum Implementieren von Logik, um auf Ereignisse im System, insbesondere auf Datenänderungen wie Erstellen, Aktualisieren, Löschen der Datenzeilen, zu reagieren. Geschäftsanforderungen können durch No-Code-Lösungen mit Workflow und Power Automate sowie durch Erweiterung von Dataverse unter Verwendung von serverseitigem (Plug-Ins) oder clientseitigem (Skript) Code umgesetzt werden.

Sie können die Optionen mithilfe eines Ansatzes bewerten, der dem in der Diskussion über Geschäftsregeln und Client-Skripte verwendeten ähnlich ist: Bewerten Sie die Geschäftsanforderungen und Organisationsfunktionen, um sie zu implementieren. Es gibt auch einige grundlegende Unterschiede in den Fähigkeiten. Anhand der folgenden Tabelle können Sie ermitteln, wann es möglicherweise besser ist, einen Ansatz anstelle eines anderen zu verwenden.

Funktion Power Automate-Flow Workflow Plug-In
Synchron oder Asynchron Asynchron Beides (Power Automate-Flows werden anstelle von asynchronen Workflows empfohlen). Beides
Zugriff auf externe Daten Ja, mit Konnektoren Nein Ja, unter Verwendung von APIs, einige Sicherheitsbeschränkungen
Wartung Ersteller Geschäftliche Benutzer Entwickler
Kann ausgeführt werden als Aktueller Benutzer oder Flowbesitzer Aktueller Benutzer oder Workflowbesitzer Jeder lizenzierte Benutzer, jedes System oder jeder aktuelle Benutzer
Kann bei Bedarf ausgeführt werden Ja Ja Nein
Kann untergeordnete Prozesse verschachteln Ja Ja Ja
Ausführungsphase Nachher Davor/Danach Davor/Danach
Trigger Erstellen, Spalten ändern, Löschen, Bei Bedarf, Geplant Erstellen, Spalten ändern, Löschen, Bei Bedarf Erstellen, Spalten ändern, Löschen, andere Nachrichten, einschließlich benutzerdefinierter Nachrichten

Microsoft Power Platform entwickelt sich ständig weiter und als Entwickler sollten Sie sich über neue und aufkommende Funktionen informieren. Wenn für Ihre Lösung beispielsweise benutzerdefinierte Einstellungen oder Konfigurationswerte erforderlich waren, mussten Sie zuvor benutzerdefinierte Tabellen zum Speichern dieser Werte verwenden und anschließend benutzerdefinierte Code- oder Plattformtools zum Bereitstellen der Daten verwenden. Das neue Hinzufügen von Umgebungsvariablen hat diese Aufgabe vereinfacht und sie auf das Deklarieren Ihrer Variablen reduziert, sodass sie als Teil der Lösungen aufgenommen und Werte festgelegt wurden – alles ohne Code.

Power Apps Component Framework (PCF)

HTML-Webressourcen waren viele Jahre lang ein zugänglicher Erweiterungsmechanismus für die Clientseite in modellgesteuerten Apps. Eine der Schwächen dieses Ansatzes war die geringe Wiederverwendung dieser monolithischen und nicht erweiterbaren Elemente. Jetzt wurden HTML-Webressourcen durch PCF-Steuerelemente ersetzt.

PCF ermöglicht Entwicklern die Erstellung wiederverwendbarer Komponenten, die von Herstellern anstelle der Standardsteuerelemente verwendet werden können. Dies ist ein gutes Beispiel dafür, wann Fortschritte bei den Plattformfunktionen es Unternehmen ermöglichen, ihre Entwicklungsanstrengungen auf die Schaffung einer soliden Infrastruktur und die Unterstützung von App-Herstellern zu konzentrieren.

Externe Systeme

Die Kommunikation mit externen Systemen ist ein gemeinsames Merkmal der Lösungsimplementierungen. Von einfachen Aufgaben wie dem Senden einer SMS-Nachricht oder dem Aktualisieren von Wechselkursen bis hin zu komplexen Datensynchronisationsszenarien war es früher eine exklusive Entwicklerdomäne. Bei den Implementierungen wurden Plug-Ins, Ereignisveröffentlichungen über Service-Endpunkte und Webhooks verwendet.

Mit der Akzeptanz von Power Automate mit seinen Hunderten von Konnektoren kann die Interaktion mit externen Systemen jetzt von App-Herstellern ohne Verwendung von Code implementiert werden.

Dies bedeutet jedoch nicht, dass die Rolle des Entwicklers überflüssig ist. Es gibt viele komplexe oder leistungsstarke Szenarien, in denen Code erforderlich ist. Darüber hinaus können Entwickler ihre Bemühungen jetzt auf die Erstellung von Diensten und benutzerdefinierten Konnektoren konzentrieren und gleichzeitig das Verbinden der Bausteine an die Hersteller delegieren.

Portale im Vergleich zu benutzerdefinierten Websites

Power Pages bieten zahlreiche sofort einsatzbereite Funktionen und ermöglichen es den Herstellern, robuste Websites zu erstellen und diese nach Bedarf zu erweitern. Entwickler unterstützen häufig anspruchsvollere Portalaufgaben wie ausgefeilte Seitenlayouts (in Liquid-Vorlagensprache) oder die Erweiterung der Front-End-Site-Funktionalität mithilfe von JavaScript.

In hochspezialisierten Szenarien können Sie mithilfe von ASP.NET oder ähnlichen Technologien ein vollständiges benutzerdefiniertes Portal erstellen. Dieser Ansatz ist nicht ungewöhnlich, erfordert jedoch eine Implementierung durch hochqualifizierte Entwickler. Auch hier ist die Entscheidung häufig ein Kompromiss zwischen einer No-Code-Implementierung von Standardfunktionen, aber einer allgemeinen Funktionalität und der kontrollierten Verwendung der Ressourcen des Entwicklers zur Bereitstellung spezieller Funktionen.

Die Entscheidung, wann Code verwendet werden soll, ist keine einfache binäre Entscheidung. Sie müssen viele Faktoren berücksichtigen: Welche Fähigkeiten und Ressourcen stehen Ihnen zur Verfügung, wie ausgereift ist Ihr Unternehmen in Bezug auf das Application Lifecycle Management, wie komplex sind die Anforderungen usw. Oft müssen die Anforderungen auf Einzelfallbasis bewertet werden, da kleine Kompromisse bei den geschäftlichen Einschränkungen die Lösung vereinfachen und von einem komplexen Entwicklungsprojekt auf eine einfache Konfigurationsübung reduzieren können.

Solide, aktuelle Kenntnisse und Verständnis der Plattformfunktionen sind für jeden Entwickler von entscheidender Bedeutung, um rationale, vernünftige Entscheidungen im Hinblick darauf zu treffen, wann Code verwendet wird und wann das System so angepasst werden muss, dass es von Herstellern und Geschäftsanwendern angepasst und konfiguriert werden kann.


Nächste Lektion: Überprüfen Sie Ihr Wissen

Vorherige Nächste