/ AWS

Push Notification von Vorgangsänderungen per AWS IoT

Europace bietet als Marktplatz für die Vermittlung von Krediten nicht nur smarte Frontends, sondern erlaubt seinen Partnern auch eine Anbindung über diverse APIs. Anlässlich der Anbindung eines CRMs wurden zwei APIs in KreditSmart entwickelt: eine Export-Schnittstelle für den Abruf von Vorgangsdaten und eine Schnittstelle zur Registrierung auf Vorgangsänderungen mittels Push. Dieser Artikel beschreibt die Implementierung der Vorgangsänderungen-Push-API. Eine Übersicht unserer APIs befindet sich übrigens auf developer.europace.de.

Zunächst der Use Case im Detail: ein außerhalb der Europace Plattform laufendes System (hier: ein CRM) soll aktuelle Vorgangsdaten aus Europace lesen und darstellen können. Im CRM können Änderungen am Vorgang ausgelöst und nach Europace übermittelt werden. Europace hat die Hoheit über die Vorgangsdaten und stellt somit die "Source of Truth" dar. Das CRM muss also die eigenen Daten stets mit Europace abgleichen. Änderungen können durch den Nutzer selbst, andere Mitarbeiter oder auch innerhalb Europace ausgelöst werden. Damit der Nutzer des CRMs stets auf den aktuellen Daten arbeitet, müssen Vorgangsänderungen schnellstmöglich an das CRM übermittelt werden.

Eine schnelle Aktualisierung des CRMs kann entweder durch hochfrequentes Polling oder durch anlassbezogene Push-Nachrichten erfolgen. Polling kann letztlich wie eine Suchquery interpretiert werden, bei der der Aufrufer als Suchkriterium verschiedene Parameter definieren kann. Dazu gehören beispielsweise Vorgang-IDs oder die Abfrage auf "alle seit Zeitpunkt X erfolgten Änderungen". Die Parameter werden natürlich stets ergänzt um Sichtbarkeits- bzw. Authorisierungs-Filter, so dass keine fremden Daten ausgeliefert werden. Diese Form der Abfrage hat verschiedene Konsequenzen, die letztlich sowohl das CRM als auch die Europace Plattform vor Datenaktualitäts- und Skalierungsprobleme stellt.

Push-Nachrichten bieten einen anderen Ansatz: zum Zeitpunkt einer Vorgangsänderung ist in Europace bereits bekannt, dass und wo eine Änderung stattgefunden hat. Es kann also punktuell ein Signal verschickt werden, das letztlich nur aussagen muss: "An Vorgang XYZ ist eine Änderung eingetreten". Bemerkenswert ist an dieser Stelle, dass in der Push-Nachricht der Vorgang nicht komplett enthalten ist, es sich also um eine sehr rudimentäre Notification handelt. Das CRM braucht sich nur an der Push-API registrieren, um bei Änderungen Notifications zu erhalten. In Kombination mit einer anderen API (in unserem Fall die oben erwähnte Export-Schnittstelle) kann dann für den genannten Vorgang ein kompletter Datensatz abgerufen werden.

In Europace werden im Laufe des Tages viele Vorgänge angelegt und geändert. Im Zweifel kann jeder Tastendruck als Vorgangsänderung an alle registrierten Systeme verschickt werden. Ein Push-Mechanismus bietet deshalb ebenfalls Herausforderungen an die Skalierbarkeit von Europace und angebundenen Systemen, hat aber einen Vorteil: Resourcen werden nur bei echtem Bedarf genutzt - anstatt im Zweifel eine teure Suche durchzuführen, die möglicherweise sogar mit leerem Ergebnis antwortet. Eine weitere Option zur Steuerung der Systemlast liegt in einem aktiven Throttling, d.h. Push-Nachrichten können gezielt gepuffert und verzögert verschickt werden. Bei der Gelegenheit kann auch noch Deduplikation durchgeführt werden, so dass am Ende sogar die Anzahl der Notifications auf ein Minimum beschränkt wird. Diese Form der Optimierung kann übrigens nicht nur beim Sender (Publisher), sondern auch beim Empfänger (Subscriber) angewendet werden, so dass der Subscriber sich selbst vor einer zu hohen Rate an Notifications schützt.

Flow von Vorgangsänderungen

Wir haben uns bei KreditSmart für das Push-System entschieden, standen aber vor der Frage, wie das Management der Subscriptions implementiert werden soll. Um solch ein Standardproblem nicht selbst lösen zu müssen, haben wir nach geeigneten AWS Services geschaut. Im Vergleich zu einer eigenen Lösung sparen wir somit Implementierungs- und Maintenance-Aufwände. Wir sind auf der Suche nach geeigneten Konzepten und Providern auf AWS IoT gestoßen, das mittels MQTT ein leichtgewichtiges Messaging erlaubt.

Nun denken viele beim Begriff "IoT" schnell an Kühlschränke und Thermometer, die ihren aktuellen Status regelmäßig reporten. Verwunderung war also die erste Reaktion, als wir intern die Idee vorgestellt haben. Doch tatsächlich passt der Gedanke gut in unseren Use Case: wir wollen bei Änderungen zeitnah und leichtgewichtig nur einen minimalen Trigger auslösen, so dass eine beliebige Menge an Subscribern weitere Entscheidungen treffen kann. Erwähnenswert ist wohl, dass wir temporäre Probleme eher ignorieren und keine Garantien geben, dass jedes einzelne Update versandt wird. Wir warten außerdem nicht auf eine Eingangsbestätigung jedes Subscribers. Es handelt sich also um ein klassisches Fire-and-Forget, was im Laufe der letzten Monate nie zum Problem wurde.

Wie sieht nun der Flow (siehe Grafik) eines Vorgang-Updates aus? Nach dem internen Verarbeiten einer Änderung wird über interne Services die Notification nach AWS IoT versandt. Subscriber erhalten die Nachricht und können anhand der Vorgangsnummer die neueste Version des Vorgangs aus der Exportschnittstelle laden. Spätestens hier wird die oben erwähnte Authorisierung relevant: KreditSmart stellt sicher, dass nur authorisierte Services oder Nutzer einen Vorgang lesen dürfen. Wenn also jeder Subscriber von jeder einzelnen Vorgangsänderung Kenntnis erlangt (also auch von Vorgängen die nicht "seine" sind) und zu jeder Änderung einen Aufruf der Exportschnittstelle erzeugt, dann wird dies zu vielen abgewiesenen Requests führen. Schlimmer noch: auch die Vorgangsnummer kann schon als sensibles Detail betrachtet werden. Wünschenswert ist also, wenn eine Notification nicht an jeden einzelnen Subscriber geschickt wird, sondern nur an die Subscriber, die zum Zeitpunkt der Änderung mindestens Leseberechtigung für den Vorgang besitzen.

Ein solcher Filtermechanismus ist mittels AWS IoT/MQTT kein Problem, denn Nachrichten werden einem Topic zugeordnet. Jeder Subscriber muss sich also auf "sein" Topic registrieren, so dass er nur die für ihn passenden Nachrichten erhält. Wir haben das Topic als Repräsentierung der Organisations- und Partnerstruktur modelliert. Soll heißen: eine Organisation "Vertrieb XY" kann sich als Subscriber registrieren und erhält nur Notifications zu Vorgängen, die in oder unterhalb dieser Organisation liegen. Wenn eine Organisation stärkere Strukturierung aufweist, beispielsweise nach Nord und Süd, dann können zwei Subscriber registriert werden, die Notifications nur für "Vertrieb XY/Nord" respektive "Vertrieb XY/Süd" erhalten.

Eine Änderung ist mittels Notification nach weniger als 1 Sekunde im externen System erkannt und kann nach Puffern, Deduplizieren und Aufruf der Exportschnittstelle innerhalb von 5 Sekunden dem Nutzer angezeigt werden. Die allgemeine Systemlast ist von der hohen Rate an Export-API-Aufrufen kaum beeinträchtigt, denn es wird eine für Leseoperationen optimierte View des Datenmodells verwendet.

Aufgrund der schlanken Umsetzung gingen Implementierung und Freischaltung schnell vonstatten. Der Mechanismus ist seit Ende 2018 in Nutzung und stieß schnell auf sehr positives Feedback. Wir beobachten das Konzept weiterhin, um bei Bedarf Optimierungen zu ergänzen.