nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

External Task Failure | Email notification on timeout | best approach

vijetha

We have a requirement to handle the external task failure scenarios in workflow. If any external task fails, then email notification should be send to admin after a particular time period. This need be implemented for all external tasks in the workflow.

I can think of using the dummy task. Has any one done this kind of implementation, if yes please let us know the best approach. Any ideas on this would be helpful and appreciated. We are using TS6.7.1 on Solaris.

Thanks in advance

Find more posts tagged with

Comments

Adam Stoller

We have a requirement to handle the external task failure scenarios in workflow. If any external task fails, then email notification should be send to admin after a particular time period. This need be implemented for all external tasks in the workflow.

I can think of using the dummy task. Has any one done this kind of implementation, if yes please let us know the best approach. Any ideas on this would be helpful and appreciated. We are using TS6.7.1 on Solaris.

Thanks in advance

I've done it many times, as has Nipper and I'm sure several other folks here. I don't believe you want a dummytask anywhere in this process though.
I create timeout handlers with one, possibly two, externaltask(s)
I create error handlers with two externaltasks surrounding a single grouptask
I utilize job variables for maintaining state information.

If you want more details - you would need to hire me for a contract :-)

Faizi

We have a requirement to handle the external task failure scenarios in workflow. If any external task fails, then email notification should be send to admin after a particular time period. This need be implemented for all external tasks in the workflow.

I can think of using the dummy task. Has any one done this kind of implementation, if yes please let us know the best approach. Any ideas on this would be helpful and appreciated. We are using TS6.7.1 on Solaris.

Thanks in advance

You did not mention that your are asking in terms of WFT or WFM concern?

vpatel

You can probably have two transitions coming out of your external task:
1. success: if your external task ran successfully -- this could be the logical next task in your process.
2. failure: if your external task failed -- this could be the email notification task that you want to notify people of the the failed external task.

In your external task code (assuming it is in Java -- for that matter Perl or anything else) you could do something like what I have outlined below. Normally what I like to do is have a single "error handling" task for all external/URL tasks. I just pass appropriate task failure information/parameters to this "error handling" task and based on that it'll figure out how to handle the error and what is the appropriate transition.

Here is a sample of one way to do this:

try{
/* controlled errors */
if (someValue == null){
task.chooseTransition(FAILURE_TRANSITION, "External task failed - someValue is null");
}
/* no errors and everything went well */
task.chooseTransition(SUCCESS_TRANSITION, "External task completed!");
}
catch(SomeException exception){
task.chooseTransition(FAILURE_TRANSITION, "External task failed - encountered some exception");
}

nipper

You can probably have two transitions coming out of your external task:
1. success: if your external task ran successfully -- this could be the logical next task in your process.
2. failure: if your external task failed -- this could be the email notification task that you want to notify people of the the failed external task.

You want a third task, being a timeout task. Failure is great when the task completes and said it did not work. However when a task doesn't even start or crashes in the middle, it hangs. Thus the timeout task.

You should have timeouts for every external (automated) task, email, CGI, deployments, everything. Even the email to the admin (which should just transition to the admin fix task). I use 1 hour for deployments and generate content tasks, 10 minutes for other Perl task and 1 minute for mail.

nipper

I've done it many times, as has Nipper and I'm sure several other folks here. I don't believe you want a dummytask anywhere in this process though.
I create timeout handlers with one, possibly two, externaltask(s)
I create error handlers with two externaltasks surrounding a single grouptask
I utilize job variables for maintaining state information.

If you want more details - you would need to hire me for a contract :-)

Ha. He (or his boss) probably saw my GearUp presentation. So he should be hiring me. :-)

Definately no dummy task is required, all timeouts and errors go to an email admin task, which goes (along with a timeout) to admin fix. The admin fix tasks is a user or group task that can go back to any task (or cancel).

vijetha

Thanks for all your input. As nipper mentioned, we can handle the task, if the task fails and said it didn’t work. Our requirement is to handle the task which crashes in the middle and it hangs.

My understanding from reply is that there will be timeout logic in the external scripts itself and it calls the admin email task after it reaches a particular timeout period, which goes to admin fix. Please correct me if I am wrong.

We are using the WFM for workflow implementation.

Thanks

Adam Stoller

Thanks for all your input. As nipper mentioned, we can handle the task, if the task fails and said it didn’t work. Our requirement is to handle the task which crashes in the middle and it hangs.

My understanding from reply is that there will be timeout logic in the external scripts itself and it calls the admin email task after it reaches a particular timeout period, which goes to admin fix. Please correct me if I am wrong.

We are using the WFM for workflow implementation.

Thanks

You're partially right - the timeout handling is not in the external scripts - it's in the workflow itself. Read the workflow documentation (both the Developer's Guide and the WFM manual) - and search for the word "timeout".

Also - search this forum for threads dealing with "timeout".

nipper

Our requirement is to handle the task which crashes in the middle and it hangs.

Read about the timeout link in WFM, it will do exactly what you want it to do