AMQP (Eingangsagent)

Verbindungs-Alias

Auswahl eines Alias. Pflichtfeld. Derzeit stehen ausschließlich AMQP-1.0-Aliase zur Verfügung.

Queue/Topic

Name der abzufragenden Queue bzw. des Topics. Pflichtfeld. Manche Broker verlangen ein zusätzliches Präfix, z. B. queue: oder topic: bei SAP Event Mesh.

Endpunkttyp

Legt fest, ob als Quelle eine Queue oder ein Topic abgefragt wird. Pflichtfeld.

Client-ID

Optional. Name des Clients. Bleibt das Feld leer, wird automatisch eine ID generiert. Für eine dauerhafte Topic-Subscription ist eine Client-ID zwingend erforderlich. Im Modus IMMEDIATE steuert die Client-ID zudem, ob Queue-Consumer konkurrieren: Eine gesetzte Client-ID erzeugt einen eigenen Subscriber-Thread, sodass die Consumer einer Queue um die Nachrichten konkurrieren.

Dauerhafte Subscription ('durable')

Nur bei Endpunkttyp = Topic sichtbar. Aktiviert eine dauerhafte Topic-Subscription. Erfordert eine Client-ID sowie einen Namen der Subscription.

Name der Subscription

Name der dauerhaften Subscription. Nur sichtbar, wenn Dauerhafte Subscription ('durable') aktiviert ist.

Servicequalität

Bestimmt, wann eine empfangene Nachricht bestätigt wird (siehe Abschnitt Servicequalität). Pflichtfeld.

Bestätigungsmodus

Bestimmt Zeitpunkt und Verarbeitungsmodus der Bestätigung (siehe Abschnitt Bestätigungsmodus). Pflichtfeld.

Shutdown-Timeout (Sek.)

Nur für die synchronen Bestätigungsmodi (AFTER_PROCESSING, RPC) relevant. Muss der Subscriber-Thread neu gestartet werden, wird zunächst für die eingestellte Dauer auf den laufenden Job gewartet. Nach Ablauf wird der Thread neu gestartet und die Nachricht nicht bestätigt – der laufende Job läuft weiter, die unbestätigte Nachricht wird aber vom Broker erneut zugestellt (doppelte Verarbeitung). Standard: 30.

Tipp

Setzen Sie den Timeout etwas höher als die maximal zu erwartende Ausführungszeit des Profils, um doppelte Verarbeitung zu vermeiden.

AT_MOST_ONCE

Eine empfangene Nachricht wird sofort bestätigt. Tritt vor dem Upload ins System ein Fehler auf, kann die Nachricht verloren gehen.

AT_LEAST_ONCE

Eine empfangene Nachricht wird erst bestätigt, nachdem sie ins System hochgeladen wurde. Tritt zwischen Upload und Bestätigung ein Fehler auf, kann eine Nachricht doppelt verarbeitet werden. Bei RPC führt ein Fehler bei der Bestätigung nach einem erfolgreichen Job – bei dem die RPC-Antwort bereits gesendet wurde – zu einer erneuten Zustellung: Der Job läuft erneut und erzeugt eine zweite Antwort.

IMMEDIATE

Asynchrone Subscription. Nachrichten werden bestätigt, nachdem der Upload ins System erfolgreich war. Profile mit identischen Einstellungen werden automatisch zum selben Subscriber-Thread zusammengefasst (1:n) – alle diese Profile erhalten die Nachricht.

 ACHTUNG: Eine gesetzte Client-ID erzeugt einen neuen Subscriber-Thread; bei Queues konkurrieren die Consumer dann (siehe Client-ID).

AFTER_PROCESSING

Die Nachricht wird erst bestätigt, nachdem der zugehörige Job erfolgreich beendet wurde. Erfordert die Servicequalität AT_LEAST_ONCE. Ein Profil mit diesem Modus erhält immer einen eigenen Subscriber-Thread (1:1), da es sich um einen synchronen Vorgang handelt.

RPC

Synchroner Vorgang (wartet, bis eine Antwort gesendet wurde) und erhält daher ebenfalls einen eigenen Subscriber-Thread (1:1).