FME Flow: 2024.2
The JMS Subscriber receives notifications from topics and relays them to Java Message System (JMS)-compliant message brokers, such as IBM WebSphere MQ.
Setting up a JMS Message Broker with FME Flow
Before configuring a JMS subscriber, you must set up a JMS broker to work with FME Flow. The steps depend on the broker you use, and are explained in the following section (applicable to both the JMS Subscriber and JMS Publisher):
Creating a JMS Subscriber for FME Flow
- In the FME Flow Web User Interface, select Notifications > Subscriptions, and click New.
- Provide a name for the Subscription.
- Specify JMS for the protocol.
-
Specify the Topics you want to subscribe to using the drop-down selector. To create a topic and use it right away, click +.
- Specify the JMS-specific fields for the subscriber
- Click OK.
JMS-specific fields
| Provider Type or Context | The message broker to connect to, or the initial context factory if the broker is not listed. |
| Provider URL | The URL of the directory containing connection details for the JMS provider. |
| Additional Provider Properties | Any additional provider-specific properties, in the form key=value. For example, randomize=false. Specify multiple pairs on separate lines. In most cases, this field is not required. The JMS brokers tested by Safe, including Apache ActiveMQ, IBM Websphere MQ, and Oracle WebLogic JMS, do not require any additional properties to establish a connection. |
| Connection Factory | The name of the connection factory object. |
| Username | An authenticating username. |
| Password | An authenticating password. |
| Destination(s) | The name of the destination object(s). These correspond to queues and/or topics. Multiple destinations can be specified, separated with a comma. |
| Use Persistent Delivery | If Yes, messages are stored by the JMS broker until the message is delivered to a destination, and can be recovered in the event of a broker restart. If No, messages may be lost in the event of a broker restart during delivery. Persistent delivery is slower than non-persistent delivery, particularly when sending large volumes of messages. |
| Notification Content Template | The message body. |
Sample Configurations
Apache ActiveMQ Sample Configuration
| Java Classpath |
No change required. (Apache ActiveMQ 5.6.0 libraries are bundled with FME Flow.) |
| Provider Type or Context | ACTIVEMQ |
| Provider URL | tcp://server:61616 |
| Additional Provider Properties | -- |
| Connection Factory | ConnectionFactory |
| Username |
-- |
| Password |
-- |
| Destination(s) | dynamicQueues/MyQueue |
IBM WebSphere 7 Sample Configuration
| Java Classpath | ... -FMESERVER_CLASSPATH “...;C:/Program Files (x86)/IBM/WebSphere MQ/java/lib/*” ... |
| Provider Type or Context | WEBSPHERE70 |
| Provider URL | file:/C:/jndi/ |
| Additional Provider Properties | -- |
| Connection Factory | cf1 |
| Username | admin |
| Password | admin |
| Destination(s) | q1,t1 |
Oracle Weblogic Sample Configuration
| Provider Type or Context | weblogic.jndi.WLInitialContextFactory |
| Provider URL | t3://bq-w2008:7001 |
| Additional Provider Properties | -- |
| Connection Factory | jms/TestConnectionFactory |
| Username |
-- |
| Password |
-- |
| Destination(s) | jms/TestJMSQueue |
Notification Content Template
The notification content template uses the following keywords in the incoming notification:
{
"location": "<location>"
"subscriber_content": "custom_message"
}
If the "subscriber_content" keyword is present, it overrides the Notification Content Template.
For example, consider the following Notification Content Template:
Hello, {Location}
If the incoming notification contains the following:
{
"location": "world"
}
The JMS subscriber sends the following message:
"Hello, world"
If the incoming notification contains the following:
{
"location": "world"
"subscriber_content": "My custom message"
}
The JMS subscriber sends the following message:
"My custom message"