| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Using MQMD.SourceQueue to check for inbound message? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Cliff |
 Posted: Thu May 24, 2012 12:31 pm Post subject: Using MQMD.SourceQueue to check for inbound message? |
 |
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
Hi all,
I'm coding some Exception handling processing and want to do different things depending on how a flow was started (it's a long story ...). Part of it is a Java Compute Node so I can get at properties of the input queue, if there is one. I'm looking for a reliable way of checking (from within the JCN) whether the flow was started by an inbound message.
I know it's not sufficient simply to check for the presence of an MQMD (other nodes can propagate messages forward, TimeoutNotification for example).
Am I right to believe that MQMD.SourceQueue is only set, ie. will not be "" or null if the flow was driven from an MQInput node? I can't find anything in the docs.
Thanks in anticipation -
Cliff |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu May 24, 2012 1:00 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Connecting to a queue from a JCN is not recommended. Is it possible? Yes (temporarily).
There is a reason why its not recommended. If you handle a volume of transactions, the QMGR will eventually run out of available connection handles. Notice I said QMGR and not your local connection pool in your JCN.
If you must interact with MQ in your flow, you must do it through a combination of the provided WMB nodes and some logic from JCN or ESQL. Use MQGet node with Browse option to check for a message.
That being said, you can check the MQMD.MsgId parm to see if it is not null. If not null, it was derived from an MQInput node.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 24, 2012 1:19 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| Connecting to a queue from a JCN is not recommended. |
True, but that is entirely not what was asked about.
| lancelotlinc wrote: |
| That being said, you can check the MQMD.MsgId parm to see if it is not null. If not null, it was derived from an MQInput node. |
That's entirely not reliable.
There is, in fact, no reliable test to say "in the whole set of unknown nodes before this, the actual INPUT node used to start this flow was X".
The base product ensures that you have the full flexibility to abstract away all of the information about the source of the message.
So if you require that there is reliable information available, you must set and enforce site standards that specify how the information will be populated, where it will be populated and when it will be removed (likely never during the processing of a given message). |
|
| Back to top |
|
|
| Cliff |
| Posted: Thu May 24, 2012 1:54 pm Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
Gentlemen,
thanks for your very prompt replies! I take the point about the connection handles but stress that this is exception processing, so should not experience high volumes.
Perhaps I should also have said that this will be part of a subflow wired to catch terminals of 'starting nodes' of flows, and will indeed be part of site standards.
The integration patterns at my client are a lot of msg in, msg out but now with increasing use of Soap nodes to talk to cloud apps and also to expose some flows as web services. And we have some aggregation, fanning out to Soap Request nodes wrapped in MQ. These patterns look to continue, it's fairly early days in web service land and we're learning some stuff the hard way .... <sigh>. And so are the web service providers, it would seem <even bigger sigh>.
So, looks like my theory should work so long as the MQMD (if there is one) that is propagated to the catch terminal is the reinstated one or the one at the point of failure. It's been an extremely long day, 15 hrs now, and I simply can't remember!
And if there was an easier way to get the backout threshold dynamically I'd use it, but I can't find one.
Thanks again and I'd be glad to hear any further thoughts.
Regards,
Cliff |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu May 24, 2012 9:50 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Designing and exception handling system should IDEALLY encompass the complete flow environment and not just something that can be bolted on afterwards.
If you are dealing with multiple input types (MQ, TCP/IP, HTTP, SOAP etc) then you need to make sure that the flow is designed so that when and exception happens the exception handler already has all the data it needs to do its work.
That may mean adding a compute (or JCN if that is your bent) just after the InputNode to add something to the Environment that tells the exceptionhandler information about the input message that may get lost/discarded during processing.
If you do that then handling exceptions becomes a whole lot easier.
One simple way to implement this is to have a Subflow for each input type that you import into your project. This has the code needed to setup the data for the Exception handler. Import the subflow, change the input Node properties to suit the flow and then import the subflow onto your main flow.
It can also have the advantage of automatically connecting up your fantastically engineered exception handler without the flow coder having to remember to do it.
Time spent sorting this out at the start of a project is time saved later on. Sadly, all too many sites think about this stuff far too late in the game and bolting on a proper error/exception handler is not always easy.
Good Luck
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Cliff |
| Posted: Fri May 25, 2012 3:43 am Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
Yes I quite agree with you. I've been doing this stuff for 10+ years (but not that long on this site!) so I've seen plenty of things.
We do use the Environment for all data that may help in diagnostics, and dump that to an Exception message (that's the way they like to do it here). And I've banged on and on about the need to give someone the time and budget to develop this stuff properly - going from POC to production builds is NOT the way to do it, so there's a degree of retrofitting that I have to deal with. We all work within certain parameters and try to do the best we can under those circumstances. I'd love a green field but am unlikely to ever get one!
So thanks again to all for your contributions. Best regards,
Cliff |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
