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 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.

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.