Dieser Artikel wurde maschinell aus dem Englischen übersetzt. Zum englischen Original.
SAP wirbt seit einigen Jahren öffentlich für ereignisgesteuerte Architekturen. Die Argumentation in SAPs eigener Erklärung zum Thema überzeugt: Systeme sollen auf Zustandsänderungen reagieren, sobald sie eintreten, asynchron kommunizieren und lose gekoppelt bleiben. Die Integrationsempfehlungen von SAP gehen noch einen Schritt weiter und verbinden die ereignisgesteuerte Architektur direkt mit dem Clean-Core-Prinzip.
Wir sehen das genauso und haben die FastApps von Arkyn genau nach diesen Prinzipien gebaut. Was viele noch überrascht, ist die Lücke zwischen diesen Empfehlungen und der Art, wie Daten in den meisten mobilen SAP-Instandhaltungslösungen heute tatsächlich fließen, auch in SAPs eigenem Produkt dafür.
Dieser Beitrag zeigt, wie die Synchronisierung zwischen SAP PM und mobilen Geräten typischerweise funktioniert, warum das Standardmodell in großen Unternehmen an Grenzen stößt und wie wir FastCloud, die SAP-Integrationsplattform von Arkyn, gebaut haben, damit sie ereignisgesteuert auf SAP BTP synchronisiert, ohne Änderungen am SAP-Core.
Das Standardmodell: Delta-Synchronisierung, die vom Client ausgeht.
SAP Service and Asset Manager (SSAM) ist die mobile Anwendung von SAP für die Instandhaltung, und ihr Synchronisierungsmodell ist in SAPs eigenen Implementierungsunterlagen gut dokumentiert. Es ist eine OData-V2-Anwendung, gebaut mit dem Mobile Development Kit, die auf SAP BTP Mobile Services mit der Offline-OData-Funktion läuft. Im Backend arbeitet das Mobile Application Integration Framework, das als SAP Mobile Add-On im SAP-System ausgeliefert wird.
Der Synchronisierungszyklus läuft so ab:
- Das Gerät öffnet eine Synchronisierungssitzung mit dem Backend.
- SAP Gateway berechnet, was sich seit der letzten Sitzung geändert hat, und ermittelt mit Delta-Token die Änderungen je Entitätsmenge.
- Die Antwort wird in den Offline-Store auf dem Gerät geschrieben, und die auf dem Gerät gesammelten Änderungen werden an SAP übertragen.
An der Delta-Synchronisierung als Optimierung ist nichts auszusetzen. Sie überträgt weit weniger Daten als eine vollständige Replikation, und SAP hat sie sorgfältig abgestimmt. Aber es ist ein Pull-Modell: Auf dem Gerät kommt nichts an, bevor das Gerät nachfragt, und bei jeder Anfrage muss das SAP-System die Antwort berechnen.
Wo Pull-Synchronisierung an Grenzen stößt.
Mit fünfzig Nutzern sollten Sie davon nichts merken. Mit Tausenden zeigen sich drei Probleme.
Das erste sind Lastspitzen.
Der Schichtbeginn ist der schlimmste Fall: Hunderte Geräte öffnen innerhalb derselben fünfzehn Minuten eine Synchronisierungssitzung, und das SAP-System berechnet für jedes einzelne die Delta-Antwort.
Das zweite sind veraltete Daten.
Zwischen zwei Sitzungen hält das Gerät eine Momentaufnahme. Ein Planer weist einen Auftrag um 09:10 Uhr neu zu, und ein Techniker, der um 09:00 Uhr synchronisiert hat, fährt noch zum falschen Einsatz. Die Daten auf dem Gerät sind nur so aktuell wie die letzte Abfrage.
Das dritte folgt aus dem zweiten und bringt Einführungen zum Scheitern: Vertrauen.
Finden Techniker oft genug veraltete oder widersprüchliche Informationen vor, verlassen sie sich nicht mehr auf die App, rufen wieder beim Planer an und greifen zurück auf Papier.
Ereignisgesteuerte Synchronisierung auf SAP BTP.
FastCloud läuft nativ auf SAP BTP, in einem eigenen Subaccount in der Cloud-Foundry-Laufzeitumgebung, und nutzt Standarddienste von SAP BTP: SAP Event Mesh, den Connectivity Service, SAP Cloud Identity Services und den Authorization and Trust Management Service.
Für Änderungen an Instandhaltungsaufträgen funktioniert das Modell umgekehrt. Ändert sich ein Auftrag in SAP, wird die Änderung über das SAP NetWeaver Add-On for Event Enablement als Ereignis veröffentlicht, über Event Mesh weitergeleitet, von FastCloud verarbeitet und an die Apps übertragen, die sie brauchen.
Der Clean-Core-Teil ist genauso wichtig wie die Echtzeit. Es gibt keine Änderungen am SAP-Core und kein Custom-ABAP zu pflegen. Das Add-On for Event Enablement ist die Standardkomponente von SAP, um ECC- und S/4HANA-Systeme ereignisfähig zu machen, und die Backend-Komponenten von Arkyn werden in einem eigenen Namespace bereitgestellt, getrennt vom Core.
Ein großer Vorteil dieses Aufbaus ist die Kontinuität bei der Migration. Weil die Integration auf den Standarddiensten von SAP für Ereignisse und Konnektivität beruht und nicht auf Custom Code im Core, funktioniert dieselbe Einrichtung mit ECC und S/4HANA. Wenn ein Kunde migriert, zieht die Integration mit um.
Offline bleibt der schwierige Teil.
Ereignisse sorgen für aktuelle Daten vom Server zum Gerät, lösen aber nicht alle Schwierigkeiten vor Ort, wo Techniker in Kellern, an Pipelines und in Stahlkonstruktionen ganz ohne Netzempfang arbeiten.
Unsere Apps sind für den Offline-Betrieb gebaut: Techniker arbeiten ohne Verbindung weiter, und die Daten werden automatisch und zuverlässig mit SAP synchronisiert, sobald die Verbindung wieder steht.
Was die Architektur am Ende bewirkt.
Architekturentscheidungen zeigen sich in den Akzeptanzzahlen. Über alle Implementierungen von Arkyn hinweg erreicht FastWork eine durchschnittliche Akzeptanzrate von 85 %, und die meisten Implementierungen gehen in 2 bis 6 Wochen live, weil die Integration mit einer vorkonfigurierten Prozessabdeckung für SAP PM und CS beginnt statt bei null.
Bei Energy Transfer, einem Pipelinebetreiber aus den Fortune 500, arbeiten mehr als 8.000 SAP-Techniker mit den iOS-Apps von Arkyn.
Ein intuitives Design sorgt für die Nutzung in der ersten Woche. Die Synchronisierungsarchitektur, der Teil, den niemand sieht, sorgt für die Wochen danach, weil sie das Vertrauen der Nutzer erhält.
Wenn Sie mobile Instandhaltungslösungen für SAP bewerten, stellen Sie früh eine Architekturfrage: Wenn sich ein Auftrag in SAP ändert, wie kommt die Änderung auf das Gerät? Lautet die ehrliche Antwort „beim nächsten Abruf durch das Gerät“, sollten Sie verstehen, was das für Last, Latenz und Vertrauen in Ihrer Größenordnung bedeutet, bevor Sie sich festlegen.
Über den Autor.
Rune Durhuus-Andersen ist Mitgründer und CTO von Arkyn. Er entwickelt seit über 20 Jahren SAP-Software für Unternehmen, darunter 13 Jahre als Leiter der Entwicklung bei Invokers, heute Trifork Smart Enterprise. Derzeit treibt er die Innovation bei Arkyn in den Bereichen KI und Technologie voran.