Siebel Business Process Designer Administration Guide > Introduction to Workflow Processes >

Run-Time Architecture of Workflow

The Workflow run-time architecture is based on the Siebel Object Manager layer and the server infrastructure layer of the Siebel eBusiness applications architecture. The run-time environment is available both as a business service and as a server component. The run-time architecture supports three invocation modes for invoking and resuming workflow processes: Local Synchronous, Remote Synchronous, and Remote Asynchronous. Figure 5 shows the run-time architecture of Workflow.

Figure 5.  Run-time Architecture of Workflow

Workflow Process Types

Siebel Business Process Designer has four types of workflow processes that characterize run-time behavior. The processing type is set in the Workflow Processes list editor of Siebel Tools, using the Workflow Mode field. The workflow process types are as follows:

• 7.0 Flow. A 7.0 workflow process provides backward compatibility for existing Siebel 7 (pre-7.7) workflows. For more information, see About 7.0 Workflow Processes.
• Long Running Flow. A long-running workflow process is a persistent workflow that can last for hours, days, or months. For more information, see About Long-Running Workflow Processes.
• Interactive Flow. An interactive workflow process navigates the user across Siebel views. For more information, see About Interactive Workflow Processes.
• Service Flow. A service workflow process executes a set of operations upon event invocation. For more information, see About Service Workflow Processes.

Workflow Process Manager

Workflow processes can be executed in any application object manager as a business service. Workflow processes can also be executed in the Workflow Process Manager server component.

Running Workflow as a Business Service

Workflow execution in an application object manager is invoked as a business service. The Workflow business services are called Workflow Process Manager. The Workflow Process Manager business services are also referred to as the Workflow engine. As a business service, the Workflow engine takes input arguments and returns output arguments.

The two Workflow business services are:

• Workflow Process Manager
• Workflow Process Manager (Server Request)

When the Workflow Process Manager business service is called, the workflow process is run in the object manager of the application called. When the Workflow Process Manager (Server Request) business service is called, the workflow process is run in the server component called Workflow Process Manager.

Running Workflow in the Workflow Process Manager Server Component

Workflow processes can be executed in the background using the Workflow Process Manager server component. The Workflow Process Manager server component is configured and optimized to run the Workflow Process Manager business service. The Workflow Process Manager server component acts as the object manager to run workflow processes, including all application logic within the workflow process.

Workflow Management Server Components

The Workflow Management server component group includes the following server components:

• Workflow Process Manager (WfProcMgr)
• Workflow Process Batch Manager (WfProcBatchMgr)
• Workflow Monitor Agent (WorkMon)
• Workflow Action Agent (WorkActn)
• Workflow Recovery Manager (WfRecvMgr)
• Generate Triggers (GenTrig)

Workflow Process Manager and Workflow Process Batch Manager

The Workflow Process Manager server components act as the application object manager to run workflows. The Workflow Process Manager server components are specialized server components configured and tuned to run workflow processes. Like all server components, the Workflow Process Manager server components provide a multi-threaded environment.

The Workflow Process Manager uses the Siebel Object Manager framework and runs workflows as a business service. The Workflow Process Manager hosts the Business Object layer and the Data Object layer. It is a scalable architecture with the ability to run multiple object managers and multiple tasks for each object manager.

NOTE:  The name Workflow Process Manager refers to both the Workflow business service (referred to as the Workflow engine) and the workflow server components.

Workflow Monitor Agent

The Workflow Monitor Agent executes Workflow policies. Workflow Monitor Agent monitors policies, and executes actions once the policy conditions are met.

Workflow Action Agent

The Workflow Action Agent processes requests logged in the action request table (S_ESCL_ACTN_REQ) for a policy group and invokes all actions linked with the Workflow policy being processed.

Workflow Recovery Manager

The Workflow Recovery Manager polls the Workflow engine to check workflow instances running on the server. The Workflow Recovery Manager recovers crashed instances and resumes instances that have been waiting beyond a due date.

Generate Triggers

Generate Triggers allows you to create database triggers. The Workflow Policies module of Siebel Business Process Designer uses these database triggers to identify which records may match policy conditions. The Generate Triggers server component needs to be rerun whenever new policies are created or deleted. You can run the Generate Triggers server component from either the Server Manager graphical user interface, or command line mode.

Invocation Mechanisms

Siebel Workflow can be invoked in three ways:

• Workflow Policies. Workflow Policies are database triggers that invoke a workflow process when a policy violation occurs. The violations are written to a database table. The Workflow Monitor Agent reads from the table and invokes the Workflow Process Manager server component to execute the workflow process. Processing invoked by Workflow Policies is not real time.
• Events:
  • Run-time events (Personalization events). Run-time events are based in the object manager and they occur when a change is encountered by the user interface or the business component layer. Processing invoked by run-time events is real time.
  • User events. User events are unique Workflow-internal events that trigger or resume a long-running workflow process. User events are generated by the User Event business service.
• Script. Scripts can call Siebel Workflow programmatically as a business service. Using scripts, you can invoke Workflow from an external system. The Workflow Process Manager server component provides APIs for such programmatic invocation.

For more information on invoking Siebel Workflow, see Invoking Workflow Processes.

Administration and Monitoring

Administration and monitoring of your workflow processes happens in the Administration - Business Process views in the run-time client. You use the Administration - Business Process views to stop workflow processes, to delete process instances and to purge process instances from the log, to monitor workflow processes that are running, and to recover workflow processes that have been interrupted.

For more information, see Administering Workflow Processes in the Run-Time Client.

Recovery

If the Workflow Process Manager server component fails, Siebel Workflow automatically resumes the interrupted workflow instances when the server restarts. Recovery is performed by the Recovery Manager based on the process instance's state information that is saved by the Workflow engine.

To manually recover process instances, you use the Workflow Instance Admin view. From the application-level menu in the run-time client, choose Administration - Business Process > Workflow Instance Admin. See Workflow Instance Admin View.

For more information, see Recovering Workflow Processes.