Issue with JMS Message as subscribed - their body not getting evaluated on subscriber side

Hi Team,

I have built a basic point to point subscription - using pub.jms.sendAndWait (on publisher) and pub.jms.reply (on subscriber side).
Standard JMStrigger is being used (which I also used to create Queues (Destination and Destination ReplyTo) on UM v 9.9 [I don’t have access to Queue Admin]).

pub.jms.sendAndWait is implemented as synchronous and as above mentioned separate Destination and DetinationReply to queue specified on it. Now I see from the Server logs, that the trigger is being executed when the message is published and the subscriber services is executed (from services usage) however in the reply message - the text that we want to pass through from request message doesn’t happens. Checked further using - ‘savePipelineToFile’ & ‘restorePipelineFromFile’ and could understand that though request message do show up in pipeline, but when we try to map it’s value to a string or the whole message into another JMS Message, it will not allow.

At this point, I am not sure - whether there is an issue with the naming convention or something else (I had similar problem in native WM pub sub, to address I named inputs of subscribing service with full qualified name of doc being passed & ir fixed). Tried different combination and it didn’t helped. Please assist.

UM Verision - 9.9
IS Version - 9 .9

Let me know, will look forward for a response. Thanks.

Hi Team,

Any response will be appreicated.

Bottome line is, in this point to point setup of JMS messaging - I was not able to pass message ( part of inputs message) as recieved - back to the response being sent back. The response string that I set separately - manually here gets passed ahead fine with no issue.

The IS server is same - my local system, but ofcourse the publisher and subscriber and different flow services here.


When I see an issue like this, I usually suggest you try to narrow down the problem by first hardcoding a value in the reply message. If this works, i.e., if the hardcoded reply message is returned to the requesting service, then we know request-reply is working as expected and the issue has to do with mapping. According to your last post, it sounds like you have already done this, which is great.

If this is the case, then I would try saving the pipeline in the trigger’s target service’s first step (again, it sounds like you have already done this). You want to double check that the values you are trying to map from match what is actually in your pipeline, which is typically the issue. The differences may be subtle, but any differences at all could impact your mapping. Note that I would recommend using pub.jms:triggerSpec as the Specification Reference for your trigger’s target service.


1 Like

This worked for me. Thanks Derek for helping out again.

I changed the input type of JMS trigger service to triggerSpec (just to eliminate odds, otherwise I have seen just using jmsMessage as input should work) and made some mapping changes.

I guess though, in the current setup I have for testing - I will not be able to pass through document type (I used string type for success case here) , since at all the places of documentation it says - “IData message format can only be used when sending a JMS message from one Integration Server to another” and I am working with same Integration server/

Will work on few more things, aspects - with this piece moving fine.