Server-sent Events (SSE) verarbeiten

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.