This question was answered by DrydenLong, on Wednesday, February 22, 20177:07 AM

Answer:

Hey Jacob,

I posted the original question about the error emails and since it's not possible, have been looking into something similar as you describe. What I'm testing now is using the OnStepError function to make a database entry using the AMError dataset, then having a seperate task parse that database and send notifications accordingly.

All of the information in the default error emails is in the AMError dataset, so you could turn off the default emails and rely solely on the error handling through the OnStepError function in order to keep it condensed.

The problem I am running into is that I have over 150+ workflows, so updating each task within those workflows will take some time, however for future tasks and the ones I have updated, this seems to be working as expected.

02/21/2017 01:48 PM

JacobNielsen Journeyman (50-99)
Posts: 84
Joined: 10/02/2015

Since it's not possible to create customized error emails (as was pointed out in an earlier post), we're working on making some error handling tasks that will classify certain tasks as Critical (highly time sensitive; drop everything and fix it now), Warning (needs to be looked at as soon as possible) or just information (something failed, but possibly because it was supposed to).

What we need is when the task fails, it passes to an error-handling task the step that failed and why. In essence, kind of like what the failure email sends, but it stores those messages in a variable that is then used in error-handling task.

For example, if a task fails on step 32 because a file can't be found, then variables are set with "Step 32" and "File doesn't exist" in the error-handling task, when then fires off an email with a subject line indicating the severity level.

Now, I know that the task will send an email with that failure information and we can follow it up with a second email sent from the error-handling task indicating that the task failed and what its severity level is; however, I'm looking to keep it condensed, if at all possible.

I posted the original question about the error emails and since it's not possible, have been looking into something similar as you describe. What I'm testing now is using the OnStepError function to make a database entry using the AMError dataset, then having a seperate task parse that database and send notifications accordingly.

All of the information in the default error emails is in the AMError dataset, so you could turn off the default emails and rely solely on the error handling through the OnStepError function in order to keep it condensed.

The problem I am running into is that I have over 150+ workflows, so updating each task within those workflows will take some time, however for future tasks and the ones I have updated, this seems to be working as expected.

I used OnStepError for a long time. What I did was take the parameters to OnStepError and insert all that info into a shared variable in a custom XML format that I defined. Something like:

Main

...

Then I could easily parse that using the built in XML functions in my error handling task. However, I had some trouble with the shared variable sometimes not retaining the error data (something I never opened a case on, but should have). Ultimately I decided to scrap this in favor of a better solution.

Now what I do is simply query the BPA database for error information. No need to capture the error using OnStepError. This has worked so much more reliably, and has the benefit of requiring no changes to your tasks. It also has the benefit of being able to handle non-task errors (evaluations/conditions/processes). I've attached the task that I use to do this. You'll need to modify your workflows to have items point at this task on a failure. You will also need to modify the task to point to your BPA database, and insert your email information. I did design this so you can modify who receives errors for each workflow. Just specify a shared variable called "WF_emailRecipient" and insert the recipient addresses in it.

I've made a number of changes since I last posted it:
1) The task will now report the entire "stack trace", which shows you the hierarchy of the calling workflow(s).
2) The email will now show the notes for every workflow in the "stack".
3) The email includes a link at the bottom to Insite (if you use it), which will show you the past history for the workflow.
4) The email will now report the failure rate - the percentage of failures over the past X runs - and change the email to high priority if the failure rate is above the threshold.

Here are the things you'll need to change in the task:
Step 1: The "SHARED_emailRecipient" variable can have a default value, and can be overridden by any calling workflow by specifying this shared variable.
Step 2: Change "emailSender" to the appropriate email address.
Step 11: Optional - This variable specifies the number of samples of this workflow to take to determine failure rate, the current value specified will sample the past 10 runs.
Step 12: Optional - This variable controls the threshold at which the email is changed to high priority. This is a percentage, so the current value will set the email to high priority if the sampled workflow runs failed more than 20% of the time.
Step 18: Change "insiteServer" to point to your HelpSystems Insite server name. If you don't use Insite, just leave this variable blank, and the URL will not appear in the email.
Step 19: Change "insiteServerId" to the ID Insite uses to reference this AutoMate server (is unique for every AutoMate product connection in Insite). An easy way to get this is to navigate to "Workflows" for that product connection, and then look at the number that occurs after "Workflows" in the URL (see in bold here): insite.example.com/HelpSystems/#AutoMate/Workflows/2/page/1/sort/name/dir/0
Step 22,23,41,43: Change the database connection info to point to your BPA database.

And then all you need to do is embed it in your workflow(s), and point a failure link from every task to this task.