Siebel Workflow - Updating Multiple Records
- Ibrahim
- Jan 20, 2016
- 4 min read

So I am unable to update multiple records in a Siebel workflow with just Siebel Operation steps. When I asked Siebel about this they specified (same as Henrick Ohm – thanks for comment Henrick) to use WfProcBatchMgr passing in the Search Specification so that the workflow will be executed for each record returned. This is the best method to use for my scenario. However there are situations where you would need to update multiple records in a workflow executed just once. I wanted to get to the bottom of this problem.
I finally determined that it is possible to update multiple records with a Siebel Operation Update step if you firstly query the Primary BC of the BO of the Workflow and this record returns a record. Then the workflow can update multiple records on other BCs under the BO of the Workflow. So for the following example (from my previous post):
Update all S_SRM_REQUEST records update the STATUS to QUEUED where STATUS = 'ERROR' AND COMPLETION_TEXT = 'SBL-SMI-00216: Internal: Not an error, all the threads are busy'
This could be achieved in a single workflow as such:
Add the CIS S_SRM_REQUEST 1 BC under the Contact BO with no link specified.
Business ObjectWorkflow Mode
ContactService Flow
The workflow has a Start step connected to a Query (Siebel Operation) step which is connected to an Update (Siebel Operation) step which is connected to an End step.
Query Step
NameOperationBusiness Component
QueryQueryContact
Search Spec Input Argument:
Expression BCFilter BCTypeSearch Specification
ContactExpression"[Id]='0-1'"
Output Argument:
Process PropertyTypeOutput Argument
Record CountOutput ArgumentNumAffRows
Update Step
NameOperationBusiness Component
UpdateUpdateCIS S_SRM_REQUEST 1
Search Spec Input Argument:
Expression BCFilter BCTypeSearch Specification
CIS S_SRM_REQUEST 1Expression"[Status] = 'ERROR' AND [Completion Text] = 'SBL-SMI-00216: Internal: Not an error, all the threads are busy'"
Field Input Arguments:
Field NameTypeValue
StatusLiteralQueued
Output Argument:
Process PropertyTypeOutput Argument
Record CountOutput ArgumentNumAffRows
Note the following for the above workflow:
- The Contact BO is used for the workflow as Contact is the primary BC of the BO. The initial query on Contact uses search expression [Id] = ‘0-1’, this search expression will always return a record because 0-1 is the Id of Siebel Administrator contact. If the Query step on the Primary BC of the BO does not return a record then the workflow will throw the following error:
No Primary Row found in 'Contact' for Siebel Operation.(SBL-BPR-00101)
- I could have left the Query step without a Search Expression, this would have done a query of all records in the Contact BC. This is undesirable because a query of all records on Contact BC has a performance hit on the workflow. Therefore I wanted to query to return only one record as fast and index efficient as possible.
- The CIS S_SRM_REQUEST 1 BC is added under the Contact BO with no link. This allows us to query the BC for all records under the Contact BO as there is no link to restrict the records returned.
- I used just a single Siebel Operation Update step to perform the query of S_SRM_REQUEST records and update these in one step. This functions the same as having a Query step before it with the search expression and an Update step after it that just has the field updates. Because an Update step that has no search expression defined will inherit the search expression from the previous step. I did it in one single step for ease of readability and maintainability.
- If the Object Id is passed into this workflow then the Query step will automatically treat the passed Object Id as a user search spec and will perform the Query step search expression on this Object Id. If the Id passed in does not exist in Contact BC then the No Primary Row found error will occur. As this workflow is executed as a task there is no need to pass the Object Id in and the default search expression is used.
- For the Search Spec Input Arguments, I left the Expression Business Component blank and populated the Filter Business Component. The Filter Business Component specified what BC is used to represent the left side of the Search Expression. For example: [Id] = ‘0-1’, the Filter Business Component specifies what BC [Id] comes from. The Expression Business Component should not be populated for this case because a literal is used on the right side or the Search Expression.
- If you use the Primary BC of a BO to perform the Update step in a workflow, the Update step will only ever update the first record and no more. This is because workflow is designed to operate on a single record in the Primary BC of the BO of the workflow.
- Even though the Siebel Operation step Update is a single Workflow step to update all records returned by the search expression. It will perform a separate SQL Update for every record returned by the search expression. Rather than just performing a single SQL Update for each record returned. It is unfortunate that Siebel is not yet sophisticated enough to do the most efficient SQL of a single SQL Update.
I cannot determine how the implementation of a workflow without a query on the Primary BC of the BO of a workflow will not cause the No Primary Row found.... The following article was created based on Siebel 8.1 which says this is possible:
http://siebel-essentials.blogspot.com/2008/12/workflow-made-simple-part-i-update.html
I am using Siebel 8.0 for the above solution and could not get the workflow to work otherwise.
Kommentarer