Package de.xima.fc.interfaces.workflow.execution

Interface ISuccessResultData

All Superinterfaces:

IBaseCompletionResult, Serializable

All Known Subinterfaces:

INormalCompletionResult, IReturningCompletionResult

All Known Implementing Classes:

NodeReturnedException, NormalCompletionResult

public interface ISuccessResultData
extends IBaseCompletionResult

Represents a successful result of INodeHandler#execute, i.e. when the node completes normally or abruptly by returning.

Since:

7.0.7

Author:

XIMA MEDIA GmbH

Method Summary

Modifier and Type	Method	Description
default List<NodeSoftErrorException>	getSoftErrors()	Business logic might need to distinguish between hard errors and soft errors.
Object	getSuccessValue()

Methods inherited from interface de.xima.fc.interfaces.workflow.execution.IBaseCompletionResult

getAlwaysValue, getFileValue, getNode

Method Detail

getSuccessValue

Object getSuccessValue()

Returns:

The value that is returned when node completed normally. Must conform to the IExecutionResultDescriptor.getSuccessValueDescriptor(IValueDescriptorFactory) IExecutionResultDescriptor#getSuccessValueDescriptor.

Since:

7.0.0 This super interface was introduced in 7.0.7, but the method itself existed in the subtypes since 7.0.0.

getSoftErrors

default List<NodeSoftErrorException> getSoftErrors()

Business logic might need to distinguish between hard errors and soft errors. A hard error is an exception that results in the workflow failing when not caught by an error handler. These are for example technical errors such as a missing database connection, or when a file cannot be read form the file system due to missing permissions.

Soft errors are similar to warnings in that not all of the the business logic could be performed or that some the business logic had to be skipped. In contrast with hard errors, however, the node itself still completes normally and does not cause the workflow to fail. This method can be used to check if any soft errors occurred.

Soft errors are similar to hard errors in that both provide an error code, an error message, as well as custom additional data.

Common examples of soft errors include missing files from optional upload form elements, or a 4xx HTTP return code. However, the exact definition of what constitutes a soft error must be decided on a case-by-case basis by each individual node implementation. This method is meant to be a uniform interface for nodes to provide information about soft errors. This method can also be used to check whether a node was "successful", by checking whether the list of soft errors is empty. Implementations are encouraged to provide more details about their completion status via getSuccessValue().

Soft errors are purely informational. Workflow execution is not affected in any way by whether or not soft error occurred. The node still either completes normally or returns, and the next node or trigger is processed as if no soft errors were present.

Returns:

A list of soft errors that did occur during the execution of the workflow node.

Since:

7.0.7