Schedule Message Polling From WebSphere MQ in MuleSoft
Learn about various MQ message polling scenarios in MuleSoft and how to configure schedule polling from WebSphere MQ in this tutorial.
Join the DZone community and get the full member experience.Join For Free
As a MuleSoft Certified Architect, Designer and Developer, I recently worked on API implementations for one of our clients using MuleSoft’s CloudHub. One common feature that we use across APIs implementations is to poll message from IBM WebSphere MQs.
In this article, we will demonstrate MQ message polling scenarios (Normal Message Polling, Schedule Message Polling, Message Polling with Delayed Processing and MQ Message Delay) using MuleSoft.
As we know, Mule provides a WMQ Connector, which connects to a WebSphere MQ server using the WMQ protocol for putting and polling messages from MQs.
Let’s get started and see different use cases which are very common and useful in polling messages from WMQs.
1. Normal Message Polling From MQ
This is the easiest and most popular message polling use case. Here we will have to poll message from MQ as soon they get posted. To achieve this in Mule, we will use Mulesoft WMQ connector as the inbound endpoint, which will listen to the MQ and pick the messages as soon as they are available.
As we can see in the above use case, Mule WMQ listener keeps listening to the MQ all the time and picks the messages whenever they are posted to the queue.
Now, we might have some use cases where we need to poll messages in a scheduled fashion. Let’s move on to our next use case, which deals with such scenarios.
2. Schedule Message Polling From MQ
2.1 Using Mule Poll Scope and Mule Requestor Module
Mule provides Poll Scope to schedule message processor invocation at regular intervals. Scheduling can be done using “Fixed Frequency Scheduler” or “Cron Scheduler.”
Here, we will use Mule Poll Scope with fixed frequency scheduler to invoke a flow at a regular interval, which will have the Mule Requestor Component to poll messages from the MQ.
Let’s walk through the configuration steps to achieve schedule polling:
Let’s configure the poll scope to invoke the message processor at an interval of 20Sec as below.
Create a WMQ connector to connect to the MQ server.
Use a Mulesoft Requestor Component to pick the message from the MQ using configured WMQ connector in step-2.
Great, we are done with configurations. Let’s post 4 messages to the MQ, which we will expect to be polled by this Mule project at an interval of 20 seconds once this project is deployed. Let’s deploy the project and see how Mule polls the messages at an interval of 20 seconds in the below screen. Please note that there may be some time difference in the logs as there is some execution time taken by the Mule components as well.
This is the most recommended approach to schedule message polling from the MQ. However, let’s move on to see the other ways we can achieve this.
2.2 Defining MQ Message Delay Property
This approach needs modification at the time of the message being posted to the MQ. We can define a message delay property for messages before posting to the MQ. This allows the message to be available in the MQ, but it will not be available for polling by any component until the delay time is over. This will achieve schedule polling for each message, as the Mule WMQ connector will not poll the messages before the delay time is over.
2.3 Using Mule Thread Sleep Property
Here we can pick the message from the MQ once it is available, but won't process the message immediately. We can define a specific delay on message processing using the Mule thread sleep property. The below code snippet shows how to implement a delay using a Groovy component to sleep in the flow execution. However, it's not recommended to put sleep into the thread unless there is a specific requirement, as this might cause an issue when we have a large number of pending threads on JVM.
<scripting:component doc:name="Groovy"> <scripting:script engine="Groovy"><![CDATA[ sleep(20000); return message.payload;]]> </scripting:script> </scripting:component>
Let’s share our knowledge to expand our MuleSoft community.
Opinions expressed by DZone contributors are their own.