Server-sent Events (SSE) verarbeiten
Die HTTP-Anfrage (REST Call, API Call)-Ereignisaktion kann in Verbindung mit der GET-Methode eingesetzt werden, um eine Verbindung zu einem Server/Endpunkt aufzubauen, der diese Verbindung anschließend nutzen kann, um eine unbestimmte Anzahl von Server-sent Events (SSE) zu übertragen.
In diesem besonderen Anwendungsszenario für die HTTP-Anfrage (REST Call, API Call)-Ereignisaktion ergibt die Anfrage also nicht eine einzige Antwort, sondern potenziell eine Serie von Antworten, die als Stream von Ereignissen ohne vordefinierten "Fahrplan" eintreffen und in Echtzeit verarbeitet werden sollen.
Die zyklische Verarbeitung des "Ereignisstroms" erfordert besondere Maßnahmen im Aufrufkontext, also der Ereignisbehandlung, in der die Verbindung per HTTP-Anfrage (REST Call, API Call)-Ereignisaktion aufgebaut wurde:
Die Option "Streaming verwenden" für die HTTP-Anfrage (REST Call, API Call)-Ereignisaktion muss ausgewählt sein.
Der adressierte Server/Endpunkt muss eine Antwort mit dem Medientyp text/event-stream bereitstellen.
Der Parameter "Inhalt der Antwort" muss ein geeignetes Ziel für die Zuweisung des "Inhalt"(Contents)-Objekts definieren, auf das der "Ereignisstrom" abgebildet wird.
Die per Standard vordefinierte Zuweisung an die Variable httpResponseContent erfüllt diese Voraussetzung ebenso wie eine Zuweisung an ein geeignetes Datenobjekt via Objekt-Feld-Wertauflöser.
Eine Zuweisung an eine Dateireferenz ist dagegen nicht geeignet, um Server-sent Events einzeln und in Echtzeit zu verarbeiten.
Für das Streaming im Kontext einer Ereignisbehandlung muss eine HTTP-Anfrage (REST Call, API Call)-Ereignisaktion mit einer Für jeden Eintrag wiederholen (Schleife)-Ereignisaktion nach folgendem Schema kombiniert werden:
Die HTTP-Anfrage (REST Call, API Call)-Ereignisaktion baut die Verbindung für das Streaming auf und erhält als Antwort ein "Inhalt" (Content)-Objekt mit dem Medientyp (mediaType) text/event-stream.
Die folgende Für jeden Eintrag wiederholen (Schleife)-Ereignisaktion greift auf das "Inhalt" (Content)-Objekt im Parameter "Wertauflöser für Einträge" zu.
Jedes Mal wenn ein konkretes Server-sent Event übertragen wird, wird eine Iteration der Schleife ausgelöst, für die als Bezugsobjekt ein "Inhalt" (Content)-Objekt generiert wird, dessen body-Feld die Daten des Ereignisses beinhaltet.
Die folgenden Konfigurationsbeispiele veranschaulichen die Handhabung der verschiedenen "Inhalt" (Content)-Objekte in unterschiedlichen Zusammenhängen:
|
mediaType |
|
Der Screenshot links zeigt einen Ausschnitt aus einer Ausführen mit-Ereignisaktion, die die Variable httpResponseContent als temporäres Bezugsobjekt für auszuführende Aktionen definiert. die HTTP-Anfrage (REST Call, API Call)-Ereignisaktion schreibt den Inhalt der Antwort per Standard in diese Variable. ►HINWEIS◄ Im Schema (oben) ist das betreffende "Inhalt" (Content)-Objekt blau schattiert hervorgehoben. Im Anwendungsfall links vergleicht eine Objekt-Feld-Regel innerhalb einer Wenn Dann Sonst-Ereignisaktion den Wert des mediaType-Felds mit dem statischen Textwert text/event-stream, um festzustellen, ob es als Antwort auf die HTTP-Anfrage ein "Ereignisstrom" zu erwarten ist. Diese Rückmeldung liegt sofort nach dem erfolgreichen Verbindungsaufbau vor, unabhängig davon, ob die Quelle bereits ein Server-sent Event versendet hat oder nicht. |
|
body |
Auf das body -Feld des "Inhalt" (Content)-Objekts sollte in Verbindung mit der Option "Streaming verwenden" auf keinen Fall direkt zugegriffen werden, da dieser Zugriff erst dann einen Rückgabewert liefert, wenn der adressierte Server die Übertragung von Ereignissen beendet und die Verbindung geschlossen hat. Ob das je passiert, entscheidet die adressierte Quelle. Die Verbindung kann unbegrenzt lange bestehen bleiben und beliebig viele Ereignisse übertragen. |
|
|
|
Das "Inhalt" (Content)-Objekt muss komplett im Wertauflöser für Einträge einer Für jeden Eintrag wiederholen (Schleife)-Ereignisaktion aufgelöst werden, wie dies links über die Variable httpResponseContent umgesetzt ist. In dieser besonderen Konstellation führt die Schleife für jedes per Stream eintreffende Ereignis sofort eine Iteration aus, für die als Bezugsobjekt ein weiteres "Inhalt" (Content)-Objekt gilt, dessen body-Feld die Textdaten des Events (als Byte-Array) wiedergibt. Im Beispiel links wird bei jedem Eintreffen eines Ereignisses sofort eine Benachrichtigung ausgegeben, in deren Meldung das String-Abbild des body-Werts erscheint. Im Titel soll der Wert der Variable $index erscheinen, die die Laufnummer der Iteration in einer Schleife vom Startwert 0 "hochzählt". ►WICHTIG◄ Die Schleife wartet solange auf weitere Ereignisse (Iterationen), bis der adressierte Server/Endpunkt die Verbindung beendet. Bis dahin bleibt ein Thread des Lobster Data Platform / Orchestration-Servers belegt, um auf das Eintreffen weiterer Ereignisse zu "lauschen". Innerhalb des Aktionsblocks für die Iteration kann zwar per Wenn Dann Sonst und Schleife abbrechen ein Abbruchkriterium für das "Lauschen" auf weitere Ereignisse formuliert werden. Dieses wird aber immer nur dann geprüft, wenn ein Ereignis eingetroffen ist. Es kann keine maximale Wartezeit für das "Lauschen" ohne Ereignis definiert werden. Der Parameter "Timeout" in der Konfiguration für die HTTP-Anfrage (REST Call, API Call)-Ereignisaktion betrifft nur für den initialen Verbindungsaufbau und begrenzt nicht die Wartezeit bis zum Eintreffen den nächsten Ereignisses. |
|
|
►HINWEIS◄ Wenn die Für jeden Eintrag wiederholen (Schleife)-Ereignisaktion wie hier beschrieben als "Empfänger" für einen "Ereignisstrom" eingesetzt wird, ist im Unterschied zu allen anderen Anwendungsfällen die maximale Anzahl der auszuführen Iterationen nicht durch den Rückgabewert für den Parameter Wertauflöser für Einträge vorbestimmt. Im Aktionsblock für die Iteration liefert die Variable $length deshalb den Wert "unendlich" (+∞), der als 2.147.483.647 (=231-1) codiert wird. Die übrigen systemseitig definierten "Iterationsvariablen" ($index, $first, $last) funktionieren wie üblich. Allerdings wird der Wert von $last nie $true liefern, weil die letzte Iteration (mit $index = ∞-1) effektiv nie erreicht wird. |
||
