Final actions are executed when a process was completed or aborted. They are typically used to clean up other resources that have been accessed during the lifetime of the process, or to archive process data somewhere else before the process gets destroyed. Like long actions, final actions are executed in separate phases, but there are only two phases, because final actions must not modify the completed or aborted process anymore. Only the first phase is permitted access to the process. The second phase runs outside of any database transaction, and may access remote servers that do not respond immediately.

The first phase consists of two methods

boolean isExecutable(Process process);

which returns whether the action needs to be executed for the given process. If this method returns false, no further methods are called.

T extractParameters(Process process);

which reads data from the process that is needed for the actual execution of the final action. All relevant data must be packaged into an object of some type, and returned from the method.

The second phase consists of the method

void execute(T parameters);

It is passed the object that was returned from extractParameters. It may perform arbitrary computations for an extended period. The method may not, however, access any objects of the workflow repository.

If any of the above methods throws an unexpected exception, it will be logged and the next configured final action will be invoked. The process will finally be destroyed, even if the execution of some final actions failed.

The methods may however throw a RetryableActionException for temporary failures. In that case, the Workflow Server will call the method again after some delay. The retry of final actions is configurable with the Workflow Server properties workflow.server.retry-final-action.*. For details see Table 3.33, “Workflow Server Properties” in Deployment Manual.

The method abort() should be implemented to let all running isExecutable, extractParameters, and execute method calls return early, possibly by throwing an ActionAbortedException. This method is called when the Workflow Server is shutting down.

The class FinalActionBase implements the FinalAction interface and provides some convenience code.

Like other actions, final actions must be reentrant and robust against being rerun in the case of a problem.