---

Introduction: You can find a description of this phase in section Phase 1 (Introduction).

---

(1) Only relevant for the add-on module Load Balancing to start the profile on a specific node. Note: See also section File Names, File Patterns, Paths, System Constants and Variables.

(2) Selection of an AMQP alias.

(3) Selection of the message type (Subscriber, Topic, Routing or RPC). The style RPC is synchronous, the others are asynchronous. Note: If you use style RPC, it is additionally necessary to use a Response Route of type Custom Class and the specific class PassBackDataResponse. The reason is that in the case of an RPC call a response is expected by the calling client, which is generated by the mentioned Response Route class in Lobster_data and from there returned to the Input Agent and then to the client. See also section Third Possibility - HTTP Response Chain.

(4) Name of the queue or topic to listen to. See also (3). Note: If an Azure Service Bus is used and Topic is selected in (3), the following syntax must be used here: <topic_name>/subscriptions/<subscription_name>, e.g. mytopic/subscriptions/mysubscription.

(5) The routing key is a message attribute that the server uses to decide how the message should be routed to queues. For details please refer to the documentation of the AMQP server used, e.g. here for RabbitMQ. Note: Does not apply to type Subscriber and RPC.

(6) Set this checkbox if (4) is a durable queue (such a queue will survive a broker restart).

(7) Here you can set the Consumer Delivery Acknowledgement behaviour, i.e. how Lobster_data confirms the receipt of a message to the message bus, see here, for example. If the checkbox is not set, the default behavior applies, i.e. the receipt is acknowledged after the backup file of the profile job has been created (except for message type RPC). If the checkbox is set, a received message will only be confirmed after the job has been successfully completed. Processing in the background is not possible in that case (parallel processing and queueing of jobs). If the Response Routes have checkbox Execute response in own thread set, the receipt of a message is always confirmed after phase 6. Note: If a message is not confirmed by Lobster_data, the setting of the AMQP server takes effect and the message may be delivered again or rejected and forwarded to the Dead Letter Queue (see also the following section Message Properties). If this is the case, you can therefore, similar to working with databases, "commit" a transaction at the end of the processing in the profile if no error has occurred. In the event of an error, profiles for error handling can be set up, for example, which may then process the erroneous messages from the dead letter queue. Note: A dead letter queue can also be created via an AMQP Response Route if the profile that uses this Response Route has a defined system variable AMQP_SYS_<name of the message system property>. For RabbitMQ, for example, that would be AMQP_SYS_x-dead-letter-exchange, see here.