Actions are executed during the entry and exit phases of a user task, during the execution
of an automated task, or during the processing of a RunActionTimerHandler. This
means that an action is typically executed in the context of a task, but that it may be
executed in the context of a process, too, if used with a timer handler.
By means of the interface
Action,
you can only implement server-side actions, that is, actions that run completely within the
Workflow Server. Actions are run on the server on behalf
of the workflow user as configured in the file workflowserver.properties.
The main method of an action is execute(WorkflowObject), where the argument is
either a task or a process depending on the context of the action. While executing, the
action implementation should only read and write variables of the argument workflow object
and its view. It is recommended that the exact variable names are made configurable by means
of bean-style getters and setters.
The method isExecutable(WorkflowObject), should return false, when it is not
currently possible to execute an action. Normally, you should always return
true from this method, but there are cases where you might want to wait for a
workflow variable to be set correctly before processing an action.
After execution, you may return a new instance of
ActionResult
in order to indicate success or failure. If you use the attributes successVariable and/or
resultVariable in your XML workflow definition, the action result is automatically evaluated
to set those variables. The action result can also take exceptions that are interpreted as
warnings. If you include warnings in your result, they are added to the list that is
returned from the method getWarnings() of the affected workflow object.
The method abort() should be implemented to let all running
execute calls return early, possibly by throwing an
ActionAbortedException.
This method is called when the Workflow Server is shutting down. There is no need to
implement special logic if the execute method always returns early. If execution takes some
time, you should also consider implementing a long action instead.
The name returned by the method getName() of an action is used solely for
logging and for parameterizing exceptions. It does not carry any semantic meaning, so that
you may choose it as you like.
In order to simplify the development of an action, you may derive your class from the
predefined classes
AbstractAction
or
SimpleAction.
Thereby, it is enough to implement a single method, namely execute(Process) in
the former and doExecute(Process) in the latter case. Because the exact task in
which the action is executed is not included in the signature of these methods, this
approach requires that all relevant variables are defined at the process level. This is the
typical use case. A detailed example of an action sending mail implemented as
SimpleAction is given in Section 6.11.3, “Example Code of the Mail Action”.
The server may run an action more than once, in particular when a transaction has to be restarted due to concurrent activity. Therefore, you should design your actions in such a way that either the second execution detects that the action has already been executed or that a repeated execution is acceptable. For example, it is preferable to set a variable to a certain value rather than to increment an integer or to toggle a flag
 |  |  |
 |