Is there any way to indicate to the process flow that the JMS trigger is calling, the name of the trigger that called it or any other info? We’d like to have 1 flow service that multiple JMS triggers call and dynamically know which queue we’re processing for. We have up to 300 MQSeries queues we’re needing to process messages for and would like to be able to only have 1 flow service that we call rather than 300.
Hi Diane,
pub.flow:getTransportInfo will help you.
The DocType being returned (pub.flow:transportInfo) contains the requested information:
The field “protocol” should be set to “jms” and the sub document jms contains the triggername
See IS Build In Services Guide for details.
Regards,
Holger
Thank you! However I’m on 9.8 and the transport/protocol pick list doesn’t have jms in it…was this an oversight because I do see jms fields in the doc? Anyway I can get around this?
Hi Diane,
can you try to call the service from your flow and place a savePipelineToFile afterwards?
Then check this file what is in it.
Additionally you can place a restorePipelineFromFile behind the savePipelineToFile using the same filename.
After the service is run for the first time thru jms trigger and the file is written, disable the savePipelineFromFile and debug the service manually.
This will return the saved pipeline for analysis.
I just checked the BIS-Guide for 9.8 and jms is still documented there as valid choice for protocol.
As you are connecting directly to MQSeries with a JNDI Alias your subprotocol should be “jndi”
Can you share a sample transportInfo-Document from your environment?
Omit IP-Adress and Port as they are not relevant for the analysis for this issue.
Good Luck.
Regards,
Holger
I have been debugging while testing and all that is in the pipeline file is the JMSMessage itself.
Attached is a snippet of the transport doc while debugging and also a snippet of what the pick list offers.
transportDocOptions.docx (71.7 KB)
I got it!! I copied the transport doc to my own folder & made it allow me to set other values for the pick list. Then I set the protocol to jndi in a map statement right before calling getTransportInfo and I get the jms info back!
Now if the transport doc in Public allowed other values to be entered I wouldn’t need to make my own copy.
So is the correct way to handle this?
thanks so much!
Hi Diane,
I have checked this with my 9.5 environment and jms is missing there too.
I consider this a bug for which a support incident should be opened at SAG eService.
You should not need to set anything before calling getTransportInfo.
Regards,
Holger
Hi Diane,
Addendum:
can you try to do a test with real jms-trigger and then recovering the saved pipeline (as I have suggested in my earlier post)?
This will return the expected transportInfo-Document
When debugging locally the getTransportInfo is different.
Regards,
Holger
I tested not setting the protocol and saved the pipeline after calling getTransportInfo and verified that I do see the jms info correctly. Thanks!