---

Einführung: Eine Beschreibung dieser Phase finden Sie im Abschnitt Phase 1 (Einführung).

---

(1) 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) Auswahl eines AMQP-Aliases.

(3) 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 in Lobster_data 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) 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) 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) 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) Hier können Sie das Consumer Delivery Acknowledgement einstellen, also wie Lobster_data auf dem Message-Bus den Empfang einer Nachricht bestätigt, 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 von Lobster_data 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.