Topic
  • 8 replies
  • Latest Post - ‏2013-05-21T19:59:00Z by chandrax
svolkers
svolkers
47 Posts

Pinned topic Failed response from backend web service call.

‏2007-11-13T17:53:09Z |
My gateway invokes a web service. If the web service fails to return a result I would like to do at least one of two things if not both.
1. Resubmit
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.

Thanks,
Scott
Updated on 2007-11-28T17:18:29Z at 2007-11-28T17:18:29Z by Workflow
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Failed response from backend web service call.

    ‏2007-11-13T23:58:53Z  
    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.
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Failed response from backend web service call.

    ‏2007-11-14T14:46:22Z  
    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
    SangaS
    70 Posts

    Re: Failed response from backend web service call.

    ‏2007-11-14T15:02:15Z  
    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.

    Regards,
    Suresh Sanga
  • svolkers
    svolkers
    47 Posts

    Re: Failed response from backend web service call.

    ‏2007-11-14T20:39:23Z  
    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.
    Thanks Andy,

    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.
  • svolkers
    svolkers
    47 Posts

    Re: Failed response from backend web service call.

    ‏2007-11-14T20:43:31Z  
    • SangaS
    • ‏2007-11-14T15:02:15Z
    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.

    Regards,
    Suresh Sanga
    Suresh,

    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.

    Regards,
    Scott
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Failed response from backend web service call.

    ‏2007-11-15T15:38:26Z  
    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.

    Corey
  • Workflow
    Workflow
    4 Posts

    Re: Failed response from backend web service call.

    ‏2007-11-28T17:18:29Z  
    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.

    Corey
    As we are getting 0x01130006 error for time out, is this error code unique in terms of the error nature. For example shall I write the xsl to throw the error "timed out" when we get the error code "0x0113006" for auditing purpose?

    or this error code also usied for different scenarios. How the DP works?

    I appriciate your help.
  • chandrax
    chandrax
    7 Posts

    Re: Failed response from backend web service call.

    ‏2013-05-21T19:59:00Z  
    • Workflow
    • ‏2007-11-28T17:18:29Z
    As we are getting 0x01130006 error for time out, is this error code unique in terms of the error nature. For example shall I write the xsl to throw the error "timed out" when we get the error code "0x0113006" for auditing purpose?

    or this error code also usied for different scenarios. How the DP works?

    I appriciate your help.

    You might already have worked through your question.

    yes, 0x01130006 is DP specific generated event code and is specific to timeout,  along with others,

    http://publib.boulder.ibm.com/infocenter/wsdatap/4mt/index.jsp?topic=%2Fcom.ibm.dp.doc%2Fmessages03.htm

     

    we can use log targets/log category/log events to subscribe to these errors/events without having to write an xsl.