Siebel Business Process Framework: Workflow Guide > About Workflow Process Steps and Connectors > About Workflow Process Step Types >

About the Siebel Operation Step

The Siebel Operation step includes operations such as Insert, Update, or Query. These operations are performed on business components. This topic includes the following topics:

• Defining a Siebel Operation Step
• Defining a Siebel Operation Search Specification
• Updating a Field That Resides in a non-Primary Business Component
• Updating a Field That is Based on a Multi-Value Group
• Updating a Calculated Field
• Using the Siebel Operation Step to Traverse a Record Set
• Using the Siebel Operation to Update a Process Property
• About the Siebel Operation Object Id Process Property
• About the Upsert Operation on the Siebel Operation Step
• About the Relationship Between a Siebel Operation and Siebel Object Layers
• Defining a Primary Business Component for a Business Object

Defining a Siebel Operation Step

You can define a Siebel Operation step for a business component associated with the business object defined for the workflow process. If you need to update a business component not associated with the business object, you can invoke a subprocess or associate the business component to the business object using Siebel Tools.

To define a Siebel Operation step

Perform the procedure described in Adding a Step to a Workflow Process with the following modifications:

1. In the Operation property, choose the type of operation.

   For updates or inserts of fields that have dependencies, make sure the fields are valid. For example, if you have a service request process and your workflow process is updating the area and sub-area fields, you must make sure the values chosen for the subarea field are valid for that associated area.

2. For the Business Component property, choose the name of the business component whose records this business service is interacting.
3. (Optional). In the MVPW, create new input and output arguments.

   If an Insert or Upsert operation is performed, make sure you add the required arguments in the MVPW. Make sure you specify the name of the field to be updated in the Field Name argument field. In the Type argument field, choose an input argument type then define other argument fields, depending on the type you specify.

   For more information, see About Process Properties.

4. (Optional). Create a search specification in the MVPW.
   1. In the Type argument field, choose a search specification type, as described in the following table:

      Type	Description
      Literal	A a static string where the run-time value is the same as the one defined in the Process Designer.
      Expression	A Siebel expression, often based on other run-time variables, where the run-time value can only be determined at run time by evaluating the expression.

   2. In the Search Specification argument field, enter search specifications.
   3. If the search specification Type is Expression, choose the applicable business component name.

      For more information, see Defining a Siebel Operation Search Specification.

Defining a Siebel Operation Search Specification

You can define search specifications to identify the specific data on which to perform the operation. Search specifications are used when the business component has multiple records and you need to perform the operation on only some of the records. For example, if you have a process for the Account object and you need to update only those Opportunities with a lead quality of Poor, you define search specifications to access only those Opportunities.

CAUTION:  Define your Siebel operation search specification as efficiently as possible, so that only the smallest necessary set of rows match. Search specifications that identify a large set of rows can cause severe performance degradation.

Defining a Literal Search Specification

A search specification of type Literal is executed as written. For example, [Status] LIKE '*Open*'. A search specification of type Expression allows you to construct a search specification dynamically. For example, "[Contact ID] = ' " + [&New ID] + " ' " is evaluated to [Contact ID] = '1-ABC' if the New ID process property is 1-ABC at run time.

Referencing a Business Component Field in the Search Specification

Both sides of an expression can reference a business component field. The Filter Business Component defines the business component referenced on the left side, and the Expression Business Component defines the business component referenced on the right side. For example, consider the configuration described in Table 18.

In this example, the expression evaluates as described in the following syntax:

"[Account.Id] = [Contact.Account Id]"

Example of Defining a Siebel Operation Search Specification

An expression for a search specification can be defined with compound expressions and substitutions from process properties or fields.

For example, consider the following generic syntax:

"([Field1] > '" + [&Process Property Name] + "') OR ([Field2] IS NULL) OR ([Field3] IS NULL)"

This syntax can be translated to:

([Field1] > 'value') OR ([Field2] IS NULL) OR ([Field3] IS NULL)

Expressions that now include literal representations of the business component fields, where 'dFromDate' is a custom process property, include:

• "([Open] > '" + [&dFromDate] + "') OR ([Open] IS NULL)"
• "([Open] > '" + [&dFromDate] + "') AND ([Status] IS NULL)"

To view search specification usage in an example workflow, see Defining the Workflow Process.

For more information about using a process property as a substitution variable, see Referencing a Process Property.

Updating a Field That Resides in a non-Primary Business Component

You can update a business component field that resides in a non-primary business component. To update a field in a non-primary business component, one of the following conditions must exist:

• A join must exist between the base table for the primary business component and the field you need to update.
• A link must exist between the primary business component and the business component that contains the field you need to update.

For example, assume you need to update sales stage data in a workflow whose business object property is set to Opportunity. The predefined Sales Stage join on the opportunity business component provides the capability to update the sales stage field.

Considerations to weigh when using joins and links include:

• If a predefined join or link does not exist, you can create one.
• In some cases, to update a field in a non-primary business component, you can choose to copy an existing business object then specify it in the business object property for a workflow process. If you choose a different business component as the primary business component for this business object, then you must make sure link or join information specified for that business component is removed or corrected. Otherwise, an error can result.

For more information, see Defining a Primary Business Component for a Business Object. For more information about modifying joins and links, see Configuring Siebel Business Applications.

Updating a Field That is Based on a Multi-Value Group

If you need to update a business component field that is based on a multi-value group, you can define a business component for the field then link the business component to the object using Siebel Tools.

For example, assume you need to update the Account Team business component field. Account Team is based on a multi-value group, so it cannot be updated by choosing the Account business component. However, you can create a business component called Account Team, then associate it with the Account business object using Siebel Tools. You can then choose Account Team as the business component to update with the Siebel Operation step.

For more information about multi-value groups, see Configuring Siebel Business Applications.

Updating a Calculated Field

A Siebel Operation step cannot be used to update a calculated field because typically the calculated field requires values from other business component fields. Instead, use an expression to perform calculations.

Using the Siebel Operation Step to Traverse a Record Set

The NextRecord, PrevRecord, and QueryBiDirectional operations on the Siebel Operation step can be used in conjunction with the Update, Query, and Insert operations to traverse a record set.

Using NextRecord and PrevRecord, you can navigate through the records of a child business component of the business object associated with the workflow:

• The NextRecord operation changes the active row of the target business component to the next record in the current workset.
• The PrevRecord operation changes the active row to the previous record.

You must perform a query on the target business component before using subsequent Next/Previous Record operations. If the workflow is traversing active records or if your workflow uses the PreviousRecord operation, query bidirectionally. Otherwise, use the standard Siebel query operation.

NextRecord, PrevRecord, and QueryBiDirectional cannot be used to navigate through records of the primary business component. These operations are designed to navigate records of a child business component in a workflow process. Therefore you must use a child business component.

To see a detailed example that uses the traversing a record set technique, see Example Workflow Process That Traverses a Record Set to Close Obsolete Service Requests.

Output Arguments Used With Traversing a Record Set

When you use Next Record and Previous Record to traverse records of a child business component, an output argument called NoMoreRecords in the Siebel Operation is set to TRUE when the Siebel Operation attempts to read the next record but finds there are no more records in the record set to traverse. NoMoreRecords is set to TRUE in the forward direction for Next Record or in the backward direction for Previous Record.

NoMoreRecords can be assigned to a process property, and in conjunction with a Decision Point, can be used to exit the loop after navigating through every record in the record set. To support this output argument, the Process Designer displays an Output Argument column in the output arguments tab for the Siebel Operation step.

Another output argument, NumAffRows (number of affected rows) exists for Query, Update and Upsert operations:

• When used with Query, NumAffRows provides the number of rows returned as a result of the query.
• When used with Update and Upsert, NumAffRows provides the number of rows updated.

Using the Siebel Operation to Update a Process Property

You can create a test workflow process that updates a process property. This technique can be useful during development. For example, you can take the sum of two business component integer fields that provide input to a decision downstream in the workflow process. By updating a process property in the Siebel operation step with the sum of the two required fields, you can use this property on a subsequent branch connector.

To create a test workflow that updates a process property

1. In Siebel Tools, create a new workflow process object definition using values described in the following table:

   Property	Value
   Process Name	Updating a Process Property
   Business Object	Action
   Workflow Mode	Service Flow

   To view an example, see Creating a New Workflow Process Object Definition.

2. Add steps and connectors until your workflow process resembles the workflow illustrated in the following diagram:

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

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

   Argument Field	Value
   Name	Custom Process Property
   Display Name	Custom Process Property
   In/Out	In/Out
   Business Object	Action

   For more information, see About Process Properties.

5. Click the Update Process Property step, then click the Search Spec Input Arguments tab in the MVPW.
6. Right-click, choose New Record, then define a new record using values described in the following table:

   Argument Field	Value
   Expression Business Component	List of Values
   Filter Business Component	Query
   Search Specification	[Name] = 'Personal' AND [Type] = 'TODO_TYPE'
   Type	Literal

7. With the Update Process Property step still chosen, click the Output Arguments tab in the MVPW.
8. Right-click, choose New Record, then define a new record using values described in the following table:

   Argument Field	Value
   Property Name	Custom Process Property
   Type	Expression
   Value	[Class Code]
   Business Component Name	List Of Values

9. Validate then Simulate the workflow process.

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

10. Implement this technique in your production workflow.

About the Siebel Operation Object Id Process Property

After executing an Insert or Upsert operation, the Siebel Operation Object Id process property automatically stores the row ID of the record that was created. The Object Id for the process is automatically passed to Siebel Operation steps. Because this automatic passing occurs, it is not necessary to define a search specification unless you are updating child records. For example, if you have a workflow process based on the service request business object and you need to update the service request, it is not necessary for you to enter a search specification. However, if you need to update activities for the service request, you can enter a search specification to query the specific activity you need to update. Otherwise, the update step updates every activity associated with the service request.

The Object Id cannot be null if you are executing a Siebel operation, unless you are inserting into the primary Object Id. If the process has no Object Id, the Siebel Operation step returns an error.

Values returned by the Siebel Operation Object Id process property when performing a query operation for child records include:

• The row ID if one record matches.
• Null/no value if no records match.
• An asterisk (*) if multiple records match. Provided to distinguish from values that return a unique record or no record. Typically, either a unique record matches or no records match. In most cases, multiple records will not match and an asterisk will not be returned.

The only option returns a row ID of a matching row.

The Insert, Update and Upsert operations update the Siebel Operation Object Id process property of the record's row ID.

About the Upsert Operation on the Siebel Operation Step

The Upsert Operation provides a way to perform either an insert or update operation based on whether a record or records exist in the database. Hence the name, Upsert. The operation can perform update or insert operations.

For example, assume you have a search specification on a Siebel Operation step that queries the database. Table 19 describes how Upsert works.

Examples Where Upsert is Useful

In the Siebel client, assume the user is taken to a view where the user clicks a checkbox to create a new contact then enters the relevant contact information. Assume the Yes default for the checkbox creates a new contact record. If the user creates a new contact, navigates away from the view, then returns to the view, when the user returns there is the potential that another contact is created. In this example, an evaluation must be made whether the contact already exists or not. If a record does exist, then the contact record must be updated. If the record does not exist, then a new contact record must be created.

In another example, assume a workflow runs in the background at midnight, processing orders submitted from an external system. If a given order does not exist, Upsert creates a new record. If a given order already exists but must be updated, Upsert updates the record.

About the Relationship Between a Siebel Operation and Siebel Object Layers

Workflow Policy programs and Siebel Operation steps use different object layers to update data. For example, you can have a workflow policy that calls a Workflow Policy program to update a Service Request record. This technique goes through the data layer, where the state model does not apply.

Conversely, if you have a workflow policy that calls a workflow process action and in the workflow process you have defined a Siebel Operation step to update a Service Request record, this technique goes through the object layer, where the state model does apply.

Defining a Primary Business Component for a Business Object

The business object defined for a workflow process must have a primary business component defined in Siebel Tools.

To designate a primary business component for a Business Object

1. In Siebel Tools, in the Object Explorer choose the Business Object object type.
2. In the Business Objects OBLE, choose the business object to be modified.
3. In the Properties window, use the picklist in the Primary Business Component property to pick the appropriate component name.

   Configure a primary business component by choosing the key business component for the specific business object.

4. Compile the SRF.

Once a primary business component is defined, the business object appears in the Workflow Processes list editor.