Siebel Business Process Framework: Workflow Guide > About Workflow Process Design Options > About Events >

About the Run-Time Event

A workflow process can integrate with the run-time events engine to provide a simplified way to automate a business process. Benefits provided by this technique include:

• Allows real-time monitoring of events.
• Minimizes the need for scripting and workflow policy invocation.

The types of events that are possible include:

• Application.
• Business Component.
• Applet.

A run-time event allows the Siebel application to respond in real time to user actions. A run-time event can be specified in the connectors that emanates from for Start, Wait, or User Interact steps to invoke or resume a workflow process. The properties of the WF Step Branch that are used to define a run-time event include:

• Event Object Type.
• Event Object.
• Event.
• Sub Event.
• Event Cancel Flag.

For more information, seeInvoking a Workflow Process from a Run-Time Event.

A run-time event provides one way to invoke a workflow process. For a comparison of invocation methods, see Invoking a Workflow Process.

For more information on run-time events, see Siebel Personalization Administration Guide.

Using a Run-Time Event With a Long-Running Workflow

NOTE:  It is recommended that a run-time event not be used to trigger a long-running workflow because a run-time event is specifically attached to a single user and a single session.

A run-time event is only for that single user, as it stems from Personalization functionality. Instead, use an interactive workflow or a service workflow to handle the run-time event. Then, after processing and validating the workflow, generate a user event to notify a long-running workflow.

Using a Run-Time Event With the User Interact Step

Events not supported with the User Interact step include:

• The DisplayRecord event.
• The DisplayApplet event.
• The Login event. Use the WebSessionStart event instead.

The event supported with the User Interact step includes:

• The SetFieldValue event for a field that has the Immediate Post Changes property set to TRUE.

  Immediate Post Changes is a property on a business component field that causes an immediate roundtrip to the server if a change is made to the field. This dictates an immediate re-calculation of the field or refresh of the view. When Immediate Post Changes is set to True the browser script PreSetFieldValue event is bypassed. For more information, see Configuring Siebel Business Applications.

Using a Run-Time Event Within a Business Object Context

A workflow process that references a run-time event is only invoked when the run-time event is detected from within the same Business Object context in which the workflow process is based.

For example, assume a workflow is invoked by the WriteRecord run-time event and that the workflow's Business Object property is set to Service Request. To update the record, the user clicks the Service Requests List screen tab, updates the Status field, then steps off the record. In this case, the record is written in the context of the Service Request business object, and the run-time event that is defined on the workflow process fires.

However, the run-time event does not fire if the Status field is updated within a non-Service Request business object context. For example, assume the user drills down on a Contact, clicks the Service Requests view tab, updates the Status field, then steps off the record. In this case, the service request record is being written in the context of the Contact Business Object, and the run-time event does not fire.

Using a Run-Time Event Within a M:1 Relationship

When using a runtime-event to trigger a workflow based on a modification made to a record that contains a M:1 relationship with a parent, you must trigger the workflow based on the child's ROW_ID.

For example, assume you need to trigger a workflow when a field in a service request's activity record is updated. Since a given service request can have one or many activities, you must trigger the workflow based on the ROW_ID for the activity, not the service request. If you base the trigger on the service request's ROW_ID, then a change made in the service request's form applet triggers the workflow, but a change made in the activities list applet does not.

To examine this relationship, in the Siebel client navigate to Service Request > Service Request List, create a new service request, drill down by clicking in the SR# field, then use the Activities list applet to create two new activities. In this view, note that the top service request form applet displays fields for the parent service request while the bottom activities list applet displays multiple activities for the parent.

To create a test workflow process triggered within a M:1 relationship

1. In Siebel Tools, in the Workflow Processes OBLE, create a new workflow process object definition with the following values:

   Property	Value
   Process Name	Update Service Request
   Business Object	Service Request
   Workflow Mode	Interactive Flow

   The workflow process is based on the Service Request business object. The runtime-event used in this workflow occurs on the start step and is based on the Action business component, which is a child of the Service Request. Note that the wait step, used here for testing purposes, requires an Interactive Flow. For more information, see About the Wait Step. To view an example, see Creating a New Workflow Process Object Definition.

2. Open the Process Designer for the workflow process you created in Step 1, then create a workflow that resembles the workflow in the following diagram:

   For more information, see About Workflow Process Steps and Connectors, and Diagramming a Workflow Process.

3. Click the Id Triggered connector, then use the Properties window to define values described in the following table:

   Property	Value
   Event Object Type	BusComp
   Event	WriteRecord
   Event Object	Action

4. Click anywhere on the canvas background.
5. In the MVPW, right-click then add a new process property using values described in the following table:

   Argument Field	Value
   Name	ActionBCRowId%
   In/Out	In/Out
   Business Object	Service Request

   For more information, see About Process Properties.

   To capture the triggered activity ROW_ID, you define a process property, then use a wait step which can read a field from the child business component into the process property in the wait step's output argument without modifying the underlying data.

6. Click the Get Activity Id step, then click the Output Arguments tab in the MVPW.
7. Right-click, choose New Record, then define a new record using values described in the following table:

   Argument Field	Value
   Property Name	ActionBCRowId%
   Type	Expression
   Value	Id
   Business Component Name	Action

   For testing purposes, this step reads the triggered activity ROW_ID, which is the Id field, into the ActionBCRowId% process property. No input arguments are defined for the wait step.

8. Validate then simulate the workflow process.

   For more information, see Process of Testing a Workflow Process.

9. Implement this technique in your production workflow.

   This example demonstrates how you can trigger a workflow based on changes made to a child in a M:1 relationship. It includes steps to test the technique. In a production environment, if you no not need to capture the child's ROW_ID, you can simply define the trigger on the connector emanating from the start step, as described in Step 3.

Using a Run-Time Event With the Updated By Field

If a step has a runtime event has its processing mode defined to run locally to either start or resume a Workflow Process, then Updated By is the user who is currently logged into the application.

Run-Time Events That Cannot Be Used to Invoke a Workflow Process

Since a workflow process can be invoked only within the context of a business component record, if there is no business component record context it is not possible to invoke a workflow, and attempting to invoke a workflow using the BusComp Query event will fail. Therefore, any runtime event that has the possibility of returning no results cannot be used to invoke a workflow.

Repeat Usage of a Runtime Event

When defining a run-time event within a workflow process, the run-time event must not be repeated. You cannot use the same event more than once within a given workflow process.