Bookshelf Home | Contents | Index | PDF     

Siebel Business Process Framework: Workflow Guide > Developing a Workflow Process > Process of Planning a Workflow Process >

Determining the Workflow Invocation Event

This task is a step in Process of Planning a Workflow Process.

During the planning phase of a development effort you can determine if the workflow process is invoked by a run-time event, user event, workflow policy, or script.

For more information, see Invoking a Workflow Process.

Using a Workflow Policy to Invoke a Workflow Process

A workflow policy triggers a workflow process after a database change. The basic construct of a policy is a rule. If the conditions of a rule are true, then an action occurs. In some cases, the action invokes the Workflow Process Manager server component to execute a workflow process.

Processing invoked by a workflow policy does not occur in real time. Typical uses of a workflow policy include:

  • EIM batch processing.
  • Siebel EAI inserts and updates.
  • Manual changes from the user interface.
  • Assignment Manager assignments.
  • Siebel Remote synchronization.

Using an Event to Invoke a Workflow Process

Types of events used by Siebel workflow include:

  • Run-time events. A run-time event is based in the Object Manager and occurs when a change is encountered by the user interface or in the business component layer. Processing invoked by a run-time event occurs in real time.
  • User events. A user event is a unique event internal to Workflow that triggers or resumes a long-running workflow process. A user event is generated by the User Event business service.

Events belong to three objects: Application objects, Applet objects, and Business Component objects. Events can be configured from the administrative interface.

Using Script to Invoke a Workflow Process

Scripts can call a workflow process programmatically as a business service. Using script, you can invoke Workflow from an external system. The Workflow Process Manager server component provides APIs for such programmatic invocation. Scripts are raised by the Object Manager.

Scripts belong to four objects: Application, Applet, Business Component, and Business Service.

Summary of Invocation Mechanisms

Table 9 summarizes the main uses and limitations for each of the possible workflow invocation techniques.

Table 9. Description of Advantages and Limitations of Workflow Invocation Techniques
Invocation Method
Most Useful When
Limitations

Workflow Policy

You must detect and react to data changes made outside of the Object Manager. For example, by Siebel Remote or by Siebel EIM.

Limitations for a workflow policy include:

  • Making changes requires database downtime.
  • Relatively complex to configure

Event

You must implement a basic entry point for a workflow or a simple custom action.

You must avoid distributing SRFs. For example, because of the burden created for mobile users.

Limitations for an event include:

  • Cannot directly respond to an event by scripting against the event object
  • Can be more difficult to pass the event context to business logic
  • This invocation technique does not trap data changes made by non-Object Manager components

Script

You need flexibility to write script directly in response to an event.

You need access to an applet event that is only exposed in Siebel Tools.

Limitations for script include:

  • Changes must be distributed through a new .SRF.
  • Does not detect data changes made by non-Object Manager components. Note that, for workflow, the script is implemented on a Siebel Tools Object Event.
    
Siebel Business Process Framework: Workflow Guide Copyright © 2008, Oracle. All rights reserved.