Siebel Business Process Framework: Workflow Guide > About Workflow Process Design Options > Invoking a Workflow Process >

Invoking a Workflow Process That Runs in the Workflow Process Manager

A workflow process can be run within the Workflow Process Manager server component. The ways in which a workflow process can be invoked on the server include:

• From a workflow policy that executes on the server.
• From a script that specifies the Server Request parameter.
• From a run-time event with the Processing Mode property set to Remote Synchronous or Remote Asynchronous.

If you compiled a custom .srf file using Siebel Tools, this file needs to be added to the Objects directory on the Siebel Application Server. In addition, you must update the siebel.cfg file referenced in the Server parameters to reflect the custom .srf file. Note that the siebel.cfg file is the default configuration file for Workflow Process Manager server components.

Considerations to weigh include:

• Invoking a workflow process from a script is performed in synchronous mode.
• A business service that calls a UI element, including navigation functionality such as the User Interact step, is not supported when a process runs on the server.

For more information, see About the Workflow Process Manager

About Remote Synchronous Processing

If a user invokes a workflow process that runs on the server within the Workflow Process Manager server component, the process executes only if the user is connected to the server. If the user is not connected to the server, the request is queued and executes when the user synchronizes or the server becomes available. For more information, see About the Server Requests Business Service.

About Key-Based Routing with Workflow Process Manager

A server key map defines the rule groups that load and process for each server. You can configure a server to load multiple rule groups. When you define server key maps, you are actually dividing the rules among the different servers. Server key maps are defined in the Server Key Map view in the Assignment Administration screen.

You submit an assignment request by specifying the AsgnKey parameter, where the AsgnKey parameter is the row id of the assignment rule group that is associated with the rules you need to evaluate. When using AsgnSrvr, the AsgnKey parameter must be the row id of one of the rule groups defined for the server in the Server Key Mappings view. The assignment server (AsgnSrvr) first looks for entries in the server key map for a specific server, and then loads rules for only those rule groups associated with that server key map. Assignment Manager uses key-based routing to route the request to a particular instance of Assignment Manager where the rules are loaded for that rule group.

You can specify multiple servers to load the same rule group. Assignment Manager routes requests to one of the servers where that rule group is based on load balancing metrics.

Environments in which the server key mapping feature is supported include:

• Where there is an interactive and dynamic assignment.
• Where a script or workflow process calls a business service.

Reasons for using Key Based Enabled include:

• Routing. You can setup the RequestKey parameter on WfProcMgr so that when workflow comes up, it registers this key. This way you can control the routing of WfProcMgr requests.
• Recovery. To target the ping messages, each WfProcMgr registers a unique key. The recovery manager uses these to keep track of which WfProcMgr is alive and what WfProcMgr is processing.

In general, if Recovery Manager is activated, then the Key Based Enabled parameter for WfProcMgr should be set to true.

For more information on key-based routing, see Siebel Assignment Manager Administration Guide.

About Workflow Process Manager and Automatic Record Insertion

When the Workflow Process Manager inserts a record, by default, the system generated CREATED_BY field is set to 0-1, which is the ROW_ID for employee SADMIN. In some cases, it can be desirable to have the CREATED_BY field set to other than SADMIN's Id.

For example, assume you have a workflow that inserts an activity record when a user performs an action in the Siebel client. Since this workflow is invoked by the Asynchronous Server Requests business service, the workflow is executed by the Workflow Process Manager on the server, and CREATED_BY is set to SADMIN, although the business requirement is to have CREATED_BY set to the user who caused the workflow to invoke.

In this situation, actions you can take include:

• Instead of invoking the workflow on the server using Workflow Process Manager, invoke the process so that it runs locally. As a result, the user's session creates the record and CREATED_BY are set to the user's Id. In this case the workflow process is executed synchronously.
• If the requirement is to record which user caused a record to be inserted, you can pass the user's Login Id or Login Name to the workflow process on the server then write it to an extension field in the business component. You can obtain the user's Login Id or Login Name in a script by using the standard functions LoginId () or LoginName (). For information about how to pass data to a custom workflow process property when submitting a server request, see About the Server Requests Business Service.