Workflow and ServiceDesk Community

Hi All -

Question regarding Workflow's Critical Error model... I have some monitoring workflows that, on occasion, encounter one error or another thereby invoking the Critical Error model.  My question is, when this occurs, the monitoring workflow tries again and again to complete successfully, but instead, I would like for the workflow to retry only a few times (that I configure) and then stop retrying.  Any way to modify the Critical Error model to achieve this?

Any/all thoughts greatly appreciated.  Thanks, Tom

Using a global counter then end in the main model?

Try doing this in an exception path in the primary model:

Hook up the Exception Trigger By Component to the component that's failing and you want to retry. Set up the Number Range Rule to test a global counter variable against the number of times you want to retry (I use 3 retries above).

If the counter is less than a certain threshold, add 1 to the counter and use the Goto comp to go back to the problem component and retry. If it exceeds the number range threshold, end.

Any exception path you create in the primary model should trump the critical errors model. In fact, the Critical Errors model can be deleted if you want, and users can enter their own exception path in the primary model (if they wish).

Thanks Mistral and reecardo. I have a few more questions about this... by default the Critical Errors model ends with the 'Exception Component', what is the default behavior with respect to this component?  In other words, it seems like what happens is the scheduler tries to run the primary model of my monitoring workflow, then when it encounters an error, the Critical Errors model is invoked, the Exception Component is quickly reached... does the workflow just go back to the beginning of the Primary Model and start over again or does the workflow go back to the last component in the Primary Model that failed? 

Also, assuming the workflow is doing one of those two things and assuming the Primary Model keeps encountering an error every time it tries to run, by default will it just keep trying forever or will it eventually give up?

Last, to keep things very simple, if I didn't want the primary model workflow to retry, rather than end the Critical Errors model with the Exception Component, could I just end it with an End component?  If I did this it seems like the workflow would try to run the primay model, encounter an error, invoke the critical errors model (only once), then end itself.

What are your thoughts?  Any/all insights are greatly appreciated.  Tnx!  Tom

The Critical Errors model is meant to log unhandled errors. It will be invoked when any model has an error not handled by any exception triggers. By default, it runs to the end and stops. Your model will not run again in the current execution. So the following situation will not happen:

Also, assuming the workflow is doing one of those two things and assuming the Primary Model keeps encountering an error every time it tries to run, by default will it just keep trying forever or will it eventually give up?

So, if you don't want to do anything special when an error happens, besides just logging the error and ending, then you can count on the critical error model. Otherwise, its a best practice to add you own error handling in models as you go. People starting out with Workflow don't tend to think about error handling so this model was created so at least there is a record if something goes wrong.

Thanks rhamner -

I modified the Critical Errors model in my monitoring workflow project to finish on an 'End' component rather than an 'Exception Component' and now when this project runs as a scheduled job, if it encounters an error, it stops on the 'End' component and does not continue to re-run as part of the same execution.  The only time it tries to re-run is when the scheduler kicks off the next time.

Thanks for your insights.  Tom

Error handling by exception triggers components has one weekness. It is very easy to make a dead loop of the process when error has happen in exception service flow.

Could you consider a developing a dedicated embedded model component immune to errors during execution? I mean for instance its embedded model's run method execution could be handled by try..catch and component could have two outputs: succes and exception.

I know that can be done by protecting any vulnerable components by using specific exception trigger component but this is much more work and still a mistake easily can be done.

So...

Maybe not a bad idea would be an embedded component not only immune to exceptions during execution but also able to repeat its execution in case of failure a set number of times after in cycle/random time?

This is true. I've seen it happen before where errors downstream of a global exception are not handled and it gets into an infinite loop. Couple this with the fact that many workflows are designed to do long running procedures but ultimately the workflow runs as a web application. So, when it blows after the standard 3 minute timeout they bump up the request timeout. If you have a request timeout of an hour, for example, it will continue looping and using server resources until it times out. 

I think that's a great idea to simply have a model on the Exception Trigger component itself. In the meantime I think you could just always just do the work downstream of an Exception Trigger inside an embedded model that contains another Exception Trigger.This certainly does require more work, especially if you add the retry. However, one tip is that you can save component configurations. Set the component how you want it with logging and retry. Then right click and chose 'Save Component To Library'. Now, you can use the Library tab of the toolbox to bring this into any project.

Yes, I know this tip with saving components to library. But it is not so flexible as you wrote.
The saved components have to use a datatype and variables common to all processes where will be used.

The work-around by using Embedded Rule Model would be OK if... Embedded Rule Model was OK.
In our appliactions we have a pretty bad experience with Embedded Rule Model.
It can lost changes made in variables inside model. This usually happens when modyfied is a property
on lower level of complex structure.
I think the marking of changed root variables or the mapping of changed variables form embedded model to upper level model can have a fault.