Author |
Message
|
dilse |
Posted: Mon Jul 31, 2006 9:45 am Post subject: HTTP Retry in WMB |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Hello All,
I am using WMB6.0.0.1. I am trying to invoke a webService using a message flow. I am using HTTPRequest node for this. My message flow design is as follows:
MQInput->Compute->HTTPRequest->Compute->MQOutput
I am formatting the input(string(BLOB)) into SOAP before making a HTTPRequest to a webservice. I am formatting the response and converting it back to string(BLOB).
I know the design should be fine but if you have any suggestions please let me know.
I am thinking of making 3 tries before I decide that the Web Service failed. How can I achive this in WMB? Any input is appreciated.
Thanks in advance,
DilSe.. _________________ DilSe..
Take life as it comes.. |
|
Back to top |
|
 |
dilse |
Posted: Mon Jul 31, 2006 3:08 pm Post subject: |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Can anyone tell me if retry attempts is achievable??
Lot of people implemented Web Services. How did you handle when it fails for the first time apart from handling thru 'Failure' or 'Error' terminals? I am looking for a best design of this integration point. Any input is highly appreciated. _________________ DilSe..
Take life as it comes.. |
|
Back to top |
|
 |
vennela |
Posted: Mon Jul 31, 2006 3:11 pm Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
I don't know much MB, but can't you catch the error and send the message back to the initial MQInput Node. But this way, you will also have to take care of any poison messages also. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Jul 31, 2006 3:22 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
If you don't want to connect failure/error terminals, you can use a Try/Catch node, and have the Catch path handle your retries.
Or as vennela says, you can use the default error handling of the MQInput node and configure a backout queue, and the backout threshold. Then make sure that any errors propagate all the way back to the MQInput node, and either don't connec the Catch terminal there or add a Throw node to the end of the catch flow and Don't Connect the failure terminal of MQInput.
Or you can do other things to build an error handling loop.
We can't really give you best design with just the requirements you've given. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
dilse |
Posted: Mon Jul 31, 2006 3:45 pm Post subject: |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Thank you for your input.
Jeff,
I am planning to handle the exception/error using Failure and Error terminals but in that way I think I cannot exactly dictate the number retries I have to make even though if I send it to MQInput node as vennela said. I am planning to retry 3 times if it fails for the first time. Please share your thoughts. _________________ DilSe..
Take life as it comes.. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Jul 31, 2006 5:33 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Backout Count is your number of retries if you allow the exception to propagate back to your MQInput node.
Otherwise, you can use Environment to hold a counter, and then rethrow an error out of the error handling to let the exception propagate further back. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
dilse |
Posted: Tue Aug 01, 2006 9:59 am Post subject: |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Jeff, Thanks a lot for the info. I thought along the same lines for this issue but the only concern I see was what happens if another request come into the MQInput node while I am handling this failure message. . Will it stop until I am done with processing the failed message? Please share your thoughts.
Thanks in advance.. _________________ DilSe..
Take life as it comes.. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Aug 01, 2006 10:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Each request is going to start it's own copy of the flow - this is going to include requeues after backout. Each copy of the flow will have it's own copy of Environment. Each copy of the flow will have it's own backout count. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
dilse |
Posted: Tue Aug 01, 2006 10:09 am Post subject: |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Thanks for all the help in pointing in right direction. _________________ DilSe..
Take life as it comes.. |
|
Back to top |
|
 |
dilse |
Posted: Wed Aug 02, 2006 10:58 am Post subject: |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Jeff, I am trying to implement the error handler routine. Here is my design
for the error handler subflow to retry.
Input -> Filter node(to check the value of backoutcount) -> compute node(to copy the Properties, MQMD, XML from the Environment tree where I stored these earlier into OutputRoot to place this message back to MQInput queue) -> MQOutput(which is MQinput for the main message flow)
I am setting a a variable in the Environment tree to track the BackoutCount but whenever I am placing the message back to MQINput queue from Error routine, it is resetting the whole Environment tree and I am losing track of BacoutCoutn at this point. Please point me in the right direction.
Thanks in advanvce, _________________ DilSe..
Take life as it comes.. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Aug 02, 2006 11:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
backout count is updated on the message itself.
If you're going to use backout count, you don't need to handle this yourself.
You need to set properties on the queue being read, however. These are the Backout Requeue Name, and the Backout Threshold. The second is what gets compared against the backout count of the message.
You also need to make sure you throw exceptions back to the MQInput node. Then the MQ Input node will put the message to the Backout Requeue Queue after the backout count exceeds the Backout Threshold. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
dilse |
Posted: Wed Aug 02, 2006 3:17 pm Post subject: |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Thanks Jeff. I found a way out.
When I recieve a failure after HTTPRequest I am setting Environment variable to keep track of retry count and sending entire message back to HTTPRequest node except exception list tree to retry. When I see the count as three I decide to notify the WebService application regarding the failure.
Thanks for your suggestions. _________________ DilSe..
Take life as it comes.. |
|
Back to top |
|
 |
dilse |
Posted: Tue Aug 22, 2006 11:09 am Post subject: |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Jeff,
I have one last question..
What happens when one http request is in processing and another request comes into the input queue? Will it stay in the queue tilll the first request processing finishes or will it make another thread to process the second flow?
Please share your thoughts.
Dilse.. _________________ DilSe..
Take life as it comes.. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Aug 22, 2006 11:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Each message flow runs in one thread, plus one thread for each additional instance you configure.
So if you only deploy the message flow once, to one execution group, and you configure the additional instances to 0, then you will single-thread your processing. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
ydsk |
Posted: Tue Aug 22, 2006 11:47 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005 Posts: 410
|
To better understand dilse's question, when a msgflow calls a webservice using a HTTPRequest node and the call times out ... does the message go to the Failure terminal of the HTTPRequest node ? Or does it go to its Error terminal.
Jeff or someone, pls clarify.
Thanks. |
|
Back to top |
|
 |
|