Managers are components that are deployed in the Workflow Server, becoming globally available for use by other plugins. Managers may encapsulate global state that is relevant for multiple processes. They may also coordinate the interaction of processes with external entities, possibly acting as a connection pool. They may react to an external event by requesting a recheck of one or more processes. During a recheck, all guards that were evaluated to false are reevaluated, so that waiting tasks may start running.
Managers must be registered in the file workflowserver.properties by indicating
at least the class of the manager in a property named
workflow.server.managers.<name>.class, where <name>
becomes the name of the manager. Using the optional properties
workflow.server.managers.<name>.order it is possible to control the
startup order of the managers. Additional properties with the prefix
workflow.server.managers.<name>. may be given in the configuration file
and retrieved by the manager during setup.
All managers must implement the interface
Manager.
Typically, it is simpler to base own implementations on the abstract base class
AbstractManager, though. This class provides utility methods for obtaining the
Unified API connection and for reading manager-specific
configuration parameters.
The life cycle of a manager starts with its creation by means of a no-arg constructor.
Afterwards, the setters setName and setConnection are called,
providing context information to the manager. Afterwards init() is called,
which allows the manager to set up itself based on configuration. It may not yet start
asynchronous behavior, because some parts of the server might not be fully set up. That in
turn is allowed after the method start() has been called.
If the server detects that the file workflowserver.properties has changed, it
will call reload(), which allows the manager to update its configuration, if it
possesses this capability.
The method stop() is called when the server is shut down, just before the
Workflow Server stops to execute automatic tasks and to
accept external requests. The manager should stop all asynchronous behavior before returning
from this method. Finally, the method dispose() is called. It provides the
manager with an opportunity to release any system resources, in particular if custom
workflow action were still accessing those resources.
In order to react to external events, processes should register themselves with an
appropriate manager. That manager reacts to events by calling recheck(Process,
...) with the affected process as an argument. Note that this is the only way for a
manager to influence a process directly while operating asynchronously out of the scope of a
call from the server. Particularly, it is not allowed for the manager to update process
variables itself. This must be done by the process after requesting information from the
manager or in a call from the process to the server during the execution of an action.
Using the ManagerService, which is an aspect of the workflow repository that is only available in the Workflow Server, other plugins may request a reference to a manager by providing the manager's name. Note that one manager class may be registered multiple time using different names, if that is required. Clients will have to make a cast to be able to call the business methods of the manager.
 |  |  |
 |