JMS Request Agent (2.3)

The JMS Request agent sets up a publishing session to the destination that is specified in the profile.

The JMS Request agent uses JNDI to connect to a JMS server. Depending on the type in the the Request field, a JMS Message of the appropriate type is sent. For a list of supported types see JMS UDRs (2.3).

The message is then sent to the specified destination. While in session, the agent creates either a temporary queue or a temporary topic and sets up a consumer for it. If the getResponse field is set to true, the agent expects a reply from the temporary destination. The JMSCycle is then saved in a local cache and sent to the JMS Server. When the reply arrives, the correlation ID of the message is used to match the incoming JMS message with the correct JMSCycle in the local cache. When found, the JMSCycle is removed from the cache and the response field is set to the incoming JMS message. Then the JMSCycle UDR is inserted into the workflow.

If the JMS Request agent encounters a connection failure the agent tries to re-establish the connection with the JMS server. If the agent has not managed to re-establish the connection to the JMS server after five attempts, it will instead try to re-establish the connection for each UDR.

A property can be set to get the JMS Request agent to connect and acquire a Connection Factory object and a Destination object from a JNDI service for every connection attempt. To enable this, add the following property to the relevant EC.

Example - Setting re-establish connection for each UDR

For Helm deployed ECs, in values.yaml add at:
systemProperties:
  - config.properties.mz.jms.reinitialize=true

For Web Interface deployed ECs, in Web Interface add in:
EC Deployment, Execution Context, Configure EC: System Properties: Add -> 
config.properties.mz.jms.reinitialize=true

Deploy the EC again in the Web Interface or with:
$ kubectl delete pod <ec-pod> -n <namespace>

If no response is expected, as getResponse is false, the agent sends the request content to the JMS server and discards the UDR. If the send operation fails, the UDR is inserted once again into the workflow with the status set to 30 or 31. 

If a reply is not received within the specified timeout, the JMSCycle UDR is forwarded with the Response field set to NULL and the status set to 20.


This section contains the following subsections: