JMS Get activity
Introduction
A JMS Get activity, using its JMS connection, retrieves all JMS messages available in a specific queue and is intended to be used as a source in an operation.
Create a JMS Get activity
An instance of a JMS Get activity is created from a JMS connection using its Get activity type.
To create an instance of an activity, drag the activity type to the design canvas or copy the activity type and paste it on the design canvas. For details, see Creating an activity instance in Component reuse.
An existing JMS Get activity can be edited from these locations:
- The design canvas (see Component actions menu in Design canvas).
- The project pane's Components tab (see Component actions menu in Project pane Components tab).
Configure a JMS Get activity
Follow these steps to configure a JMS Get activity:
-
Step 1: Enter a name and specify settings
Provide a name for the activity and specify the options for retrieving messages. -
Step 2: Review the data schemas
Any request or response schemas generated from the endpoint are displayed.
Step 1: Enter a name and specify settings
In this step, provide a name for the activity and specify the options for retrieving messages. Each user interface element of this step is described below.
Tip
Fields with a variable icon support using global variables, project variables, and Jitterbit variables. Begin either by typing an open square bracket [
into the field or by clicking the variable icon to display a list of the existing variables to choose from.
-
Name: Enter a name to identify the activity. The name must be unique for each JMS Get activity and must not contain forward slashes
/
or colons:
. -
Queue name: Enter the name of the queue to retrieve the JMS messages from.
-
Message selector: Enter a message selector to specify the messages to be retrieved (optional).
-
Wait time (milliseconds): Enter the time in milliseconds to wait to retrieve messages.
-
Maximum batch size: Enter the maximum number of messages to be retrieved.
-
Transacted Session: Select to use a transacted session. When using a transacted session, an
acknowledgeId
is returned in the activity response, which can then be used to acknowledge the message through the Acknowledge activity. If unselected, anacknowledgeId
is not returned. -
Save & Exit: If enabled, click to save the configuration for this step and close the activity configuration.
-
Next: Click to temporarily store the configuration for this step and continue to the next step. The configuration will not be saved until you click the Finished button on the last step.
-
Discard Changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.
Step 2: Review the data schemas
Any request or response schemas generated from the endpoint are displayed. Each user interface element of this step is described below.
-
Data schemas: These data schemas are inherited by adjacent transformations and are displayed again during transformation mapping.
Note
Data supplied in a transformation takes precedence over the activity configuration.
The response data schema consists of these nodes and fields:
Response Schema Node/Field Description getActivityResponse
Node representing the activity response acknowledgeId
String with the acknowledge ID, returned only when using a transacted session messages
Node representing the messages retrieved item
Node representing each message retrieved messageHeaders
Node representing the message header of the retrieved message JMSCorrelationID
String of the correlation ID of the retrieved message JMSDeliveryMode
String indicating whether the retrieved message will be persistent ( 2
) or non-persistent (1
)JMSDestination
String representing the destination of the message JMSExpiration
Integer representing the time in milliseconds to expire the message, with 0
indicating a message will never expireJMSMessageID
Unique identifier for the message JMSPriority
Integer value ranging from 0
through9
indicating the priority of the messageJMSRedelivered
Set to true
if the message is being resent to the consumerJMSReplyTo
The reply destination that is supplied in the replyTo
field in the Send activity's request schema or theJMSReplyTo
header field of the JMS messageJMSTimestamp
The time in milliseconds that the message was sent JMSType
The message type that is supplied in the JMSType
header field of the JMS messagecustomMessageProperties
Node representing the custom JMS message properties item
Node representing the custom properties name
The name of the custom property value
The value of the custom property messageBody
The body of the JMS message -
Refresh: Click the refresh icon or the word Refresh to regenerate schemas from the JMS endpoint. This action also regenerates a schema in other locations throughout the project where the same schema is referenced, such as in an adjacent transformation.
-
Back: Click to temporarily store the configuration for this step and return to the previous step.
-
Finished: Click to save the configuration for all steps and close the activity configuration.
-
Discard Changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.
Next steps
After configuring a JMS Get activity, complete the configuration of the operation by adding and configuring other activities, transformations, or scripts as operation steps. You can also configure the operation settings, which include the ability to chain operations together that are in the same or different workflows.
Menu actions for an activity are accessible from the project pane and the design canvas. For details, see Activity actions menu in Connector basics.
JMS Get activities can be used as a source with these operation patterns:
- Transformation pattern
- Two-target archive pattern (as the first source only)
- Two-target HTTP archive pattern (as the first source only)
- Two-transformation pattern (as the first source only)
To use the activity with scripting functions, write the data to a temporary location and then use that temporary location in the scripting function.
When ready, deploy and run the operation and validate behavior by checking the operation logs.