Fail Configuration

The FailConfiguration class specifies the actions to be taken when a step fails during process execution. It provides flexibility in defining how failures are handled, whether by retrying the step, initiating a fallback process, or simply marking the step as failed without further actions.

Field	Type	Description
action	StepErrorAction	Defines the action to perform when a step fails. Options are FAIL, RETRY, or NONE.
runRequest	ProcessRequest	Details of the process request to initiate a new process run if applicable.
runRequestAfterRetries	boolean	Indicates whether to execute the runRequest after all retry attempts have been exhausted.
retryInterval	long	The interval (in milliseconds) between retry attempts.
retryBackoffExponential	boolean	Determines if the retry interval should increase exponentially with each attempt.
retryCount	int	The number of retry attempts allowed after a failure occurs.

StepErrorAction Enum

The StepErrorAction enum defines the possible actions to take when a step encounters an error during execution.

Action	Description
FAIL	Marks the step as failed and stops the process execution.
RETRY	Attempts to retry the step based on the configured retry policies.
NONE	Takes no action, allowing the process to continue despite the error.

ProcessRequest

The ProcessRequest class encapsulates the details required to initiate a new process run. It includes metadata and input parameters necessary for executing the process.

Field	Type	Description
name	String	The name of the process to be executed.
namespace	String	The namespace under which the process is categorized.
version	Integer	The version number of the process definition.
id	String	A unique identifier for the process run.
correlationId	String	An identifier used to correlate related process runs or events.
input	Map<String, Object>	A map of input parameters provided to the process during initiation.

Fail Configuration Mechanism

The FailConfiguration determines how the system responds when a step fails. Depending on the action specified, the system can:

• FAIL: Immediately marks the step as failed, halting the entire process execution.
• RETRY: Attempts to re-execute the failed step based on the defined retry policies.
• NONE: Ignores the failure, allowing the process to continue without interruption.

Sample Configurations

Example 1: Fail Immediately on Error

Field	Value
action	FAIL
runRequest	null
runRequestAfterRetries	false
retryInterval	0
retryBackoffExponential	false
retryCount	0

Description: This configuration ensures that if a step fails, the process is immediately marked as failed without any retry attempts.

Example 2: Retry on Failure with Fixed Interval

Field	Value
action	RETRY
runRequest	null
runRequestAfterRetries	false
retryInterval	5000 (5 seconds)
retryBackoffExponential	false
retryCount	3

Description: This configuration attempts to retry the failed step up to three times, waiting five seconds between each attempt. No fallback process is initiated after retries are exhausted.

Example 3: Retry with Exponential Backoff and Fallback Process

Field	Value
action	RETRY
runRequest	ProcessRequest
runRequestAfterRetries	true
retryInterval	2000 (2 seconds)
retryBackoffExponential	true
retryCount	5

Description: This configuration retries the failed step up to five times, doubling the retry interval with each attempt (exponential backoff). If all retries are exhausted, it initiates a fallback process defined by runRequest.

Example 4: No Action on Failure

Field	Value
action	NONE
runRequest	null
runRequestAfterRetries	false
retryInterval	0
retryBackoffExponential	false
retryCount	0

Description: This configuration has the same effect of having no error fail configuration. The step will still fail.

Usage in Process Flow

The FailConfiguration is utilized within the error handling mechanisms of process executions. When a step fails, the system consults the FailConfiguration to determine the appropriate response. Below is an overview of how it integrates into the process flow:

1. Step Failure Detection:

   • During process execution, if a step encounters an error, the failure is detected and the corresponding FailConfiguration is retrieved from the ErrorPolicy.

2. Action Determination:

   • Based on the action field in FailConfiguration, the system decides whether to fail the step, retry it, or take no action.

3. Executing the Action:

   • FAIL: The step is marked as failed, and the process may halt or trigger compensating actions.
   • RETRY: The system attempts to re-execute the step according to the retry policies defined (retryCount, retryInterval, and retryBackoffExponential).
   • NONE: The process continues without altering the step's status, effectively ignoring the failure.

4. Fallback Process Execution:

   • If runRequestAfterRetries is set to true and all retry attempts are exhausted, the system initiates a fallback process using the details provided in runRequest.
   • If false, it runs the process on each failed attempt instead of after all retries

Best Practices

• Define Clear Actions: Choose the appropriate StepErrorAction based on the criticality of the step. Use FAIL for essential steps and RETRY for recoverable errors.

• Limit Retry Attempts: Set a reasonable retryCount to prevent infinite retry loops and manage system resources effectively.

• Use Exponential Backoff: When using retries, consider enabling retryBackoffExponential to reduce the load on external systems and increase the chances of successful retries.

• Implement Fallback Processes: Utilize the runRequest and runRequestAfterRetries fields to define fallback mechanisms, ensuring that the process can recover gracefully from failures.

• Secure Process Requests: Ensure that ProcessRequest instances contain only necessary and secure information to prevent unauthorized process initiations.

• Monitor and Log Failures: Implement comprehensive logging around failure handling to track issues and facilitate troubleshooting.

• Test Error Handling: Regularly test failure scenarios to ensure that the FailConfiguration behaves as expected and that retry mechanisms and fallback processes function correctly.