Siebel Business Process Framework: Workflow Guide > Options for Configuring a Workflow Process > Starting a Workflow Process >

Starting a Workflow Process from the Workflow Process Manager

A workflow process can run in the Workflow Process Manager server component. It can start on the Siebel Server in the following ways:

• From a workflow policy that runs on the Siebel Server. For more information, see Starting a Workflow Process from a Workflow Policy.
• From a script that specifies the Server Request parameter. For more information, see Starting a Workflow Process from a Script.
• From a run-time event with the Processing Mode property set to Remote Synchronous or Remote Asynchronous. For more information, see Starting a Workflow Process from a Run-Time Event.

The siebel.cfg file is the default configuration file for Workflow Process Manager server components.

Siebel CRM runs a workflow process that starts from a script in synchronous mode.

Siebel CRM does not support a workflow process that runs on the Siebel Server and that uses a business service to call a user interface element, including navigation functionality, such as the user interact step.

For more information, see Workflow Process Manager Server Component.

Remote Synchronous Processing

If a user starts a workflow process that runs on the Siebel Server in the Workflow Process Manager server component, then this workflow process runs only if the user is connected to the Siebel Server. If the user is not connected, then Siebel CRM queues the request and runs the workflow process when the user synchronizes or when the Siebel Server is available. For more information, see Server Requests Business Service.

User Key Routing with Workflow Process Manager

A server key map is a map that defines the rule groups that Siebel CRM loads and processes for each server. You can configure a Siebel Server to load multiple rule groups. A server key map divides rules among different servers. To define a server key map, you use the Server Key Map view in the Assignment Administration screen.

You can use key routing to do the following:

• Routing. To control how Siebel CRM routes Workflow Process Manager requests, you can set up the RequestKey parameter on the Workflow Process Manager so that Siebel Workflow registers this key when Siebel Workflow starts.
• Recovery. To target the ping messages, each Workflow Process Manager registers a unique key. The Workflow Recovery Manager uses these keys to keep track of which Workflow Process Manager is alive and what information the Workflow Process Manager is processing.

To send an assignment request, you define the AsgnKey parameter, where the AsgnKey parameter is the Row Id of the assignment rule group that is associated with the rules that Siebel CRM must evaluate. If you use AsgnSrvr, then the AsgnKey parameter must contain the Row Id of one of the rule groups that you define for the Siebel Server in the Server Key Mappings view. The Assignment Server (AsgnSrvr) looks for entries in the Siebel Server key map for a specific server, and then loads rules for only the rule groups that are associated with that server key map. Assignment Manager uses key routing to route the request to a particular Assignment Manager instance where the rules are loaded for that rule group.

To load the same rule group, you can define multiple servers. Assignment Manager routes requests to one of the Siebel Servers where that rule group references load balancing metrics.

The following environments support server key mapping:

• An interactive and dynamic assignment exists
• A script or workflow process calls a business service

If Workflow Recovery Manager is activated, then the Key Based Enabled parameter for Workflow Process Manager must be set to true.

For more information, see Siebel Assignment Manager Administration Guide.

Controlling How Siebel CRM Handles the User Id

If the Workflow Process Manager inserts a record, then, by default, Siebel CRM sets the CREATED_BY field to 0-1, which is the ROW_ID for employee SADMIN. In some situations, it can be desirable to set the CREATED_BY field to a value other than the Id for SADMIN.

For example, assume a workflow process inserts an activity if a user performs an action in the Siebel client. The Asynchronous Server Requests business service starts this workflow process and the Workflow Process Manager runs it on the Siebel Server. It sets CREATED_BY to SADMIN but the business requirement is to set CREATED_BY to the user who caused the workflow process to start.

To control how Siebel CRM handles the user Id

• Instead of using Workflow Process Manager on the Siebel Server to start the workflow process, you can configure Siebel CRM to start the workflow process so that it runs locally. If the workflow process runs locally, then the user session creates the record and Siebel CRM sets CREATED_BY to the user Id. This workflow process runs synchronously.
• If the business requirement is to record the user who caused Siebel CRM to insert a record, then you can configure Siebel CRM to pass the Login Id or Login Name of the user to the workflow process on the Siebel Server, and then write it to an extension field in the business component. To get the Login Id or Login Name for the user, you can use the LoginId or LoginName function in a script. For information about how to pass data to a custom process property of a workflow process when Siebel CRM sends a server request, see Server Requests Business Service.