Error Import

A workflow process can error for a number of reasons.  Most common errors include:

• SMTP Servers are unresponsive to outbound messages being set.
• Release related data errors (data types don't match, field lengths exceeded, no pages exist).
• Exceeding maximum performance capacity of server.

Workflows can leverage one or more Error Import nodes to create retry behaviors, or move documents to validation queues where admin level users can take action.

Settings

Workflow designers must provide a Title to add the node to a workflow.  Optionally, a Target Node Name may be specified.  When using multiple Error Import nodes in a single workflow, ALWAYS specify a Target Node Name for each node.  Designers should also consider the Frequency specified.  It may be unnecessary to check for errors at the default rate, and performing checks less frequently may improve overall system performance.

Sample Workflows

Example 1

In most cases, you will want to control the flow of processes in error.  Consider the following example workflow, which is built specifically to generate an error at Step 4 (Release) 100% of the time.

3 Process Fields are defined:

• Error Count - Used to keep track of how many time a process has failed.
• Page Count - Used in this example to create an error condition.  By deleting all pages of a document, attempts to release will generate an error condition.
• Description - A text field used to store information about the error condition.  It is presumed that at some point, a user may need to refer back to the history of the process when an error condition can not be resolved.

Documents enter the workflow from the standard green Import node (bottom left), where they flow through to release node.  Prior to doing so, this sample workflow will delete all pages from the process, which in turn will cause an error when the Release node attempts to output a file.

At bullet 1, the Error Import node will monitor for any error processes related to this workflow.  In the example, Error Import is only going to react to processes that failed at the release step.

At bullet 2, the Error Count is increased by one.  This value will be used to control how many times an error can be retried.

At bullet 3, the Error Count is checked.  If the error has happened less than 4 times, the Release Step will be attempted again (bullet 4).

At bullet 5, set a message to the description field.  At some point, it may be helpful to understand why this process exited the workflow process.

Customers looking to build off of this workflow to implement their own processes can download the sample outlined here from the Square 9 SDN.  In the Workflow Bootstrapping component section, select the Error Management workflow.

Example 2

In this example, 3 Error Import nodes are leveraged.  Each node is monitoring for processes in error from the node they target.  In this example, we are going to perform a perpetual retry any time an error occurs in sending an email (1), sending an email (2), or releasing to an Archive (3). 

Example 3

In a different variant of the same process, the desired process may be to queue any errors to an Admin level user for management.  In this example, only a single error import node is leveraged, and the Target Node Name in its settings is left blank.  All errors in this workflow will route to a specific validate node when a trained user can perform the necessary steps to correct any errors.