Die Low-Code-Revolution wird derzeit von den neuesten Entwicklungen im Bereich KI überdeckt. Das ist irgendwie auch verständlich, schliesslich ist Low-Code nicht annähernd so revolutionär wie die neuesten neuronalen Netzwerke... oder vielleicht doch?
Im Internet liest man häufig, dass man mit Low-Code- und No-Code-Lösungen die Entwicklungskosten um das Zehnfache reduzieren kann. Diese Einschätzung finde ich persönlich etwas zu optimistisch. In meiner Erfahrung ist man aber oft bis zu fünfmal schneller in der Entwicklung. Zwar erreicht dies nicht die revolutionäre Wirkung von KI-Technologien, dennoch sollte der Wert einer solchen Zeitersparnis nicht unterschätzt werden. Zeit ist ja bekanntlich Geld.
Eine der grössten Hürden im Bereich Low-Code ist die limitierte Anpassungsfähigkeit. Man behauptet oft, dass man mit Low-Code-Lösungen wie der Microsoft Power Plattform nur einfache Probleme lösen kann. Das mag vielleicht früher der Fall gewesen sein, doch die Plattform hat inzwischen eine sehr gute Reife erreicht und dank der Erweiterungsmöglichkeiten mit Pro-Code-Komponenten kann man fast alles umsetzen.
Es ist endlich möglich, die Prozesse zu digitalisieren, die bis jetzt noch keine „bezahlbare“ Lösung hatten.
In diesem Blog möchte ich das Potenzial der Power-Plattform in Kombination mit Dataverse-Plugins hervorheben. Wenn du selbst ein Entwickler bist und die erweiterten Funktionen der Power-Plattform erkunden möchtest, findest du am Ende dieses Artikels eine Anleitung für einen modernen Entwickler-Workflow für die Dataverse-Plugins.
Erweiterte Business Logic mit Plugins
Die Entwicklung von PowerApps, die auf Dataverse basieren, eröffnet die Möglichkeit, punktuell Dataverse-Plugins zu nutzen. Diese Plugins werden aktiviert, wenn mit dem Dataverse interagiert wird. Innerhalb dieser Plugins können vielfältige Operationen durchgeführt werden: Verbindungen zu externen APIs, Datenvalidierungen oder spezifische Business-Logic können implementiert werden.
Damit lässt sich die Low-Code- und No-Code-Welt auf elegante Art und Weise mit der Pro-Code-Welt verbinden. Viele Limitationen werden somit überwunden, und man kann das Beste aus beiden Welten nutzen.
Zum Beispiel kann man so für alle Standardkomponenten in einer Business-App, wie Authentifizierung, Security, das gesamte Frontend und alle CRUD-Operationen, die fertigen Komponenten der Power Plattform nutzen. Gleichzeitig lässt sich die komplexere Geschäftslogik mittels .NET und C# in den Dataverse-Plugins erweitern.
Und im Frontend? Manchmal reichen klassische Formulare nicht aus und die Benutzerfreundlichkeit könnte dank spezifischer UX/UI-Designs deutlich verbessert werden. Es gibt dafür auch eine Lösung: Wer eine Model-Driven-App entwickelt, kann sogenannte Webressourcen und PCF-Komponenten nutzen, um in der grafischen Benutzeroberfläche mit JavaScript oder TypeScript eigene Komponenten zu entwickeln. Dadurch lässt sich auch das Frontend, wo nötig, nahezu grenzenlos erweitern.
Entwicklung von Plugins
Die Dataverse-Plugins scheinen weniger verbreitet und bekannt zu sein als die JS/TS-Webressourcen für die Erweiterung des Frontends. Zu diesem Thema findet man auch weniger aktuelle Ressourcen. Die meisten Artikel stammen aus der Zeit vor dem Dataverse, denn die Plugins haben ihre Wurzeln im Common Data Service und in der Dynamics CRM-Plattform.
Microsoft selber ermöglicht nicht den einfachsten Einstieg für Entwickler. Wenn man den offiziellen MS Docs folgt für die Plugin-Entwicklung, wird man in Richtung der Visual Studio Extension gedrängt. Die Benutzererfahrung mit dieser Extension ist ziemlich schlecht, das Tooling ist fehlerhaft und bringt Visual Studio oft zum Absturz. Die Nutzerbewertungen der Extension sind auch nicht die besten...
Die andere in der Dokumentation vorgestellte Option ist der manuelle Weg, bei dem im Entwicklungs- und Debugging-Zyklus viel zu viele Klicks und manuelle Schritte erforderlich sind. Ain’t nobody got time for hat.
Es gibt einen viel besseren Ansatz, der leider noch nicht häufig in den Docs vertreten wird, nämlich die Nutzung der Power Platform CLI. Dort steht ein modernes Toolset zur Verfügung, das die Entwicklung solcher Plugins vereinfacht und einen modernen Workflow ermöglicht. Hier ist eine kleine Schritt-für-Schritt-Anleitung für die Entwicklung eines Dataverse-Plugins in VS-Code mit der Power Platform CLI.
Development Workflow
Anforderungen
Zuerst wird das .NET Framework und die Power Platform CLI benötigt. Beachte hier dass neben der neusten .NET Version das .NET Framework 4.6.2 installiert werden muss. Nach der Installation von .NET lässt sich die Power Platform CLI mit folgendem Befehl installieren:
dotnet tool install --global Microsoft.PowerApps.CLI.ToolVorbereitung
Beginnen wir mit der Erstellung einer neuen Lösung im Portal, welche wir dann herunter. Für diesen Schritt benötigen wir den Namen der Lösung und die Environment-ID. In diesem Fall nehmen wir "DemoSolution" als Beispiel.
pac auth create --environment ****.dynamics.com
pac solution clone --name DemoSolution
cd DemoSolution
dotnet build"dotnet build" erstellt automatisch eine unmanaged solution unter bin/Debug/DemoSolution.zip.
Plugin Hinzufügen
Innerhalb der Lösung erstellen wir einen Ordner für die Quelldateien und initialisieren gleichzeitig ein neues Plugin.
mkdir plugin-src
cd plugin-src
mkdir demoplugins
cd demoplugins
pac plugin init
code .Dies erstellt das Grundgerüst für das Plugin, indem das erste leere Plugin (Plugin1) hinzugefügt wird und öffnet unsere Solution mit VS Code.
Zu beachten ist hier, dass "pac plugin init" eine Solution erstellt, die das erste von potenziell vielen verschiedenen Plugins enthält. Laut Microsoft sollte man immer ein Plugin an eine Aktion (Step) in Dataverse binden. Viele verschiedene Plugins können jedoch in dieser einzelnen Assembly enthalten sein.
Jetzt kann man die Klasse `Plugin1.cs` bearbeiten. Als Beispiel hier wird der angegebene Name auf der Account Entity immer überschrieben.
Am besten nennen wir auch das Projekt, der Namespace und die Solution um, damit später sinvolle Assembly Namen entstehen. Idealerweise folgt man folgende Konvetion: Provider.Solution.Pluigins:
Nun können wir unser Plugin mit dotnet build kompilieren.
Wir müssen nun noch eine Referenz auf das Plugin in der Solution hinzufügen. Aus dem Solution Ordner:
pac solution add-reference --path .\plugin-src\demoplugins\Damit das Plugin sauber mit der Solution integriert wird, werden noch zusätzliche Matadaten benötigt. Diese werden mit add-reference leider nicht hinzugefügt. Am einfachsten macht man das über das Portal während des ersten Deployments.
Deployment
Mit dem Plugin Registration Tool (PRT) die passende Solution öffnen und Plugin-Assembly in der Lösung registrieren:
pac tool prt
Im nächsten Bild "Load Assembly" auswählen und die vorher kompilierte DLL auswählen. Dann Register "Selected Plugins" auswählen. Merken wir uns hier die Assembly ID. Diese werden wir später benötigen.
Nun mit Rechtsklick aufs Plugin klicken und einen Step hinzufügen.
Nun im Maker Portal, innerhalb unserer Demo Solution das Plugin und den Step hinzufügen. Danach nicht vergessen "Publish all customizations":
Nun können wir die benötigen Metadaten von der Online Solution mit einem Sync herunterladen. Danach können wir die Gesamtlösung auch lokal exportieren.
pac solution sync
dotnet build DemoSolution.cdsproj"dotnet build" aus dem Solution Ordner wird jetzt gleich auch die Plugins kompilieren. Wenn wir alles richtig gemacht haben, sollten wir die Assemblies in der exportieren Solution.Zip sehen.
Updates
Nun kommen wir zum interessanten Teil, nämlich wie man Änderungen am Plugin vornimmt und sie bequem auf das Environment überträgt.
Das Ganze lässt sich sehr einfach mit einem CLI-Befehl ausführen. Da jedoch einige Informationen jedes Mal benötigt werden, empfehle ich die Erstellung eines einfachen Powershell-Skripts, damit man wirklich mit einem Klick die Updates hochladen kann.
Im Plugin-Ordner erstellen wir eine Deploy.ps1 Datei mit folgendem Inhalt.
$assemblyId= "ASSEMBLY_ID"
$pluginFile = ".\bin\Debug\net462\WorkframeDemoSolution.GotchaPlugins.dll"
Write-Host "Building..." -ForegroundColor Yellow
dotnet build .
Write-Host "Pushing..." -ForegroundColor Yellow
pac plugin push --pluginFile $pluginFile --pluginId $assemblyId
Write-Host "Done!" -ForegroundColor GreenHier einfach ASSEMBLY_ID durch die zuvor kopierte ID ersetzen. Danach einfach das Skript ausführen und die Updates werden hochgeladen. Das Plugin Registration Tool wird für diesen Schritt nicht mehr benötigt, und man muss den Editor nicht mehr verlassen.