The Workflow Design section of RPM allows users to create Workflow containers and define workflows. These containers include WorkflowGroup, WorkflowCategory, and WorkflowProcess.
The configuration of a WorkflowProcess defines the steps the workflow undergoes once it is running. Workflow
Design is not available in this version of the API.
The Workflow
Process section of RPM allows users to manipulate WorkflowProcess containers created in Workflow Design. The API allows the user to load previously defined workflow containers and manipulate them. This includes associating workflow processes to projects as well as scheduling, starting, suspending, resuming, and cancelling workflow processes.
As shown in the UML diagram labelled Diagram 1, the API defines three concrete workflow containers:
A WorkflowGroup
is predefined. In order to map a workflow process to a particular type
of container, it must be defined in the appropriate workflow group. For
example, to map a workflow process to a Defect container, it must be
defined in WorkflowGroup ‘Defects’. A WorkflowGroup has no valid parents
and can have children of type WorkflowCategory.
A WorkflowCategory
container categorizes workflow processes within workflow groups. A
WorkflowCategory must have a parent of type WorkflowGroup and can have
children of type WorkflowProcess.
A WorkflowProcess
container defines a workflow process that can be mapped to one or more
containers and manipulated. In order to manipulate a workflow process,
it must first be activated.
Once a WorkflowProcess is loaded by the API, it can
be manipulated using the following application methods.
These methods are described in detail in the API_interfaces document: Interfaces and Methods
A running workflow process executes the steps
defined when the process was created. Once all of the workflow steps
have been completed, the workflow process is closed.
Once a workflow has been associated to a GenericProject, the WorkflowProcess specified will appear in an
AvailableWorkflowProcess object in the workflowProcessesAvailable array
in the GenericDocument, WorkElement, or AbstractScope objects contained
within the GenericProject specified (depending on the group in which it
was defined).
Once a workflow has been started, it will appear in a RunningWorkflowProcess object in the
workflowProcessesRunning array in the GenericDocument, WorkElement, or
AbstractScope on which it was started. All started, suspended, resumed,
and hanged processes are considered to be running.
The author of the Workflow Process in design mode need not immediately assign a participant to a workflow step; instead he can define a role which allows the participant to be assigned to the workflow process later on. A Resource, a GenericSecurityRole, and a
ContactGroup can be mapped to an existing workflow role once the workflow process is associated to a GenericProject. This allows for different participants to be assigned to the same step of a process in different GenericProjects.
Once a WorkflowProcess has been associated to a project and if the process contains one or more roles, a list of WorkflowRoleMapping containers can be loaded through the list of available workflow processes for a WorkElement, a GenericDocument, or an AbstractScope container. The WorkflowRoleMapping can then be populated with a Resource, a GenericSecurityRole, and/or a ContactGroup.