Workflow Execution
The execution of a workflow is triggered by a message from an SDX component (see Figure 1). The message includes the distinguished names (DNs) of the objects related to the service being provisioned, together with the name of the workflow to be executed. The objects are stored in the directory.
The DNs are specified by the state machine controlling the life cycle of the target object or by the target object itself, which is always present in the message. The workflow engine uses the DNs to retrieve the necessary information from those objects and pass them to the workflow. To avoid retrieving unnecessary information, a parameter list is associated with every workflow. This list contains common unique names valid in the realm of the workflow. A translation table maps those common names to LDAP names and is defined in the workflow configuration file.
Receipt of the message from the SDX component instantiates the parameter list associated with the named workflow. All workflow names must end with Workflow. The associated parameter list, if stored in a JAR file, has the same prefix as the workflow but ends with WorkflowParameterList. For further information, see Chapter 16, Work Item Library.
Driven by this parameter list, a series of LDAP operations are performed to retrieve the specified data and create a token containing the data. A token is the object that carries the data along with the components and determines their eligibility for execution. Finally, the workflow is instantiated, and this token is passed to it. This action starts the execution of the workflow.
Completion of the workflow is signalled by the return of a token to the workflow engine. The objects in the directory are updated with the data embedded in the token. The parameter list specifies which token parameters must be sent to the directory. The SDX component that initiated the process is notified via a TCP/IP message whether the workflow was successfully completed. Finally, the workflow is removed from the workflow engine.
Figure 1 shows a sample process where creation of a subscription for the user John Doe triggers the BBRASWorkflow.
During the entire process, a workflow can be paused if it is not progressing, swapped to disk, and resumed later to try again. This process is done automatically without the knowledge of the workflow. This gives the illusion that all active workflows, the ones that have been started but not yet completed, are running in the main memory. The specifics vary depending on the kind of component, which is explained later.