Siebel Business Process Framework: Workflow Guide > About Siebel Tools and Process Properties > About Process Properties >

Predefined Process Properties

Some default process properties automatically defined for each workflow process include:

• Object Id. The Siebel row ID of the record against which the process is invoked.
• Error Code. An error symbol of the process instance if a step returns an error. This process property is automatically populated when an error occurs.
• Error Message. An error message text of the process instance if a step returns an error. This process property is automatically populated when an error occurs.
• Siebel Operation Object Id. The Siebel row ID of the record that is updated, created, or queried on during a Siebel Operation step. This process property is automatically populated when a Siebel Operation step is executed.
• Process Instance Id. A unique number assigned to the currently running instance of the process. This process property is automatically populated when a process is executed and persistence is activated.

About the Object Id Process Property

The Object Id process property is the Siebel Row Id of the primary business component record against which a process is invoked.

Run-Time Event Behavior

When a workflow is invoked by a run-time event, the active business component instance that triggered the run-time event is automatically passed to workflow. Run-time events are received on the row specified by the Object Id property. Workflow receives and processes this event only when the business object that the active business component instance belongs to is the same as the business object in the workflow definition. If workflow can receive this event, the Object Id process property is automatically set to the active row of the primary business record in the business object.

If the business component that actually triggered the run-time event is not the primary business component, the active row of the business component is not reflected in the Object Id process property, and it needs to be retrieved through some extra processing.

Long-Running, Interactive, and Service Workflow Behavior

Behavior for the long-running, interactive, and service workflow processes include:

• The Object Id must match the Row ID of the primary business component's active row. The Workflow engine does not allow the active row of the primary business component to be different from the Object Id process property. If the Object Id process property is different from the active row, the primary business component is executed again to make the active row the same as the Object Id.
• It is possible to change the active row by assigning a new Row Id to the Object Id property. When Workflow detects that an assignment is made to the Object Id process property, Workflow executes the business component again and makes the new Row ID the active row.
• You can set the Object Id to an empty string then Workflow no longer enforces the must match rule. However, the parts of Workflow that require an Object Id, such as run-time events and Siebel Operation steps, cannot be used until the Object Id is set to a new Row ID.

Changing the Active Row in a Workflow Step

If you need to change the active row in a step of a workflow, you can do so by using an appropriate Business Service step or Siebel Operation step. However, you must promptly update the Object Id process property to the new active Row ID in the output arguments of the step that changes the active row.

Once a step finishes and output arguments have been evaluated, Workflow checks to make sure the Object Id matches the active row. So changes to the active row must be reflected in the Object Id property within the affected step.

About the In/Out Process Property

If necessary, you can run the workflow process and avoid receiving response data back. For example, to avoid inserts to the S_SRM_DATA table that can cause a heavy backlog.

Configuration within a workflow process determines whether response data is returned. If a process property's type is Out or In/Out, then outputs are returned to the caller. For example, to SRProc. If the caller receives a non null response from a callee, it writes the response into the S_SRM_DATA table. If no response data is received, the response is not written into the S_SRM_DATA table.

When a request is inserted into the S_SRM_REQUEST table, one or more rows are inserted into the S_SRM_DATA table for the component request parameters and input arguments used by the request. During submission of a request, the S_SRM_DATA table column MSG_TYPE_CD contains a value of REQ_DATA, indicating the type of data is to request data or inputs for the request. When the request finishes execution, a set of rows is also inserted into the S_SRM_DATA table with the MSG_TYPE_CD column having value of REQ_RESPONSE, indicating the request has returned a response back to the caller. In this case, since the request is in the S_SRM_REQUEST table, the caller is the Server Request Processor component.

To run a workflow while avoiding response data inserts

1. Configure one of the following options:

• Until immediately before the workflow ends, leave the In/Out property on the process property with the value In/Out.
• Right before the workflow ends, call another step that nulls out values stored in the process properties. In this way, SRProc receives no response text and an insert is not made into the S_SRM_DATA table.

2. Review the workflow's process properties and set the In/Out property to NONE.