Important note: This Input Agent can only be selected if at least one JMS connection has been set up.

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 a JMS 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. Note: If you use style "Topic", the checkbox "Persistent (Durable)" will appear. Set this checkbox if (4) is a durable queue (such a queue will survive a broker restart) . If you are using ActiveMQ, you must use a JMS Client ID in the connection, otherwise, this generates an error, which you cannot detect directly, but only in the Server Logs under _data/error.logs in the following form:

...javax.jms.JMSException: You cannot create a durable subscriber without specifying a unique clientID on a Connection...

(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) JMS message selector: If you need to filter the messages you want to receive, you can use a JMS API message selector, which allows you as consumer to specify the messages you are interested in. See the corresponding section below. Note: Does not apply to type "Topic".

(6) Only confirm messages 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 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 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 JMS server takes effect and the message may be delivered again or rejected and forwarded to the Dead Letter Queue. 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.

(7) 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.

JMS 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.

JMS message selectors

JMS message selectors use a relatively complex language that is constructed in a similar way to a SQL WHERE clause. Such a selector can be used for filtering on message headers and properties, but not on the message content. Following are a few examples because the Oracle documentation is a bit thin there.

Element	Description	Example selector
Header fields	Any headers except JMSDestination, JMSExpiration and JMSReplyTo.	JMSPriority = 9
Properties	Message properties that follow Java identifier naming.	releaseYear = 1982
String literals	String literals in single quotes, duplicate to escape.	title = 'Sam''s'
Number literals	Numbers in Java syntax (int and double).	releaseYear = 1982
Boolean literals	TRUE and FALSE.	isAvailable = TRUE
( )	Brackets.	(releaseYear < 1980) OR (releaseYear > 1989)
AND, OR, NOT	Logical operators.	(releaseYear < 1980) AND NOT (title = 'Thriller')
=, <>, <, <=, >, >=	Comparison operators.	(releaseYear < 1980) AND (title <> 'Thriller')
LIKE	String comparison with wildcards '_' (stands for a single character) and '%' (stands for any sequence of characters, including an empty sequence). Both wildcards can be anywhere in the string.	title LIKE 'Thrill%'
IN	Find value in set of strings. The IN operator works only on sets of strings, not on numbers.	title IN ('Off the wall', 'Thriller', 'Bad')
BETWEEN	Check whether number is in range (both numbers inclusive).	releaseYear BETWEEN 1980 AND 1989
IS NULL, IS NOT NULL	Check whether value is null or not null.	releaseYear IS NOT NULL
*, +, -, /	Arithmetic operators.	releaseYear 2 > 2000 - 20*

Note: Take a look at the Response "JMS" on how to send messages to selectors, i.e. how to send messages that can be fetched by a specific selector.

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.