Das Werbeversprechen
In der Welt der Softwareentwicklung versprechen Low-Code- und No-Code-Plattformen eine Revolution. Sie ermöglichen es auch denen, die keine tiefergehenden Programmierkenntnisse haben, Apps zu entwickeln, zu betreiben und zu warten. Doch wie sieht es in der Praxis aus? Wir haben Power Apps von Microsoft auf die Probe gestellt und unsere Erfahrungen in einem realen Projekt gesammelt, um die Möglichkeiten und Grenzen dieser Technologie auszuloten.
Photo by Robo Wunderkind on Unsplash
Was sind Power Apps?
Power Apps ist ein Dienst von Microsoft, der Benutzern die Möglichkeit bietet, Apps mit einem webbasierten Benutzeroberflächen-Editor zu erstellen und als Software-as-a-Service innerhalb von Azure zu betreiben.
Mithilfe von sogenannten Connectoren können diese Apps Daten aus verschiedenen Quellen lesen und schreiben. Hierbei empfiehlt Microsoft besonders die Nutzung von Dataverse, einer vollständig verwalteten relationalen Datenbank, die als Datenbasis für Apps dienen kann.
Mittels Power Automate kann Programmlogik in Form von Cloud-Flows grafisch erstellt und von einer App ausgeführt und genutzt werden.
Ausschnitt eines Cloud-Flow-Beispiels
Power Apps bietet zwei unterschiedliche Arten der App-Erstellung: Canvas-Apps, die sehr flexibel sind, jedoch eine manuelle Konfiguration jedes UI-Elements erfordern, und Model-Driven-Apps, die sich auf das Datenmodell konzentrieren und automatisierte CRUD-Operationen sowie Benutzeroberflächen für dieses Datenmodell bereitstellen.
Der Model-Driven-App-Editor in Aktion
Das Projekt
Unser Ziel war es, den Onboarding-Prozess für Teams auf einer API-Management-Plattform zu automatisieren. Dabei sollte eine Lösung entwickelt werden, die so weit wie möglich ohne Programmcode auskommt und von den Fachabteilungen gepflegt werden kann.
Unsere Erfahrungen
Die Erstellung von Canvas-Apps erweist sich für Fachabteilungen als zu komplex und erfordert fast genauso viel Fachwissen wie die Nutzung eines vollwertigen UI-Frameworks. Für Entwickler, die bereits Erfahrung mit traditionellen Entwicklungswerkzeugen haben, bietet ein vollständiger Code-Ansatz oft mehr Flexibilität und Produktivität. Daher würden wir Canvas-Apps in den meisten Fällen nicht empfehlen.
Model-Driven-Apps hingegen eignen sich gut für einfache UI-Prototypen oder zur Darstellung von Daten in Tabellenform. Für komplexere Anwendungen, extern bereitgestellte Benutzeroberflächen oder anspruchsvolle Validierung sind sie nicht die erste Wahl. Die Möglichkeiten der Business Rules für die Validierung neuer Einträge in der Dataverse-Tabelle waren nicht ausreichend. Auch das synchronisierte Starten einer Validierungslogik in Form eines Cloud-Flows war nicht ohne die Verwendung von JavaScript-Code möglich.
Die Datenverwaltung mittels Dataverse hat gut funktioniert und befreit von so mancher Herausforderung, den der Betrieb einer eigenen Datenbank mitbringt. Dabei gibt es praktische ‚Out of the box‘-Funktionen, wie Row-Level-Security und Auditierung. Das heißt, man kann genau bestimmen, wer Zugriff auf welche Daten hat, und bei Bedarf ganz einfach nachvollziehen, wer was wann geändert hat.
Ein ungelöstes Problem stellt die Umsetzung eines effektiven Migrations- & Backup-Konzepts dar. Insbesondere im Hinblick auf die Durchführung von Schema-Migrationen inklusive Datenanpassungen konnten wir keine Empfehlungen finden. Sind solche Features von entscheidender Bedeutung, scheinen Power Apps nicht geeignet zu sein.
Die Automatisierung von Programmlogiken mit Cloud-Flows kann eine Vielzahl von Aufgaben erleichtern, insbesondere durch die umfangreiche Auswahl an Connectoren, die eine flexible Kombination von Diensten im Microsoft-Ökosystem ermöglichen. Es gibt jedoch einige wichtige Aspekte zu berücksichtigen:
1. Einfachheit: Trotz der benutzerfreundlichen, grafischen Modellierung gibt es weiterhin viel Spielraum für Syntaxfehler, da die meisten Connectoren Textfelder für die Eingabe von Programmausdrücken verwenden.
2. Komplexität: Die Erstellung und Wartung kann schnell unübersichtlich und schwer wartbar werden. Das Abstraktionsniveau der meisten Aktionen ist vergleichbar mit dem von Programmcode, was bedeutet, dass selbst einfache Logiken schnell zu umfangreichen grafischen Darstellungen führen können. Dies ist besonders bei der Implementierung von Fehlerbehandlung und Transaktionsmanagement zu beachten.
3. Performance: Für zeitkritische Aufgaben ist es möglicherweise nicht die optimale Lösung. Die Ausführungszeiten können je nach Komplexität der Flows und der Auslastung der Microsoft-Server variieren, was bereits bei kleinen Flows zu Verzögerungen führen kann.
4. Sicherheit: Obwohl Power Automate den Datenaustausch und die Ausführung von Aktionen in verschiedenen Diensten erleichtert, müssen dabei stets die Sicherheitsaspekte im Auge behalten werden. Dies ist besonders beim Umgang mit sensiblen Daten oder der Implementierung von Zugriffskontrollen wichtig. Insbesondere für Benutzer ohne IT-Hintergrund kann dies eine Herausforderung darstellen und ein hohes Sicherheitsrisiko mit sich bringen.
5. Anfälligkeit für Code-Injection: Die Verwendung von Benutzereingaben als direkte Eingaben für Connector-Funktionen ohne ausreichende Validierung oder Bereinigung kann zu Sicherheitslücken führen. Angreifer könnten dies ausnutzen, um unautorisierten Zugriff auf Systeme zu erlangen, Daten zu manipulieren oder andere schädliche Aktionen durchzuführen. Die Designer der Flows in den Fachabteilungen sind oft nicht in der Lage, dieses Risiko zu erkennen, und die Plattform bietet keine ausreichenden Werkzeuge zur Input-Validierung oder zum kontextspezifischen Escaping von Eingaben. Dies stellt ein erhebliches Sicherheitsrisiko dar, insbesondere wenn die Flows in kritischen Geschäftsprozessen eingesetzt werden. Daher ist es entscheidend, dass Entwickler und Sicherheitsexperten in den Prozess der Erstellung und Überprüfung von Flows eingebunden werden, um solche Sicherheitsrisiken zu minimieren.
Im Bereich der Tests und Bereitstellung hält Power Apps einige interessante Features bereit, stößt aber auch an Grenzen. Auffallend ist, dass ein neuer Build und der Deployment-Prozess mit nur einem Klick durchführbar sind und überraschend schnell ablaufen – ein neues Deployment ist innerhalb von circa 10 Sekunden live. Es existiert ein grundlegendes Staging-Konzept, das jedoch in seiner Funktionalität begrenzt ist. Anstelle einer Continuous Deployment Pipeline basiert der Prozess auf dem Import und Export von Projekten, auch Solutions genannt.
Die Plattform bietet die Möglichkeit, Cloud Flows automatisiert zu testen, und ermöglicht auch UI-Tests der App mittels Selenium. Es ist jedoch zu beachten, dass solche Prozesse für die Fachabteilungen eine Herausforderung darstellen können und in der Regel die Unterstützung durch Entwickler erfordern.
Zur Überwachung (Observability) bieten Power Apps die Integration in Azure Application Insights und das Bereitstellen von Telemetrie-Daten dafür. Dies ermöglicht es, mit wenig Aufwand ein zentrales Logging, Tracing und Monitoring für die Apps einzurichten.
Unser Fazit
Low-Code- und No-Code-Plattformen wie Power Apps haben definitiv ihren Platz in der Softwareentwicklung und können in bestimmten Szenarien erhebliche Vorteile bieten. Sie sind jedoch nicht für jedes Projekt geeignet. Es ist wichtig, die Grenzen und Risiken dieser Technologien zu verstehen, bevor man sich für ihren Einsatz entscheidet.
Power Apps bietet Vorteile, vorwiegend für einfache Szenarien mit strukturierten Daten und einfachen Operationen. Doch bei komplexeren Anforderungen, hohen Qualitätsansprüchen oder spezifischen Validierungsbedürfnissen stößt man an Grenzen.
Unsere Erfahrungen in diesem Projekt haben uns wertvolle Einblicke gegeben und helfen uns nun besser einzuschätzen, wann und wie der Einsatz von Power Apps sinnvoll sein kann.