Einstellungen

(1) Nur auf IS starten: Nur relevant für das Zusatzmodul Load Balancing, um das Profil auf einem bestimmten Node zu starten. Hinweis: Siehe auch Abschnitt Dateinamen, Dateimuster, Pfade, System-Konstanten und Variablen.

(2) Verbindungs-Alias: Auswahl eines AMQP-Aliases.

(3) Nachrichten-Art: Auswahl der Nachrichtenart (Subscriber, Topic, Routing oder RPC). Der Style RPC ist synchron, die anderen asynchron. Hinweis: Wenn Sie den Style RPC verwenden, dann ist es zusätzlich notwendig einen Antwortweg des Typs Eigene Klasse und der spezifischen Klasse PassBackDataResponse zu verwenden. Der Grund ist, dass bei einem RPC-Call eine Response erwartet wird vom aufrufenden Client und diese wird durch die erwähnte Antwortweg-Klasse erzeugt und von dort an den Eingangsagenten und dann an den Client zurückgegeben. Siehe dazu allgemein auch Abschnitt Dritte Möglichkeit - Eigene Klasse im Antwortweg.

(4) Queue/Topic: Name der Queue, auf die gehört wird, bzw. das Topic. Siehe (3). Hinweis: Wenn ein Azure Service Bus verwendet wird und bei (3) Topic ausgewählt wurde, muss hier folgende Syntax verwendet werden: <Topicname>/subscriptions/<Subscriptionname> , also z. B. mytopic/subscriptions/mysubscription .

(5) RoutingKey: Der Routing Key ist ein Message-Attribut, das der Server verwendet, um zu entscheiden, wie die Nachricht an Queues weitergeleitet werden soll. Für Details verwenden Sie bitte die Dokumentation des verwendeten AMQP-Servers, z. B. hier für RabbitMQ. Hinweis: Gilt nicht für Typ Subscriber und RPC.

(6) Persistent ('Durable'): Setzen Sie diese Checkbox, falls es sich bei der in (4) angegebenen Queue um eine "durable" Queue handelt (eine solche Queue überlebt einen Neustart des Brokers).

(7) Message erst bei erfolgreichem Job am Ende bestätigen: Hier können Sie das Consumer Delivery Acknowledgement einstellen, also auf dem Message-Bus der Empfang einer Nachricht bestätigt wird, siehe z. B. hier. Ist die Checkbox nicht gesetzt, dann gilt das Default-Verhalten, d. h. der Empfang wird nach dem Anlegen der Backup-Datei des Profil-Jobs bestätigt (außer bei Nachrichten-Art RPC). Ist die Checkbox gesetzt, dann wird eine empfangene Nachricht erst nach erfolgreichem Job-Durchlauf bestätigt. Damit ist keine Verarbeitung im Hintergrund möglich (Parallelverarbeitung und Queueing von Jobs). Ist in den Antwortwegen Antwortwege entkoppelt ausführen gesetzt, dann wird der Empfang einer Nachricht ab Phase 6 immer bestätigt. Hinweis: Wird eine Nachricht nicht bestätigt, dann greift die Einstellung des AMQP-Servers und die Nachricht wird gegebenenfalls erneut zugestellt oder abgelehnt und auf die Dead Letter Queue umgeleitet (siehe auch den folgenden Abschnitt Message Properties). Ist das der Fall, kann man in solch einer Konstellation also, ähnlich wie bei einer Datenbank, am Ende der Verarbeitung im Profil eine "Transaktion committen", wenn kein Fehler aufgetreten ist. Im Falle eines Fehlers können dann z. B. Profile für die Fehlerbehandlung eingerichtet werden, die dann unter Umständen die fehlerhaften Nachrichten aus der Dead Letter Queue abarbeiten. Hinweis: Eine Dead Letter Queue kann auch über einen Antwortweg AMQP angelegt werden, wenn das Profil, das diesen Antwortweg benutzt, eine System-Variable AMQP_SYS_<Name der Message System Property> definiert hat. Für RabbitMQ wäre das z. B. AMQP_SYS_x-dead-letter-exchange, siehe hier.

(8) Virtueller Dateiname ist: Hier können Sie den Namen einer Message Property angeben. Der Wert der Property wird dann als Name der empfangenen Datei verwendet (Log-Übersicht im Control Center). Wird kein Wert angegeben, oder die Property wird nicht gefunden oder hat keinen Wert, dann wird für den Dateinamen der Default-Wert amqp.data verwendet. Beispiel: Die empfangen Nachricht hat die Message Property myfilename mit dem Wert test.txt, dann geben Sie im Feld den Wert myfilename an und die empfangene Datei bekommt den Namen test.txt. Hinweis: Beachten Sie bitte, dass Sie im Feld nicht direkt den Dateinamen verwenden können.

(9) Nachrichten sammeln und (10) Max. Wartezeit: 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.

(11) Weiterzuleitender Wert: Wenn Nachrichten gesammelt werden (Wert in (9) größer 1), können Sie hier entscheiden, was zurückgegeben werden soll. Bei Alle müssen die einzelnen Nachrichten evtl. mit einem Trennzeichen (12) verbunden werden.

(12) Trennzeichen für Nachrichten: Das Trennzeichen für Nachrichten. Hier können auch Hex-Codes mit Präfix 0x angegeben werden. Siehe auch (11). Hinweis: Nur aktiv, wenn der Wert in (9) größer 1 ist.

(13) Zusätzliche (vorzeitige) Weiterleitung: Hier können Bedingungen (für numerische Werte, für Strings oder reguläre Ausdrücke) angegeben werden (nur eine muss gelten), wann Nachrichten vorzeitig weitergeleitet werden an das Profil zur Verarbeitung. Wenn die Daten im Beispiel nicht den String lens enthalten (→ entsprechende Bedingung setzen), wird erst gesammelt. Wenn der String lens enthalten ist, wird sofort durchgeleitet und der Sammel-Counter zurückgesetzt, d. h. andere gesammelte Nachrichten werden verworfen. Alternativ zu Bedingungen können Sie eine Funktionskette zur Prüfung verwenden. Liefert die aufgebaute Funktionskette am Ende true, dann wird die Prüfung als erfolgreich betrachtet. Hinweis: Nur aktiv, wenn der Wert in (9) größer 1 ist.

(14) Geben Sie hier die Anzahl der Nachrichten an, bis die Funktionskette geprüft wird. 1 zur Überprüfung jeder Nachricht.

(15) Wählen Sie hier per Doppelklick (oder Pfeil) eine Funktion aus. Diese wird in (16) eingefügt.

(16) Die Funktionskette, wie Sie sie bereits aus Phase 3 kennen. Hinweis: Beachten Sie den spezifischen Parameter-Typ Nachricht.

(17) Neben den bereits aus Phase 3 bekannten Parametertypen gibt es hier zusätzlich den Typ Nachricht.

(18) Hiermit können Sie einen Test durchführen. Siehe folgender Screenshot. Hinweis: Für jede einzelne Funktion kann als Ergebnis entweder der kalkulierte Wert oder ein fest angegebener Wert verwendet werden.

(19) Hier können Sie manuell eine Nachricht eintragen, die für den Test verwendet wird.

(20) Klicken Sie hier, um den Test auszuführen.

(21) Das Ergebnis des Tests.

AMQP Message Properties

Um Message Properties einer Nachricht abzufragen, können Sie Variablen verwenden. Beispielsweise wird die Message Property NameX im Profil über eine im Profil definierte System-Variable MSG_CALL_NAMEX verfügbar. Der Variablenname muss also dem Parameter-Namen in Großbuchstaben mit vorangestelltem MSG_CALL_ entsprechen. Spezifische Beispiele: MSG_CALL_GROUPID, MSG_CALL_SUBJECT, MSG_CALL_MESSAGEID, MSG_CALL_CORRELATIONID.

Hinweis: Wenn Sie AMQP 1.0 verwenden, wird für den Fall, dass das Profil fehlschlägt, die Property DeadLetterErrorDiscription mit der Fehlermeldung gefüllt (ohne Stacktrace). Dazu muss aber die Checkbox (7) gesetzt sein (siehe auch Beschreibung dort).

Profil-Suspendierung

Wenn Profile mit diesem Eingangsagenten suspendiert werden, dann werden während der Suspendierung keine Nachrichten angenommen, sondern verbleiben auf dem Broker. Wird die Suspendierung aufgehoben, kann es bis zu 60 Sekunden dauern, bis diese Nachrichten verarbeitet werden.