Kafka (Eingangsagent)


images/download/thumbnails/44944572/arrow_up-version-1-modificationdate-1582703346536-api-v2.png Einführung: Eine Beschreibung dieser Phase finden Sie im Abschnitt Phase 1 (Einführung).


images/download/thumbnails/44944572/image2020-3-12_15-36-29-version-1-modificationdate-1583980587771-api-v2.png

images/download/attachments/44944572/1175-version-5-modificationdate-1657524295921-api-v2.png images/download/attachments/44944572/1176-version-2-modificationdate-1657524222586-api-v2.png images/download/attachments/44944572/1177-version-2-modificationdate-1657524354623-api-v2.png


Hinweis: Siehe auch Abschnitt Dateinamen, Dateimuster, Pfade, System-Konstanten und Variablen.

(1) Nur relevant für das Zusatzmodul Load Balancing, um das Profil auf einem bestimmten Node zu starten.

(2) Der Kafka-Alias. Siehe Abschnitt Kafka-Verbindungen.

(3) Das Topic, von dem Nachrichten empfangen werden.

(4) Eine optionale ID eines Kafka-Consumers (in einer Consumer-Gruppe), die bei jeder Anforderung an einen Kafka-Broker übergeben wird.

(5) Falls gesetzt, wird eine E-Mail gesendet, wenn ein Tombstone empfangen wird, ansonsten wird er übersprungen und ignoriert. Ein Tombstone hat immer einen Null-Payload, daher darf er nicht verarbeitet werden, da sonst das Mapping beim Parser einen Fehler erzeugt.

(6) Der Datentyp des Schlüssels der Nachricht. Wichtiger Hinweis: Der Datentyp muss immer angegeben werden. Achten Sie darauf, dass Sie beim Senden und Empfangen immer übereinstimmende Typen verwenden. Wird z. B. eine Nachricht als Byte/String definiert und gesendet und dann als Integer/Byte gelesen, führt das zu einem Fehler und die Nachricht kann nicht gelesen werden. Lobster_data als Consumer ist so lange blockiert, bis jemand diese falsche Nachricht vom Broker entfernt und verarbeitet so lange keine Nachrichten von diesem Topic!

(7) Der Datentyp der Nachricht. Wichtiger Hinweis: Der Datentyp muss immer angegeben werden. Achten Sie darauf, dass Sie beim Senden und Empfangen immer übereinstimmende Typen verwenden. Wird z. B. eine Nachricht als Byte/String definiert und gesendet und dann als Integer/Byte gelesen, führt das zu einem Fehler und die Nachricht kann nicht gelesen werden. Lobster_data als Consumer ist so lange blockiert, bis jemand diese falsche Nachricht vom Broker entfernt und verarbeitet so lange keine Nachrichten von diesem Topic!

(8) UTC-Timestamp. Damit kann eine Neuabholung aller Nachrichten, die jünger als der angegebene Zeitpunkt sind, ausgelöst werden. Der Parameter wird automatisch nach Abholung zurückgesetzt.

(9) Wenn gesetzt, dann wird jeder Record asynchron committed. Wenn nicht gesetzt, dann kann ein Intervall angegeben werden, nach wie vielen Records asynchron committed wird.

(10) Mit dieser Option ist es möglich, sich statisch an ausgewählte Partitionen zu hängen. Hierbei wird explizit keinerlei automatisches Rebalancing berücksichtigt.

(11) Über das Kontextmenü können weitere Consumer-Properties definiert werden.

(12) und (13) Nachrichten werden in einem Buffer gesammelt. Das Profil wird mit den gesammelten Nachrichten gestartet, wenn entweder die maximale Anzahl an gesammelten Nachrichten erreicht ist oder die maximale Wartezeit. Wird das Profil gespeichert, werden Nachrichten im Buffer gelöscht. Hinweis: Es können hier auch manuell die gew ü nschten Sekunden eingegeben werden.

(14) Wenn Nachrichten gesammelt werden, können Sie hier entscheiden, was zurückgegeben werden soll. Bei Alle müssen die einzelnen Nachrichten evtl. mit einem Trennzeichen verbunden werden.

(15) Sind Bedingungen gesetzt und erfüllt (bei Funktionen muss die Funktionskette true ergeben), dann findet eine vorzeitige Weiterleitung statt.

System-Variablen und Header-Properties


Beim Empfang wird der Key einer Nachricht in der System-Variable MSG_CALL_KAFKA_KEY abgelegt (falls definiert) und steht damit im Mapping zu Verfügung. Header-Properties einer Nachricht können über System-Variablen der Form MSG_CALL_<KEYNAME> (alles großgeschrieben) ausgelesen werden.

Antwortweg


Siehe Abschnitt Antwortweg Kafka.