Pinned topic Failed response from backend web service call.
2. Raise the error to a monitoring services, for example Tivoli snmp, logging, or email.
The policy allows for an Error rule to be defined. I can match on an error code to then determine whether to email or the course of action. The error codes I presume are one of two: x01330006 - Could not receive response; or x00c30015 - External URL timed out. I am not sure which is approriate. Please advise.
Also, can the message be resubitted as part of the process steam? If not, I can requeue.
Re: Failed response from backend web service call.2007-11-13T23:58:53ZThis is the accepted answer. This is the accepted answer.Hi Scott,
Check out "on-error" actions which are available in the "advanced" actions on a policy screen. You can configure an on-error action to run a different request rule which could be made to submit to a different back end (eg specifies a different "route-action").
Concerning 2, you can define specific or generic events using wildcards (eg x0133*) that can be funneled to any supported logging mechanism.
Re: Failed response from backend web service call.2007-11-14T14:46:22ZThis is the accepted answer. This is the accepted answer.Scott,
for the retry I would use a LBGroup that had the same endpoint 2 or 3 times in the list of endpoints. This way if the 1st request fails, it will try the exact same endpoint a 2nd or 3rd time depending upon how many time you put that end point in the list of endpoints for the LBGroup.
Then you can couple that with the on-error action like Steve suggests to accomplish your design goals.
SangaS 270000Q92674 Posts
Re: Failed response from backend web service call.2007-11-14T15:02:15ZThis is the accepted answer. This is the accepted answer.There is a trickiest way to capture the failed to establish backend connections.
Define request, response, error rule at the WSDL level. (click on Webservice configuration-> policy tab -> navigate to WSDL configuration, add 3 rules, 1. request, 2. response, 3. errorrule)
Configure Match action on the error rule with matching type "Errorcode" and errorcode to "0x01130006".
Use the transformation action to transform to required format (WS_SOAP_Fault.xsl attachment for coding the xsl).
Set results action output to "OUTPUT".
Let me know this helps.
Re: Failed response from backend web service call.2007-11-14T20:39:23ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
I an on-error. I was not sure if the re-route was the best method and I was not sure which error code to trap for. Steve's advice on the wild card for the error is a great tip. Did not know it would do that. As for the LBGroup (I presume the Load Balance Group), that sounds like it may be a good idea. I have more reading to do on that option. I had not set one up before, and the gateway is a multi-protocol gateway (Pull from MQ; call Web service; put back to MQ - all the while saving off original request and merging it with the response prior to putting back to MQ) I was not sure how Load balancing would work in such a situation.
I am standing up the identical service in a second box for redundancy and scaling. I confirmed in another thread this would be fine. Any overview or direction to a doc that would explain how the LBGroup would work in such situations would be helpful.
Re: Failed response from backend web service call.2007-11-14T20:43:31ZThis is the accepted answer. This is the accepted answer.
- SangaS 270000Q926
See my previos post on the gateway construction (Multi-protocol MQ-Web Service- Back to MQ). Are you suggesting I use a separate gateway and is your suggestion more related to capturing and adding error text? The logging is helpful to no if I failed, but I would like the gateway to retry, I am currently presuming period network error and/or backend web service failure. If I can retry, and succeed this is the best solution, as they can not live without a response. I have a datapower variable containing my original request which I inject into the response prior to posting back to MQ for the application.
Re: Failed response from backend web service call.2007-11-15T15:38:26ZThis is the accepted answer. This is the accepted answer.I feel compelled to weigh in here Scott. In my opinion, you are going down the wrong path in building a complex set of policies to support retry. Architecturally, SOA Appliances are designed to be a transparent gateway. They aren't really designed to perform long running transactional logic. I understand that a simple retry just scratches the surface of transactional logic, but it qualifies nonetheless.
I would rather see you build a policy that caught an error if the GW can't establish a connection to the back side queue and redirect that request to a retry queue where the same service or another service is listening with an MQ Front Side Handler as a retry service. This way you are not relying solely on the connectivity of one device or the in memory copy of the message on one device to service your retry logic. If you have a message hanging around in memory for a long time and the device loses power - you lose your message.
Anyway, the point is that you should always try to design policies that have a definitive outcome. Either the request/response completes successfully or the policy triggers an error that has some kind of definitive result (like send the message to a retry queue). The device should always send a message successfully to the next hop for persistence - or fail the transaction with an error to the initiator.
Workflow 110000BMGM4 Posts
Re: Failed response from backend web service call.2007-11-28T17:18:29ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
or this error code also usied for different scenarios. How the DP works?
I appriciate your help.
chandraX- 2700060HYV11 Posts
Re: Failed response from backend web service call.2013-05-21T19:59:00ZThis is the accepted answer. This is the accepted answer.
- Workflow 110000BMGM
You might already have worked through your question.
yes, 0x01130006 is DP specific generated event code and is specific to timeout, along with others,
we can use log targets/log category/log events to subscribe to these errors/events without having to write an xsl.