| Author |
Message
|
| zz348 |
 Posted: Mon Jun 04, 2012 11:34 am Post subject: Independent retry routes in Message Broker |
 |
|
Newbie
Joined: 04 Jun 2012
Posts: 8
|
We have a need to create a flow based on an MQInput node that routes and transforms the message to two independent recipients. The goal is to not have an all or none transaction. The goal is to allow either route within the flow to commit/rollback/retry independently of the other route/destination.
One idea for how to address this was "split this flow into 3 flows where the receiving flow would take the incoming message and manipulate it to the last point where the message is the same for the two recipients. This is the point where I would send the message to the other 2 flows and let design error handling in those flows to handle what ever problems may arise." But this approach would tightly couple the success of the MQ puts to the two recipients and force either all or none transactioning on the puts (artifical dependency), or if independent puts were configured at MQOutput node properties level, cause dupe message to be sent to one or the other recipient in case of rollback and retry of the failed put.
What is the best practice for saving state in the input message assembly to indicate which of the routes failed on previous pass, so that we don't send a dupe message to the route that succeeded when the message is backed out to the input queue and then retried? Is the best practice to save the state in a new or reused RFH2 header? Or is there a way to use MQ or MQMD properties to save the state? Or would we need to add a new element to the actual xml defining the incoming message in order for the failure state to survive the rollback to the input queue? Thanks very much. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Jun 04, 2012 11:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
First thing. with MQv7, do not think about an MQRFH2. Think about Message Properties.
Even though Broker only lets you specify message properties using the obsolete MQRFH2, you still need to think about message properties and not an mqrfh2.
Secondly you can consider pub/sub. This would allow you to create an administrative subscription that pointed to the two destinations. Then the routing flow sends ONE message, and the pub/sub engine is responsible for ensuring that each flow receives a single copy of each message.
Thirdly you need to consider how many error conditions really can exist between an MQOutput node in a flow and the Broker's queue manager. I.e. under what conditions is it even *possible* that one PUT will fail and the other succeed? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jun 04, 2012 11:58 am Post subject: Re: Independent retry routes in Message Broker |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| zz348 wrote: |
| What is the best practice for saving state |
An Enterprise Service Bus is a stateless object by design. The best practice, yea, the only practice, is not to save state.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 04, 2012 12:00 pm Post subject: Re: Independent retry routes in Message Broker |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| zz348 wrote: |
| What is the best practice for saving state |
An Enterprise Service Bus is a stateless object by design. The best practice, yea, the only practice, is not to save state. |
Indeed. it's not clear he or she is building an ESB, rather than just using Broker, however. |
|
| Back to top |
|
|
| zz348 |
| Posted: Mon Jun 04, 2012 12:11 pm Post subject: |
|
|
Newbie
Joined: 04 Jun 2012
Posts: 8
|
Thanks very much MQJeff. All three of your points sound like really sound advice! On the third point, I guess one way a queue put could fail for the one recipient but not the other is if that recipient were down and the queue wasn't sized properly and filled up.
Everyone else, thanks and I'm just trying to save state for messages being recycled back to input queue or eventually backout/recycle queue to avoid sending dupe messages to any flow routes that succeeded in previous retries. MB has concept of "Enviroment" and "LocalEnvironment" within a flow, but those state caches disappear once the message is rolled back to the input or backout/recycle queue. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jun 04, 2012 12:16 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| zz348 wrote: |
| MB has concept of "Enviroment" and "LocalEnvironment" within a flow, but those [storage areas] disappear once the message is rolled back to the input or backout/recycle queue. |
And with good reason. KISS.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 04, 2012 12:17 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zz348 wrote: |
| I guess one way a queue put could fail for the one recipient but not the other is if that recipient were down and the queue wasn't sized properly and filled up. |
yeah, but presumably even if the queue were sized wrong, you're still monitoring it, at least in production, and so you'd get notified that it was getting full... I.e. you'd be able to take corrective action to alleviate the outage for the other side before it got too bad.
In general, you can't save state in the input message. You can only save state using something 'external', i.e. the cache node, a database, an *output* message, an ESQL shared variable, a java static variable or etc. etc. etc. |
|
| Back to top |
|
|
| zz348 |
| Posted: Mon Jun 04, 2012 12:24 pm Post subject: |
|
|
Newbie
Joined: 04 Jun 2012
Posts: 8
|
| This is all great advice. Thanks a ton MQJeff and LancelotLinc |
|
| Back to top |
|
|
|
|
