Eine Frage, die in Webinaren, Workshops und Gesprächen immer wieder gestellt wird: Wo sind die Grenzen von Power Apps?
WEKO ist ein im süddeutschen Raum bekanntes, hochwertiges Möbel- und Einrichtungshaus. Neben der Ware, die in den 5 Filialen direkt mitgenommen werden kann, werden bestellte Artikel wie z.B. Maßanfertigungen direkt zum Kunden nach Hause geliefert. Um diese Lieferungen effektiv und effizient zu planen, beschäftig WEKO mehrere Mitarbeiter speziell für die Tourenplanung.
Wir durften zusammen mit der IT von WEKO eine Power App entwickeln, welche die gewachsene Lösung auf Basis Microsoft 365 ablösen sollte.
Die Herausforderungen
WEKO nutzt ein ERP-System, welches im internen Netzwerk läuft (On-Premises). Damit die Mitarbeiter die Touren planen können, werden Informationen aus dem ERP-System benötigt. Nach der Planung müssen bestimmte Informationen wieder in das ERP-System geschrieben werden.
Die große Frage, die es zu klären galt war, wie kriegen wir die Daten aus dem lokalen Netzwerk in die Cloud (Dataverse) und wie schreiben wir sie aus der Cloud wieder zurück in das ERP-System und das unter Einhaltung folgender Voraussetzungen:
- für den Zugriff aus der Cloud in das LAN dürfen keine zusätzlichen Firewalleinstellungen notwendig sein.
- mit dem ERP-System darf schreibend nur über den Application-Layer kommuniziert werden, welcher einen SOAP-Service zur Verfügung stellt
- die neue Lösung muss einfach in der Bedienung und deutlich performanter als die bisherige Lösung sein.
Eine weitere Anforderung, welche sich während der Konzeption ergeben hatte war, dass unsere Business-Logik - in Form eines Plugins - diejenige Komponente war, welche mit dem oben beschriebenen Application-Layer kommunizieren soll. Es musste also möglich sein, programmatisch auf diesen lokalen SOAP-Service zuzugreifen.
Grundsätzlich gab es 3 Fragen zu klären:
- wie stellen wir eine sicher Verbindung aus der Cloud in das LAN her, um mit dem SOAP-Service kommunizieren zu können?
- wie kommen wir an die Daten, welche in der Power App verarbeitet werden sollen?
- wie stellen wir eine zufriedenstellende User-Experience (UX) sicher?
Recherche und mögliche Ansätze
Wie stellen wir eine sicher Verbindung aus der Cloud in das LAN her, um mit dem SOAP-Service kommunizieren zu können?
- On-Premises Data-Gateway
Das Data-Gateway ist eine Technologie von Microsoft, welche es bestimmten Cloud-Technologien erlaubt, über einen Konnektor mit bestimmten Diensten in einem LAN zu kommunizieren.
Azure Hybrid Connection
Sie basiert auf dem Hybrid-Relay-Pattern. Die Kommunikation wird dabei auf Basis von Web-Sockets betrieben, ist bidirektional und die Firewall muss nicht angefasst werden. Sie ist Bestandteil des Azure App-Service und ermöglich damit das programmatische Ansprechen von Ressourcen aus dem lokalen Netzwerk so, als würde der Code selber auch in dem lokalen Netzwerk ausgeführt werden.
Wie kommen wir an die Daten, welche in der Power App verarbeitet werden sollen?
- Virtual Tables
Die Virtual Tables werden über das Dataverse bereitgestellt und verhalten sich wie die herkömmlichen Tabellen, haben allerdings einige Einschränkungen. Im Hintergrund wird mittels eines Data-Providers auf die Zieldatenbank zugegriffen. Der Data-Provider muss dabei bestimmte Funktionen (CRUD) implementieren um den Datenzugriff lesend, aber auch schreibend zu ermöglichen. Es gibt bereits bestehende Data-Provider, die genutzt werden können, man kann sie aber auch selber implementieren. - Synchronisation
Eine weitere Möglichkeit ist, die Daten, welche aus der lokalen Datenbank zur Verarbeitung in der Cloud benötigt werden, per Synchronisation in das Dataverse zu spiegeln. Der Nachteil dabei ist, dass es keine Echtzeit-Daten sind. Zur Synchronisation gibt es Möglichkeiten über Azure-Dienste oder aber Software von Drittanbietern.
Wie stellen wir eine zufriedenstellende User-Experience (UX) sicher?
Die Grundidee des User-Interfaces (UI) war dem Benutzer die Möglichkeit zu geben, Waren, welche ausgeliefert werden können, per Drag&Drop in eine Kundenbezogene und zeitlich terminierte Ladung ziehen zu können. Mehrere Ladungen an einem Tag - eine Ladung je Kunde - ergeben dann eine Route.
Unsere Vision war auf der linken Seite eine filterbare Auswahl an Kundenbezogenen lieferbaren Waren, welche per Drag&Drop auf einen in Tage unterteilten Kalender gezogen werden können. Über die Einträge an einem Tag, wird die Route festgelegt.
Da es in den Modeldriven Apps keine Komponente gibt, welche diese Anforderung abdeckt, sahen wir 2 Möglichkeiten:
- Webressource
Webressourcen sind typische Web-Dateien (HTML, JS, CSS), welche man in eine Modeldriven View oder Form einbinden kann und dort dann mittels der Web-API andere UI-Komponenten oder auch Backend-Ressourcen programmatisch ansprechen kann. Über diesen Weg könnten wir also innerhalb einer View oder eines Forms per HTML, JS und CSS in das bestehende UI eingreifen und es um neue, selbst entwickelte Komponenten ergänzen.
- PCF
PCF steht für Power Apps component framework und gibt Entwicklern die Möglichkeit eigene UI-Komponenten für Power Apps zu entwickeln. Der Vorteil gegenüber den Webressourcen ist, dass dabei ein Standard eingehalten werden muss. Dadurch lassen sich die Komponenten in verschiedenen Views und Forms wiederverwenden und über Properties konfigurieren.
Proof of Conecpt
- On-Premises Data-Gateway vs. Azure Hybrid Connection
Leider haben wir keinen Weg gefunden, wie wir aus einem Plugin heraus programmatisch über das Data-Gateway mit dem LAN kommunizieren können. Aus diesem Grund haben wir es relativ frühzeitig als Lösungsmöglichkeit ausgeschlossen. Zudem hat uns der Ansatz über die Azure Hybrid Connection - dadurch, dass sie Bestandteil eines Azure App-Service ist, eine Vielzahl weiterer Möglichkeiten eröffnet. Z.B. der Zugriff auf die SOAP-Schnittstelle des ERP Systems aus einer Canvas-App mittels eines Custom-Connectors usw.
- Virtual Tables vs. Synchronisation
Der Ansatz über die Virtual Tables ist wirklich genial. Leider aber haben sie (noch?) Einschränkungen, welche sich dem geübten Benutzer wie ein Fehler darstellen und Verwirrung auslösen. Z.B. beim Filtern oder Suchen von Datensätzen. Dies konnten wir auch nicht über den Ansatz eines selbst geschriebenen Data-Providers nicht lösen, was uns vom Microsoft Support bestätigt wurde. Wenn diese Restriktionen nicht mehr bestehen, bieten sich völlig Neue Möglichkeiten bei der Entwicklung von Modeldriven Power Apps. - Webressource vs. PCF
Mit Webressourcen haben wir in der Vergangenheit bereits sehr viel entwickelt. Meist handelte es sich um kleine Anpassungen oder Automatisierungen. Für ein so großes Vorhaben empfanden wir den Weg innerhalb eines Standards zu entwickeln als passender. Der PoC hat gezeigt, dass sich auch komplexe Anforderungen an eine Web-Komponente sowie Drag&Drop mittels PCF lösen lassen.
Die Lösung und Gesamtkonzept
Täglich werden bestimmte Daten aus dem ERP-System in ein lokales Warehouse gespiegelt. Die Daten, welche zur Tourenplanung benötigt werden, werden über eine Drittanbietersoftware aus dem lokalen Warehouse regelmäßig ins Dataverse synchronisiert. Dort werden die Touren von den Mitarbeitern der Tourenplanung in einer Modeldriven Power App per Drag&Drop geplant und modifiziert. Im Hintergrund lösen die Aktionen der Benutzer Funktionen in einem Plugin aus. Das Plugin kommuniziert dann mit der REST-API eines Azure App-Services, welcher seinerseits wit dem SOAP-Service des ERP-System kommuniziert und dafür sorgt, dass die geplanten Touren im ERP-System für das Personal der LKW-Planung sichtbar werden. Ein schöner Roundtrip.
Und ja, das ganze Konstrukt ist performant. So performant, dass die Lösung bei der Präsentation von den zukünftigen Nutzern Applaus kassieren durfte.
Fazit
Wir sehen keine Grenzen aufgrund von Größe, Menge oder technologischer Möglichkeiten - diese sind unseres Erachtens unbegrenzt. Die Grenzen liegen mehr in der Sinnhaftigkeit einer Lösung und damit in der Gegenüberstellung von Kosten und Nutzen.
Nutzt Power Apps, denkt groß und baut Lösungen, die euch einen Mehrwert schaffen.