| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| WMB 7 Event generation for Output queues |
« View previous topic :: View next topic » |
| Author |
Message
|
| Vitor |
 Posted: Tue Sep 13, 2011 5:59 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sri wrote: |
| With WMB events, I dont see an option to capture the message event after the WMQ output nodes (without adding any nodes to the out terminal). |
You should, and this APAR seems to be the thing.
| sri wrote: |
| I want to capture the event only after the WMQ output nodes, since it will confirm that the message has been already delivered to the queue. |
Again I question the value of this - what is it telling you? If the target queue is not on the broker's queue manager all this is telling you is that it's been sent, not that it's been delivered to it's destination.
To achieve that, you need to use COD & COA messages. There are any number of discussions in here on that, as it's very easy to get into a tangle with those. The simple question remains - why don't you trust WMQ to deliver the messages? Why do you need a log?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Sep 13, 2011 6:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I see the value of having a log of a transaction being processed; not whether or not a message was inserted into a queue.
Your use of WMB events is not aligned to your business value. Vitor is correct on this point.
WMB events is not a performance impediment unless you have stringent latency requirements or high volumes. Meaning 100 ms latency or 10,000 TPS.
If you want to know whether or not the receiving application received the transmitted message, turn on COD at the WMQ level and construct a message flow to process those messages and log them.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 13, 2011 6:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| I see the value of having a log of a transaction being processed; not whether or not a message was inserted into a queue. |
And the log indicating if the transaction was processed successfully or not (which I'm sure is what you meant)
| lancelotlinc wrote: |
| If you want to know whether or not the receiving application received the transmitted message, turn on COD at the WMQ level and construct a message flow to process those messages and log them. |
Ensuring the design handles those situations where the COD turns up late or not at all.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sri |
| Posted: Tue Sep 13, 2011 6:31 am Post subject: |
|
|
Apprentice
Joined: 14 Mar 2004
Posts: 32
Location: Chennai - India
|
Hi Vitor and lancelotlinc
Currently we are capturing the logpoint/event of message delivery to each WMQ output nodes. This is because, we have 100s of message flows and some flows have 6 to 7 delivery queues (some of them are outside the flow transaction). Some time the messages are passed through multiple flows.
For support team these log points are verymuch useful to confirm the trace of the messages across the flows. We have the spreed sheet with expected log points for each interfaces. If there is an issue in the flow, it is easy for the support team to check the logpoints and confirm the list of queues to which the messages are already delivered/rolled back.
I am not realy looking for delivery confirmation from the end system. I am looking forward to capture the delivery of messages to the local queues and this is mainly for message tracing. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 13, 2011 6:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sri wrote: |
| If there is an issue in the flow, it is easy for the support team to check the logpoints and confirm the list of queues to which the messages are already delivered/rolled back |
I'd question the robustness of your error reporting there, but whatever works for you. 
| sri wrote: |
| I am not realy looking for delivery confirmation from the end system. I am looking forward to capture the delivery of messages to the local queues and this is mainly for message tracing. |
So if the requirement (which is what I originally asked about) if for a message to "ring the bell" as it goes through a given MQOutput node, then the out event from the MQOuput node (when you get it working with this APAR) is what you need.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 13, 2011 7:06 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Many commercial software implementations have a progress indicator service. Many times this is implemented as a Web Service (can also be implemented as an MDB). Basically, in particular places in your flow, you make a WS call to update your progress on a particular transaction.
WS calls:
1. I started a new transaction, step 1.
2. I completed step 1.
3. I am starting step 2.
4. I completed step 2.
5. I am starting step 3.
6. I completed step 3.
etc etc
The WS (or MDB listening on a queue if you prefer) records this information in a DB. Periodically, sys admins run a query on the DB to see what transactions completed successfully, and if any got stuck in a particular place in the work.
For example, if step 6 sends a confirmation email to the end user, and for some reason step 6 did not complete, the sys admins can rerun only step 6 for a particular transaction automatically. Our user interface into the adminstration of running these steps is a browser-based solution. It can even display the input msg and output msg at any point in the work (minus the pci fields).
This is a standard implementation of software architecture. In the Insurance industry, its called IAA. See http://www-903.ibm.com/kr/event/download/200804_337/s337_b02_1.pdf
The functionality is called "Activity Condition Place" in IAA vernacular.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| sri |
| Posted: Tue Sep 13, 2011 7:10 am Post subject: |
|
|
Apprentice
Joined: 14 Mar 2004
Posts: 32
Location: Chennai - India
|
Thanks a lot Vitor and lancelotlinc.
It was realy great chating with you both. Lot of information I have gathered.
Thanks a lot again for your quick responses and lot of information. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
