View number of messages not consumed

Thank you very much…

we are using Non Durable because there is no consumer present at this moment. Consumers will be added later on…

This is the reason we want to select as Non Durable… So that messages can be lost after placing topic.
Whenever we add new consumer then messages can be consumed (While adding consumer will select Durable Subscriber option).
If we use Non Durable then we will not get to know which subscriber received and which one not picked.
How we can verify same when we use Durable Subscriber need to know.

I’m sorry but I am still having difficulty understanding your question.
You say you start by creating a topic and publishing messages. You say it is OK if those messages are discarded as long as there are no active consumers.
When you first add a consumer, it will be a durable subscriber. From that point onwards, that consumer will receive messages, including those published while it is offline.
So, let’s take an example:
On Monday, you create the topic and publish 100 messages (ID 1-100). There are no consumers so the messages are discarded by UM.
On Tuesday, you add your first two consumers (C1 and C2). You then publish 100 more messages (ID 101-200). Those will be delivered to C1 and C2. If C1 goes offline after message ID 150 is published, then messages 151-200 will be queued for the C1. Let’s say C1 is still offline at the end of Tuesday.
So, what information is available to you at the end of Tuesday?

  • You will be able to see that 200 messages have been published on the topic.
  • You will be able to see that you have two durable subscribers (C1 and C2) for your topic.
  • You will be able to see that C2 is connected and C1 is not.
  • You will be able to see that the last message delivered to C1 is ID 150 and the last message delivered to C2 is ID 200.
  • You will be able to see that 50 messages are queued and waiting to be delivered to C1.
  • You will NOT be able to see exactly what the first message was that C1 and C2 received (ID 101).
  • You will NOT be able to see exactly how many messages C1 and C2 have received to date.

Does this clarify things?

1 Like

Thank you very much…

i have one more concern for GIMA format,

we were using GIMA format in our project.
GIMA format example sample data in below,

<?xml version='1.0' encoding='UTF-8' ?>

<sActMsgG3:ActorReadRequest xsi:type=‘sActG3:ActorReadRequestMessage’ >




problem is we did parsing in webmethods. because above structure depending reference document.

We are working on parsing/validating an XML file that is specific to our partner. It has SOAP data in the XML file. We are trying to create a document type for the XML file but not able to get the complete structure. Please help in getting the document type created for this XML.

This new question is unrelated to UM.
Can you please repost it as a new thread in an Integration Server forum?

Hi Jonathan,

I Hope you are doing Good.

I need your help one more time.

We are using Durable subscribers and Type is Persistent, If Subscribe not yet available Data not yet store event and i sea event showing 0 values. if i am snoop was start and will start publish data. it;s stored in Snoop once subscribe will start and try to re-publish it’s reached to Subscribe.

My requirement was, want store data in Event and if subscribe will start will automatically subscribe all data store in UM.

What are steps are will followed for above scenario will do…

Please help here…

Usually a durable subscriber is created the first time a subscribing client connects, and it remains in place after that. So any events published before a subscriber connects for the first time will not be available. Is this the scenario you are referring to?

If you want any new subscribers to receive messages that were published before the subscriber came online, then you can achieve this by disabling JMS Engine on the channel. But if you do this, then all events will be stored indefinitely and you will have to take steps to purge them at some point. You can do this by defining a time-to-live (TTL) on the channel or individual events to ensure that UM removes them when they reah a certain age.

You say you see the event count as zero. Where precisely do you see that? On the channel or on the durable subscriber (named object)?

Also, what version of UM are you using?

Thank you Jonathan,

it’s working fine…

Hi Jonathan,

Scenario 1:- If subscribe is down after subscribe UP.
Subscribe is down after UP. i am trying to re-publishable in UM subscribe. it’s showing event count increase. how did know data sent to subscribe

Scenario 2:- already Subscribe UP
i am trying to publishable. it’s showing event count increase

My question is:-

which data send to Subscribe or not, how did know from UM?

Hi Jonathan,

We need one more help…

Subscribe was down, when subscribe is UP all messages are send to Subscribe. what are the steps are followed

We had used TOPIC Durable
Type: Persistent

Please help here…

Hi Varadharajulareddy ,

If you are using topic with durable subscriber , and the subscriber is down when the messages were published. Once the subscriber comes up it will subscribe all the messages.

Are you looking for any specific steps to be followed , can you please describe what steps do you need. It is not clear from your post.

Hi Jonathan,

I need to roll back the message to queue if there is any error (transient) while processing the trigger service. Also I need to suspend the JMS trigger.

I have set the property suspend on transient error. I want to know how trigger will get to know in case of transient error. How to implement this. Can anyone please help on this.

IS services invoked bya trigger are generally smart enough to distinguish between transient and permanent errors. For example if you call an adapter service that fails with a connection error, then that is treated as transient (ISRuntimeException), where as a duplicate unique key error, or SQL syntax error would be treated as permanent (ServiceException).
If you want to control it yourself, then you can call pub.flow:throwExceptionForRetry in your code (possibly in a try-catch block), to tell the calling trigger that this is a transient exception.

Thanks jonathan,
which you mentioned all steps we had followed. But we have used Http connectivity for this steps are followed. i didn’t see JMS re-trigger the Subscription Topic messages


Are you saying that you make an outbound HTTP call in the service tha is invoked by the trigger?
And that the HTTP call fails?
Are you using pub.client:http?
If so, what sort of exception does it throw?
It is possible that it always throws a ServiceException, which will not cause the trigger to suspend.
You can put a try-catch block around the pub.client:http call and in the catch block invoke pub.flow:throwExceptionForRetry.
That will flag this as a transient error, which would cause the trgger to suspend (if you have configured it that way)

Thanks jonthan,
Yes, we have make an outbound HTTP call in the service that is invoked by the trigger and HTTP call failed like as Service unable , service down etc…

Please find the attached trigger monitor and subscribe flow in try.catch block.

Background story:-

we had used UM combination with type Persistent, if any time Subscribe was down. after some time subscribe will come online(server up). all storage topics will automatically send to Subscribe.

That only we had implemented transient error and re-trigger to JMS.

Please explain in this scenario how to sent to subscribe server

trigger Monitor.PNG
try and catch.PNG

Hi Jonathan,

I believed it. i heard by using Universal message (version 9.9) , while publishable and subscribe scenario, for example subscribe was down. while data message was publishable and store data from Topic(topic should be durable and combination of type is persistent). subscribe comes online. whatever data store in topic, automatically sent to subscribe. Is it correct or i am not??

If correct, we have followed same scenario, it’s not yet sent to subscribe server.

if any wrong to my end… please explain the scenario, which scenario sent the all messages to subscribe server automatically.

we were using below,

UM version :9.9
Topic : Durable subscribe
subscribe server http

Please let us know if you any requested information.

What you are describing is basic JMS and is fully supported by UM. Here’s the sequence:

  • Create a topic in Enterprise Manager using the JNDI tab. This will create the JNDI entry and the channel. The channel will be of type Mixed, which is correct.
  • Create a connection factory in Enterprise Manager using the JNDI tab. Enter the URL of the UM server in the CF definition. I recommend setting Shared Durable to True.
  • In your subscriber, establish a durable subscription to the topic you previously created. If you are using Integration Server as the client, then set your JMS trigger to Topic (Durable) and enter a name for the durable subscriber in the trigger.
  • Publish some messages to the topic and verify that they are received by the subscriber.
  • Stop the subscriber. (Note: the durable subscriber will still be present on the UM server, visible in the Named Object tab under the channel).
  • Publish some more messages
  • Restart the subscriber and verify that the messages that you published while the subscriber was down, are received correctly.

As I said, this is a very basic, standard JMS use-case and works exactly as I describe here.

I hope this helps.

Thank you for step by step explained Jonathan,

It’s published all are message while subscribe was down, after that all publishable message while subscribe serve come online. is it automatically sent to subscribe server for all are messages ???

Thank you for step by step explained Jonathan,

It’s published all are message while subscribe was down, after that all publishable message while subscribe serve come online. is it automatically sent to subscribe server for all are messages ???

or any need implementation transient error code…

Please help here…

I don’t understand your question fully.
UM will automatically send all messages to the subscriber that were published while it was down - there’s nothing special about that, no special code needed.