JMS Message

Dear All,

is there any way to retrieve JMS messages from a TOPIC without having a trigger. We need to have a service which will receive all JMS message periodically.

Please help.

Kind Regards,
Sasanka

Yes. Use pub.jms:createConsumer followed by pub.jms:receive.

But this will still receive only one message at a time, and not all the messages. You might have to execute it ‘n’ times to drain all the messages.

In JMS Trigger, there is an option of ‘max batch size’ which you can set to some numbers, and trigger processing service will retrieve between 1 and that many number of messages (defined in max) at a time. However, this can be useful when you have lots of JMS messages being sent, and you want to process batch wise… If the frequency of messages sent is lesser, you dont have to use this option.

HTH
Senthil

Hi Senthil Sir,

Thanks for your quick and prompt response. I have followed your first option, but getting the error as close connection. is there anything else I need to do?

I will do a small POC on your second option today and post the result.

Thanks a lot :slight_smile:

Kind Regards,
Sasanka

When do you get the error as ‘close connection’? While invoking jms:createConsumer service, or jms:receive? Just to make sure you dont miss any parameters while invoking those services, go through the built in services guide…

Do you have any reason for not going with ‘trigger’ approach which is real-time and choose ‘pull’ approach which is scheduler based?

-Senthil

If you do step by step run then it will throw ‘close connection’ error. Try running in single flow it should not throw error.

@Senthilkumar_G -

“… Do you have any reason for not going with ‘trigger’ approach which is real-time and choose ‘pull’ approach which is scheduler based? …” - Is it possible to setup Message Trigger to be executed based on a schedule?

Also is there a way to retrieve messages from UM based on a particular expiry/timestamp.

eg: A bad document has been moved to a RETRY.Q and I would like to retry the message handling service after n-hours for m-attempts.

Best Regards,
Franklin