Aegis Workflow 101 – Error Handling!

Aegis Workflow 101 – Error Handling!

Welcome to Part 7 of Aegis Workflow 101.  Error Handling in workflows allows workflows to recover from an error in an activity and to complete a workitem in a controlled manner.

First of all - What is an Activity Error?  Activity errors have 2 classifications - errors which are handled inside the activity and produce a normal output with a success code, or an error handled (or possibly not handled)  inside the activity and passing the error onto the workflow with a failure code.  Almost all of the time this is a decision made by the designer of the activity. Let's look at an example to illustrate this:

An SQL activity connects to a database and runs a query and returns the count of rows affected.

Now - What happens if the SQL activity cannot connect to the SQL server?  If the activity developer handled the error in the activity, and outputted 0 (zero) to indicate no rows affected, would that be considered the correct thing to do?  That would simply hide the error.  Not being able to connect to the server is really an unexpected error - so we would expect that the activity would fail and generate an error with some indication of what the problem was so we can make a decision in the workflow what to do next.  So each activity can generate a number of distinct error messages depending on the cause - so you might get a "connection error", "login error", "timeout" etc. depending on the condition found in the code, and lastly there is often a "general error" left for any other conditions.

On the other hand, if we had an activity called 'test SQL connection', in this case we would expect the activity to return a false output when an error occurs trying to connect to the SQL server rather than generating an error.

We are only concerned with activities which generate an error here.  The activity 'Capture Workflow Errors' is used to handle any errors in the workflow generated by activities, I refer to it as the error handler activity.  Without an error handler, when an activity generates an error that flow stops.  If other flows are running in parallel in the workflow they will continue to run and depending on the workflow logic may make it to the end of workflow successfully.  However when an unhandled activity error occurs (no error handler) the workitem will always end with a State of Error.


In this example I have forced an error in the 'Execute SQL Statement' activity.  In Parallel I run a delay activity which continues to run and goes to the end of workflow.  The state though as you can see is 'Error' because the Execute SQL Statement error was unhandled.


Examining the activity Itself I see I got an error : Failure to connect to the database

This is correct - I forced the error by trying to connect to an SQL Server which in powered down.  In real life this could be a network problem, server maintenance etc.

So now lets handle this error so the workflow can continue.  We add a 'Capture Workflow Errors' activity to the workflow.


When you add the activity you will see the Error Type is [All Error Types] and Activity Name is [All Activities].   This means the activity will handle all activity errors from all activities - a 'catch all' configuration.  Remove this type from the list and click on 'Add' and you get a list of available activities in the workflow.


By selecting 'Execute SQL Statement' now this handler will only handle errors from the 'Execute SQL Statement' activity.  So its a bit more granular.  But we may want to be really specific - like to only handle the case of a connection error and not when there is a problem with the SQL statement attempted to be run.

To do this expand the 'Execute SQL Statement' to view the available errors for the activity.  We want to pick the error corresponding to the error we saw above : Failure to connect to the database.


You will be presented with a long list of possible error conditions.  The majority will be errors available to most activities but a subset will be specific to the activity itself.  So for example any activity could return : 'Activity library {library} not found'.  Anything in {} is going to substituted in at runtime.

Now we have a very specific error handler that will only handle the connection error on that specific activity.  Once the activity is configured you use connectors as normal to create a flow exiting the activity.  You cannot connect any connector into the activity.


With the addition of the error handler, now the workflow will end in a state of 'completed' and not 'error'.  But it looks like we are just hiding the error here - well in this case we are but we will look more at this shortly.  Firstly we need to understand the hierarchy of error handlers first.

This is the same workflow with some more error handlers added :


Now I have 3 error handlers.  The original to specifically handle a specific error (or could be errors) on a specific activity, a second which captures all errors from the specific activity and a third which captures all events from everything.  So which will actually capture an error when it occurs, or will all 3, since each error handler matches the criteria?  The answer only one handler will capture the error, and it is the most specific error handler which will do it.  So in this case it is the original error handler.  If an error occurred on the 'Pause' activity then it will be handled by the 'Capture ALL' activity.  Finally the case where two or more error handlers of the same configuration is added - then which handles it?  Again only one.  To avoid any guesswork do not duplicate error handlers!

So now we know how to capture errors - but what is the point?  There are two main categories of error handing in workflows - Passive Error Handlers and Active Error Handlers.

Passive Error Handlers are handlers which usually record or notify of an error occurrence and typically go to the end of workflow.  It is passive because it doesn't really do anything to help the automation continue.  An example is using the template ' Empty workflow with error handling' when creating a process.


There are two error handlers in it.  The first is a 'Catch All' 'Capture Workflow Errors' activity which captures anything in the workflow and the second is an error handler in case something goes wrong in the error handling part - like failing to send the email for example.

Active Error Handling is a much more progressive type of error handling.  If we cannot connect to the SQL Server, what could be wrong?  Is the Server contactable?  Is Server under maintenance?  You can think of active error handling as mini processes.  You can handle the error, ping the server, check the server maintenance state etc. , wait and try again, identify a problem and fix the problem or notify the correct team of what the problem is.  Its called active because you provide the workflow logic to actively try and progress the workflow even-though you've hit an error of some description.  Error handling logic once complete can re join the main workflow at any point, so it can retry part, skip part etc. as the scenario dictates.

Real value can be gotten from a workflow which uses active error handling compared to those which don't.  When you use active error you are less likely to think "oh that Aegis workflow failed again last night" and rather "the Aegis workflow resolved an connectivity issue to our SQL databases... while we slept".   Always remember the workflow is only ever as smart as the workflow developer who built it.

Error handling logic though can bloat a workflow.  Normally error handling is an after thought (unfortunately) so it can be a pain trying to squeeze in error handling after the fact.  However there is an easy enough way around this.  I typically build workflows which are of a page width when viewed on standard widescreen.  This way to follow a workflow I just need to scroll up and down to follow the workflow.  It also allows me to put the error handling over to the right hand size so if an error occurs I scroll over to the right hand side to follow error handling logic.  If error handling logic is large or re-usable often I'll call a child process to handle it and when complete return to the main flow.

One thing to watch out for - you can generate endless loops with error handling.  Redirecting an error handler back into a failed activity to retry could end up with endless error- catch loop!


Next up is: Aegis Workflow 101 – Debug Mode


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2016-05-03 19:56
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.