Author |
Message
|
Der11 |
Posted: Mon Mar 25, 2013 5:36 am Post subject: Retry using intermediate Results action |
|
|
Newbie
Joined: 25 Mar 2013 Posts: 7
|
Hi,
I am working on a requirement which needs the WSP to retry the same Backend URL n times (in case of no response) before invoking the error rule.
I tried to achieve that by using an intermediate Results action by putting a context variable as Destination. The context variable contains the dynamic backend URL.
The issue is that i am getting a 0x00c3000f (Invalid URL error),instead of getting a Failed to Establish a back side connection error after trying the above configuration.
Please share your valuable suggestions/thoughts on what should be the correct way.
Regards,
Simmer |
|
Back to top |
|
 |
rekarm01 |
Posted: Mon Mar 25, 2013 11:58 pm Post subject: Re: Retry using intermediate Results action |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
Double-posting here (and quintuple-posting on the IBM developerWorks DataPower forum) won't provide a quicker solution; it's more likely to have the opposite effect.
Der11 wrote: |
Did you got any solution for this.
Please reply |
Please explain how the suggested solutions already offered here or here were inadequate. Another option is to let the DataPower object (mpgw, wsp, etc.) error out, and have the caller examine the returned event code, and retry as needed.
Der11 wrote: |
I am ... using an intermediate Results action by putting a context variable as Destination. The context variable contains the dynamic backend URL. The issue is that i am getting a 0x00c3000f (Invalid URL error) ... |
The DataPower web-gui interface explains the event codes in more detail:
Quote: |
Event Code 0x00c3000f - Invalid URL
The configured URL is not well-formed and cannot be opened. Verify the configuration. |
Please provide more detail for the configuration of the request rule and results action. What does the context variable actually contain? |
|
Back to top |
|
 |
Der11 |
Posted: Tue Mar 26, 2013 12:40 am Post subject: |
|
|
Newbie
Joined: 25 Mar 2013 Posts: 7
|
Hi,
Thanks for replying and your expert advice. I will not repeat this in future.
Context variable contains the the BACKEND url , which i am building dynamically according to the request.
This context variable is assigned to Destination in the intermediate result action for 4 retries in a fixed interval of time followed by another result action
Then i need to process the response and send back to the client.
And i need to retry only in case of backend failure.
And if chck for the returning codes it wouldnot be a retry after fixed interval of time.
I am getting a 0x00c3000f error with the above retry logic and connection error (certificate mistmach) after removing retry logic.
Please share your valuable thoughts and sorry for double posting |
|
Back to top |
|
 |
rekarm01 |
Posted: Wed Mar 27, 2013 12:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
Der11 wrote: |
Context variable contains the the BACKEND url , which i am building dynamically according to the request. ... This context variable is assigned to Destination in the intermediate result action ... |
"More detail" means actual data. What are the literal values assigned to the intermediate result action fields, particularly for the Destination field, and what is the literal value assigned to the context variable prior to executing the result action?
Der11 wrote: |
... followed by another result action |
And what are the literal values assigned to the fields in this result action? If the previous result action already sends a request to the backend and gets a response, then what is this one for?
It may help to enable the probe for the DataPower object and turn on debug level logging, to compare what the object is meant to do with what it's actually doing. |
|
Back to top |
|
 |
Der11 |
Posted: Mon Apr 01, 2013 11:16 pm Post subject: |
|
|
Newbie
Joined: 25 Mar 2013 Posts: 7
|
Hi,
Sorry for replying late, was just stucked in some other issue.
I tried an intermediate result action as it was mentioned in one of the solutions in IBM developer works.
Current flow is :
Dynamic HTTPs backend
Match Action -> Transform (which does some validations, transformations, generates the URL dynamically and populating a context variable) -> Results(populating the Destination with the Context variable containing URL and setting no of retries).
But getting error connecting to url in the return response message ()
and i want to process the response after that.. will do that in request rule only by skipping the backend url and send back the response. is it the correct way.
Please help me out. And please correct me if i am doing any thing wrong.
I really need your expertise and will not repost the same thing any where else as u suggested. |
|
Back to top |
|
 |
Der11 |
Posted: Mon Apr 01, 2013 11:19 pm Post subject: |
|
|
Newbie
Joined: 25 Mar 2013 Posts: 7
|
missed a point -
URL is working fine with without retry logic being implemented.
I just need to do 5 retries at the interval of 30 sec in case of backend failure and not in case of a soap fault |
|
Back to top |
|
 |
rekarm01 |
Posted: Wed Apr 03, 2013 1:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
Much of this is already covered in the other developerworks thread.
Der11 wrote: |
Current flow is :
Dynamic HTTPs backend
Match Action -> Transform (which does some validations, transformations, generates the URL dynamically and populating a context variable) -> Results(populating the Destination with the Context variable containing URL and setting no of retries). |
Use the probe and debug-level logging to verify that the input context contains the request message, the destination context contains the desired url, and the output context contains the response message.
Der11 wrote: |
But getting error connecting to url in the return response message () |
Does the probe or log provide additional information? Does the error always occur, or just for specific scenarios? The destination and output don't really serve the same purpose, and may not generate the same error message for the same type of error.
Der11 wrote: |
and i want to process the response after that.. will do that in request rule only by skipping the backend url and send back the response. is it the correct way. |
As explained in the other thread, a loop back firewall is more suitable for the backend, in order to process the response after that.
Der11 wrote: |
I really need your expertise and will not repost the same thing any where else as u suggested. |
The suggestion was not to duplicate posts in the same forum. Feel free to post in the other forum -- there are a lot more DataPower experts there.
Der11 wrote: |
I just need to do 5 retries at the interval of 30 sec in case of backend failure and not in case of a soap fault |
As explained in the other thread, the results action may have its own criteria for deciding when to retry and when not to, and that doesn't seem to be configurable, so this approach may not be suitable at all. It may be easier to implement the retry logic in a separate artifact that calls the WSP.
For other, probably better suggestions, open a PMR. |
|
Back to top |
|
 |
Der11 |
Posted: Wed Apr 03, 2013 12:55 pm Post subject: |
|
|
Newbie
Joined: 25 Mar 2013 Posts: 7
|
Thanks for replying.
Issue was with my backend service.That is resolved.
I already tried that solution that is mentioned in IBM link.
The issue is that it is going for a retry, even in the case of a fault from the service.
Please share your thoughts and please correct me if i am wrong any where |
|
Back to top |
|
 |
Der11 |
Posted: Wed Apr 03, 2013 1:17 pm Post subject: |
|
|
Newbie
Joined: 25 Mar 2013 Posts: 7
|
Backend people are ok if go for a retry in any fault case. but i just wanted to improve my functionality.
And if you have time please look into below ibm url which needs help regarding one more severe issue https://www.ibm.com/developerworks/forums/thread.jspa?threadID=484380
Actually I am looking into two different projects (so dont think I am reposting).
Just wanrted you to have a look.
Any help in this regard would be great. |
|
Back to top |
|
 |
|