Retry of a process step

, ,
1

I have this basic question. How can I make a process step to be retried?
I have set the Retry Count for the flow step to a value > 1. I modified the generated flow step to do EXIT and signal FAILURE. Still the PRT does not retry my step. It just fails and follows the ERROR transition.
Am I missing something? How can I make the PRT follow the Retries Exceeded transition?
I am on 6.1.
TIA

2

I dont think, that there is a mechanism to automatically retry a process step - but you could use a REPEAT and set the “repeat-on” parameter to “FAILURE” - then you could set the “backoff” parameter to have a defined pause between your retries. The “count” Parameter limits the retries for a specified number (keep in mind, that the first run does not count as a retry)

RST

3

See retrycount param in process step properties.

4

I’ve only played with this a little so someone jump in here. But doesn’t the process step suffer the same problem as a normal flow which is if you are in a try/catch it consider the service to have executed successfully regardless of the outcome. So the retry condition never gets executed. Seems like taking it out of the try catch corrected the problem. Not sure on this though, its being a while.

5

Krishna,
If you read my post you would see that I already tried that and it does not work.
Mark, when you do catch and then do EXIT with FAILURE I guess that the PRT should interpret this as failure and retry. Anyway I tried different things. Throwing exceptions, throwExceptionForRetry, etc. Still I could not make the PRT retry my step and I have the Retrycount set properly.

Any other thoughts?

TIA

6

The following pseudo code will produce the desired results.

TRY
…DO SOMETHING RISKY
CATCH
SET FAILURE_FLAG=TRUE
IF FAILURE_FLAG=TRUE THEN
throwExceptionForRetry
END

The key is the throw for retry outside of the catch block (also to have a retry count). We are running webMethods 6.1 and this works.

Best Regards,
Brian Dussault

7

Note: The IF FAILURE_FLAG=TRUE THEN … needs to be outside of the catch block.

8

Brian,
Is this solution you are describing working with Process Models? Or is it working generally with triggers, where you set the retry in the trigger properties?

I tried to use it in the flow generated by the Modeler and still could not make it work. I still don’t know how to use the Retry Count feature of the process model step.

Krishna, do you know how to make it work?

9

It is working with process model steps.

  1. On the target model step set the retry count property.
  2. Generate the model
  3. Update for monitoring
  4. In the flow service…
    4a. Create a sequence structure for a try/catch
    4b in the catch set a variable (isError=True)
    4c. Outside the catch block create a branch statement to evaluate isError variable
    4b. if isError true then call the service, throwExceptionForRetry

Note: You should be careful when throwing for retry service exceptions. typically this would be used for transisent failures only.
If you post your code I might be able to help…
-brian

10

Hello,

What do you mean by throwExceptionForRetry? Is this a built in service?

I also don’t understand your Note, do you mean that the retry count applies to failures in the transition from one step to another? I understood it could be used for failures in the step itself.

Thanks for your help

11

In webMethods 6.1 throwExceptionForRetry is a built in service. The note was just an advisory that throwing service exceptions will result in the same exception occuring until the max retry is reached. For example: If the service performs a divide by zero operation and will throw an error of type ServiceException. To catch and retry this type of exception is never advised. But if you have network connectivity outage (a transient failure), it makes sense to attempt to retry. The developer/modeler guide will better define a transient error vs. service error.

12

Hi all!

I was able to make the retry work but only in IS trigger/service, I mean not in context of a Process Model. I got even more information on how to write the service code from here [url=“http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?w=0&targChanId=knowledgebase&oid=1611547540”]http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?w=0&targChanId=knowledgebase&oid=1611547540[/url].

However now I want to have the retry working in the process model and I don’t know how to do it.

The questions I have are:

  • the throwExceptionForRetry should be thrown by the flow service generated by Modeler? Or by the service being invoked from the service generated by Modeler? Does it matter btw?
  • what is the relation between the Retry Count property set in Modeler for the step and the Max attempts property of the Trigger generated by Modeler?

Brian, have you made it work in the Process Model? If so, can you explain how?

TIA

13

Fenek,

  1. the throwExceptionForRetry should be thrown by the flow service generated by Modeler? Or by the service being invoked from the service
    generated by Modeler? Does it matter btw?
    Yes, it can be thrown from either the generated stub or the any flow service being called by the stub. Be sure that the generated code does not catch the error!

  2. what is the relation between the Retry Count property set in Modeler for the step and the Max attempts property of the Trigger generated by Modeler?
    The retry count in modeler is the number of times the step will be executed when a transient error occurs. When the retry count is exceeded you can use a retry exceeded transistion to do something.
    The max attempts applies to document delivery errors and not process model errors.

The only other thing I can think of is that on our models we have:
Volatile Tracking, Volatile Transistion documents, Express Pipeline, Optimize locally, and volatile global data all deselected.

Hope this helps.

14

Hi Brian,

Thanks for the suggestions. I tried deselecting the options and still it does not work.

Could you look at the model and the generated IS package below? What am I doing wrong?

In fact I created a very simple model just to demonstrate how I am doing things. I guess this is enough.

One of the things that is not clear to me is what happens when despite of the retries the problem persists? Which transition will the model follow, the RetriesExceeded or the Error?

Thanks for your help.

The Process Model
Retry.model (18.2 k)

The IS package
Retry.zip (8.2 k)

15

I left out one important part. There should be an error transistion from the fail step to another service which transistions back to the failed service. The “failed” service has a join type of complex with an “or” on the transistions.

See the attached gif for my screenshots.
-brian

screenshots
solution.zip (17.6 k)

16

Thanks a lot, Brian. I have tried this and made it work!

I also played around a little and this is what I noticed:

  • in the ToBeRetried step you don’t have to throwExceptionForRetry. It is enough to do EXIT from $flow and signal FAILURE. So the throExceptionForRetry is not mandatory for retry.
  • If the step that you transition on Error from ToBeRetried is not a Flow step but instead and an Empty step then the Process follows the Retries Exceeded transition (see the attached picture) and does not go to the general Error handling step. Do you have an idea why is that? I guess this has something to do with the fact that I have the green OK mark over Empty step and you had the red cross on the TransitionBack.

Thanks again for your help.

17

Actually, I think my transistionBack step didnt have it retrycount set correcttly. It was set to 1.

Best of luck,
brian

18

Hi Brian,

I spent even more time on the retry problem In fact you are right that your TransitionBack step should have the retry count set correctly. It was set to 1 and this was the reason why the process went to the process-wide Error step. For the second iteration of the TransitionBack step with retry count of 1 the process would normally follow Retries Exceeded transition. As there was no transition like that the process went to Error.

It was difficult to notice the problem because I had the retry count of ToBeRetried set to 2. And in fact the step was executed 2 times. But if I set the retry count to 3 the step would still be executed only 2 times because the TransitionBack would go to Error in the second iteration.

So one should set the retry count of the TransitionBack to the same value as the ToBeRetried retry count. In this situation the process would never go to the Error step but rather follow the Retries Exceeded transition. This would also mean that you need to specify the Retries Exceeded for the TransitionBack step because you need to do so for each step with retry count > 1.

Instead of doing all this I would recommend simply use Empty step instead of the Flow step as the TransitionBack step.

Thanks Brian again for your input. Now I have full understanding of how the things work.

19

Actually, you should be able to use Flow Step. After checking an existing project, I found that I set the retry count = 0 of the TransitionBack equivalent. Interesesting approach with the Empty Step, which seems to perform in the same manner (retry count =0).

Anyway… Good too see that you have it working.

-brian

20

I tried setting the count to 0 and even a negative value. Works exactly the same as the Empty step. I believe though that unless you have a good reason to put the TransitionBack as the Flow step it is just cleaner to use the Empty step.