Settings

(1) Start on IS only: Only relevant for the add-on module Load Balancing to start the profile on a specific node.

(2) Connection alias: Selection of an AMQP alias.

(3) Message type: 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 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 class and from there returned to the Input Agent and then to the client. See also section Third Possibility - HTTP Response Chain.

(4) Queue/Topic: 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) RoutingKey: 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) Persistent ('Durable'): Set this checkbox if (4) is a durable queue (such a queue will survive a broker restart).

(7) Only confirm message at the end of a successful job: Here you can set the Consumer Delivery Acknowledgement behaviour, i.e. how the receipt of a message to the message bus is confirmed. If the checkbox is not set, the default behaviour 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 Responses 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, 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 a Response "AMQP" if the profile that uses this Response 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.

(8) Virtual file name is: Here you can enter the name of a message property. The value of the property is then used as the name of the received file (log overview in the Control Centre). If no value is specified or the property is not found or has no value, the default value amqp.data is used for the file name. Example: The received message has the message property myfilename with the value test.txt. If the field has the value myfilename, the received file gets the name test.txt. Note: Please note that you cannot use the file name directly in the field.

(9) Buffer messages and (10) Max wait time: Messages are collected in a buffer. The profile is started with the collected messages when either the maximum number of collected messages is reached or the maximum waiting time. If the profile is saved, messages in the buffer are deleted. Note: The desired seconds can also be entered manually.

(11) Value to forward: If messages are collected (value in (9) is greater than "1"), you can decide which ones are to be passed on. If you select "All", you might have to use a delimiter (12) between the single messages.

(12) Delimiter for messages: The delimiter for messages. You can also specify hex codes with prefix "0x". See also (11). Note: Only active if the value in (9) is greater than "1".

(13) Additional (premature) case to forward: Here you can specify conditions (for numerical values, for strings or regular expressions) when messages are to be forwarded to the profile for processing prematurely (only one must apply). If, in the example, the message does not contain the string "lens" (→ set corresponding condition), it will be collected. If the string "lens" is contained, the message is passed on immediately and the collection counter is reset, i.e. other collected messages are discarded. As an alternative to conditions, you can use a function chain to check messages. If the function chain returns "true" at the end, the check is considered successful. Note: Only active if the value in (9) is greater than "1".

(14) Enter the number of messages here until the function chain is checked. "1" if every message should be checked.

(15) Select a function by double-clicking (or using the arrow). It will be inserted in (16).

(16) The function chain, as you already know it from phase 3. Note: Note the specific parameter type "Message".

(17) In addition to the parameter types already known from phase 3, there will also be the type "Message".

(18) You can test your function chain. See the following screenshot. Note: Either the calculated value or a fixed value can be used as the result of each individual function.

(19) Here you can manually enter a message that will be used for the test.

(20) Click here to run the test.

(21) The result of the test.

AMQP message properties

To query message properties of a message, you can use system variables. For example, the message property NameX is available in the profile via a system variable MSG_CALL_NAMEX that has to be defined in the profile. So the variable name is the prefix MSG_CALL_ followed by the parameter name in upper case. Specific examples: MSG_CALL_GROUPID , MSG_CALL_SUBJECT , MSG_CALL_MESSAGEID , MSG_CALL_CORRELATIONID .

Note: If you are using AMQP 1.0 and the profile fails, the message property DeadLetterErrorDiscription is filled with the error message (without stack trace). For this purpose, however, checkbox (7) must be set (see also description there).

Profile suspension

If profiles with this Input Agent are suspended, no messages are accepted during the suspension, but remain on the broker. If the suspension is released, it can take up to 60 seconds for these messages to be processed.