| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Reprocessing a message if the webservice is down??? |
« View previous topic :: View next topic » |
| Author |
Message
|
| chris boehnke |
 Posted: Tue Oct 02, 2007 4:50 am Post subject: Reprocessing a message if the webservice is down??? |
 |
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
Hi Guys,
I am working with MB V 6.0
I am calling a webservice by using httpRequest node in my message flow.
My messageflow looks like this:
MQInput->Compute node->HTTPRequest node->Compute node->MQOutput node.
I want to reprocess the message if the HTTP status code is other than 200, i.e. resend the message to the webservice and reprocess...
Here is the ESQL code what I am using in the Compute node just after the HTTPRequest node:
IF InputRoot."HTTPResponseHeader"."X-Original-HTTP-Status-Code" = '200' AND STATUSCODE = '1' THEN
IF RESULT = 'T' THEN
SET OutputRoot.XML = Environment.myMsg;
RETURN TRUE;
ELSE
RETURN FALSE;
END IF;
--RETURN TRUE;
ELSE
THROW USER EXCEPTION MESSAGE 2950 VALUES ('Invalid Webservice response:',Environment.myMsg );
RETURN FALSE;
END IF;
Here in the above code, myMsg is the original input message.
Please suggest whether I am going in the right direction. Let me know if you have any other way of achieving this.
Thanks much. |
|
| Back to top |
|
 |
| jsware |
| Posted: Tue Oct 02, 2007 1:41 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
This should roll-back any persistent messages/all messages if you have used trans = auto/yes on the input node. However, broker will then loop round and reprocess this message again without pausing for thought. Thus you will "hammer" on the web service door as it were.
I developed a flow using the SendMail plugin (essencially a "synchronous" protocol like web services - bear with me). If the SendMail plugin node failed, I constructed a message containing the original message and an error description and put this onto a "holding queue". The message was given an "short" expiry and a MQRO_EXPIRY_WTH_FULL_DATA report option and a reply-to q of my input queue.
Now when we successfully invoked SendMail, the flow then used the MQGet plugin (now part of MB6) to do a get matching a known-not-to-match-anything correlation ID to expire the messages on the hold queue back onto the input queue. It works quite well, but does rely on a stream of input messages unless you have an independent, timed "browse" of the old queue to expire messages in the absense of any new messages.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 02, 2007 1:51 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A couple of other options for doing this replay-with-delay is to use a backout queue, rather than an expiry hold-queue, and another flow triggered from a TimeoutNotification node and the MQGet to pull out messages from backout and resubmit to input.
Or use a TimeoutNotification on the mainflow, that's driven off a TimeoutControl node. The message passed to the TimeoutControl node will include the original message, and how long you want the message to be delayed for. Then the original message will be part of what comes out of the TimeoutNotification node.
These are more advanced techniques. Using a backout queue and a manual reprocess step is probably okay for a lot of cases.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
