SBL-BPR-00191: The rowId of the active row of the primary buscomp '%1', '%2', does not match the Primary Id
Applies to:
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157] ESN
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Server SP 3
Database Server OS: Microsoft Windows 2000 Server SP 3
This document was previously published as Siebel SR 38-1386997031.
Symptoms
SBL-BPR-00191
We have a error with a workflow.
This WF is excuted by policy when a particular activity
is closed. The WF Business Object is 'Action'.
Inside this WF, there is a subprocess that
invokes a Business Service that creates a new activity.
In a second subprocess, the region Id
of this new activity is updated using the standar update
method funcionality of Siebel
workflow process.
Error processing Siebel Operation for:
Business Object
'Action'
Business Component 'Action'
Primary Id ''1-5NEI6'
Operation
'Insert'(SBL-BPR-00100)
--
The rowId of the active row of the primary buscomp 'Action',
'1-4SNCV', does not match the
Primary Id (i.e., the 'Object Id' process property),
'1-5NEI6'.(SBL-BPR-00191)
SR 38-1161971008 has exactly the same problem, and a workaround
is given (updating de 'Object Id' property with value of the new activity before this is updated)
This update is made in the 'Obtener Region' step.
However, even doing this, the error
persists...
This workaround seems not work. Any suggestion?
Thanks in
advance,
Clemente
Solution
Message 1
For the benefit of other readers:
Customer's workflow process begins with an activity record that was passed by the workflow policy, this activity id was set in the Object Id process property. The workflow process then created a new activity and later updates a field on this new activity. During the update step on the new activity, the workflow process failed with the following error:
"The rowId of the active row of the primary buscomp 'Action', '1-4SNCV', does not match the
Primary Id (i.e., the 'Object Id' process property), '1-5NEI6'.(SBL-BPR-00191)"
Customer tried to workaround this by passing in the new activity id to a subprocess to do the update, but the same error message occurred as well.
Tech Support was able to reproduce the error message with customer's main and subprocess. The error occurs because the Workflow Engine held ROW_ID value from original activity as active row in memory, say Id X. Then, in the subprocess, a different Object Id value was used, say Y. Workflow Engine saw a conflict between what it had in memory as active row X with what it saw in subprocess Object Id Y.
[1/3]
Message 2
[2/3]
To work around this, what we need to do is force the Workflow Engine to requery against the primary business component to fetch a new row as the active row for the primary buscomp. This can be done by using a Siebel Operation Query against the primary business component, having the query use the implicit [Id] field against whichever process property that should be considered the active row.
This is better explained by describing the two workarounds tested by Siebel Support:
1. Put the Siebel Operation Query step in the main process before calling subprocess. Query against the primary business component using a Search Spec against the Action BusComp. The search spec should check for [Id] field to be that of the value for the new activity id (and not that stored in the Object Id). The search spec should use this expression:
BusComp Filter: Action
Type: Expression
Search Spec: '[Id] = ' + '"' + [&process property hold new activity row-id] + '"'
BusComp: Action
The Workflow Engine will submit this query and return the ROW_ID held in the process property and will then set it as the rowId of the active row of the primary buscomp.
Then, the workflow can proceed with the next step to call the subprocess to perform the update on the new activity successfully. This still assumes that main workflow process is passing value from the process property into subprocess' 'Object Id'.
....
Message 3
[3/3]
2. Using the same query approach in workaround 1, this option omits the subprocess and just moves the update step on 2nd activity into the main process as well. The flow of this process is:
Start workflow
> get field values / process property for original activity
> requery primary BC for new activity as active row as illustrated in approach # 1
> wait step to reset object id to new activity id
> Siebel update step to update new activity's field with search spec that '[Id] = ' + '"' + [&IdActividadNew] + '"'
> end
Search keyworks: workflow, operation, update, The rowId of the active row of the primary buscomp, does not match the Primary Id, engine, current, active, Object Id
.
Applies to:
Product Release: V7 (Enterprise)
Version: 7.5.2.215 [16076] Auto
Database: Oracle 8.1.7.4
Application Server OS: IBM AIX 5L 5.1
Database Server OS: IBM AIX 5L 5.1
This document was previously published as Siebel SR 38-1161971008.
Symptoms
SBL-BPR-00191
We have upgraded to patch 7.5.3.2. In Testing we have found a workflow that is no longer
working.
The step that is broken is in a creation of an Activity record. Here is a short
summary of what our workflow does:
1. An SR (SR#1) is created by the user and the workflow
is invoked.
2. After a number of other steps SR#1 is closed by workflow and a second SR (SR#2)
is created.
3. Then we create an activity that is associated to SR#2.
When workflow
tries to create the activity, we are getting the error that I have attached. It is getting
confused with the Id of SR#1 and SR#2.
What would cause this workflow to work in 7.5.2.215
and not in 7.5.3.2?
Solution
Message 1
For the benefit of other users, the behaviour reported is as follows:
A workflow process was developed to carry out the following steps:
Workflow Process is based on Service Request business object, gets a ROW_ID via workflow policy or can be triggered by a runtime event. Thus, the workflow process' initial Object Id value is set to the ROW_ID of the service request.
Workflow Process steps are: Start > created new SR with Insert Operation > create a new activity with with Insert Operation > End
The above workflow process steps worked properly on Siebel 7.5.2 and 7.5.2.x maintenance releases.
However, the same workflow process errored out on Siebel 7.5.3 and 7.5.3.x versions, with the following error:
Error updating business component at step 'Create Process Request Act'.(SBL-BPR-00187)
--
Error processing Siebel Operation for:
Business Object 'Service Request'
Business Component 'Service Request'
Primary Id '1-6GB'
Operation 'Insert'(SBL-BPR-00100)
--
The rowId of the active row of the primary buscomp 'Service Request', '1-UXX', does not match the Primary Id (i.e., the 'Object Id' process property), '1-6GB'.(SBL-BPR-00191)
[1/3]
Message 2
[2/3]
The above error message began to occur after installing Siebel 7.5.3 version. As of Siebel 7.5.3 forwards, some changes have been made to how the Siebel Workflow Engine handles the active row and the Object Id. The changes implemented is that, in an event that a new record is created by the Workflow Engine (via the workflow process), the Workflow Engine treats the new record as the active row and there are internal checks with the ROW_ID of the current active row and the value stored in the Object Id process property.
If the two values do not match, the above error message occurs.
The Workflow Engine will not automatically change the Object Id to match the current row, as doing this may cause unexpected and undesired behaviours. In some instances, the workflow process would always process on the same Object Id value and not the new ROW_ID value, where the new ROW_ID may just be a child record.
Thus, to ensure that the above error message does not occur, users would need to include additional checkpoints in the workflow process to set or reset the Object Id process property to the correct or appropriate value. This can be done by updating the Object Id value before doing the next operation.
....
Message 3
[3/3]
Methods to update the Object Id process property value within a workflow process are:
a. By specifying it in the Output Arguments applet of a Siebel Operation step.
b. Or, by using a Wait Step to set / reset the value in the Output Arguments applet.
The following Change Request has been logged included the above information into the documentation for future Siebel versions:
CR # 10472305: Document how Workflow Engine handles the active row as of 7.5.3 and how it compares with Object Id.
Search keyworks: workflow, operation, update, The rowId of the active row of the primary buscomp, does not match the Primary Id, engine, current, active, Object Id
.
Applies to:
Product Release: V7 (Professional)
Version: 7.5.3.5 [16183]
Database: Microsoft SQL Server 2000 SP 2
Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2000 Server SP 4
This document was previously published as Siebel SR 38-1737006771.
Symptoms
SBL-BPR-00191
I am creating a workflow process (which I've included with this SR) based upon SR Activities.
I'm evaluating for Activities of type Email-Outbound. If I find one, I have a Siebel Operation to
insert an Activity of type 'Info Request' associated with the same SR.
The problem I'm
running into is when the Siebel Operation is performed, the WF process looses the pointer to the
original Email-Outbound Activity, and is instead pointed to the newly created Activity. I then
try to test the original Activity for conditions, which always fail becuase the WF process is not
looking at the correct Activity. I've tried several things to get the Siebel Operation to set the
pointer to the original Activity. The last iteration consisted of making the Siebel Operation a
sub-process and setting Object Id and Siebel Operation Object Id properties the same as an output
to the subprocess. I've tested this by sending these values back to myself as an email, and they
both are pointing to the correct ROW_ID of the Email-Outbound activity, but the decision branch
is still evaluating the newly created Activity.
Solution
Message 1
For the benefit of other customers:
The behavior described is currently expected as per the design. The design may also result in the following error message depending on the workflow process.
The rowId of the active row of the primary buscomp 'Action', '1-UXX', does not match the Primary Id (i.e., the 'Object Id' process property), '1-6GB'.(SBL-BPR-00191)
The following workaround can be used to save the context of the record and have it consistent in the application memory during Siebel Operation steps:
a. Create a new Process Property in the WF process - ObId
b. Map ObId = Object Id in a Wait Step (in output arguments) after Start step
c. Insert new activity as per requirement (this may cause the new activity Id to be loaded into application memory instead of Object Id now)
d. Set Object Id = Siebel Operation Object Id in the Output Arguments applet of the Insert step above (this is to set Object id = Id in the memory of the process – this is to avoid the validation error above during execution)
e. Add a query step to query on ObId using a Search Specification expression:
'[Id] = ' + '"' + [&ObId] + '"'
(this is to refresh the application memory with the Original Object Id)
f. Reset Object Id = ObId in the output args applet in the same Query step above (this is to reset and keep the Object Id as original record for further Siebel Operation steps)
...
Message 2
...
Change Request # 12-T1W9VF has been logged to enhance the feature for better execution to avoid such workarounds.
Siebel Technical Support
Applies to:
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157] Fin Svcs
Database: Oracle 9.2.0.4
Application Server OS: Microsoft Windows 2000 Advanced Server SP 2
Database Server OS: IBM AIX 5L 5.1
This document was previously published as Siebel SR 38-1575430421.
Symptoms
SBL-BPR-00191
Hi,
We have a runtime event which is developed through a workflow process (WORKFLOW1),
this runtime event is triggered when a new activity record is created. We have another workflow
which is used to created a new activity record (WORKFLOW2), so everytime WORKFLOW2 creates a new
record WORKFLOW1 would be triggered.
This seems to work fine if the workflow WORKFLOW2 is
called through UI, however we receive an error message from WORKFLOW1 when we run WORKFLOW2
through Workflow Process Batch Manager:
Error updating business component at step 'Update
Planned Field'.(SBL-BPR-00187)
--
Error processing Siebel Operation for:
Business
Object 'Action'
Business Component 'Action'
Primary Id '""'
Operation
'Update'(SBL-BPR-00100)
--
The rowId of the active row of the primary buscomp 'Action',
'1-YSMH', does not match the Primary Id (i.e., the 'Object Id' process property),
'""'.(SBL-BPR-00191)
We've attached the workflows here for you to review. One thing we
noticed that when Siebel triggered the WORKFLOW1, it sets the Object Id twice. The first time it
set correctly but second time it set to null as
below:
PrcExec PropSet 4 2004-10-26
11:20:33 Setting runtime value of property 'Object Id'
to:
PrcExec PropSet 4 2004-10-26
11:20:33 1-YSMH
PrcExec PropSet 4 2004-10-26
11:20:33 Setting runtime value of property 'Object Id'
to:
PrcExec PropSet 4 2004-10-26
11:20:33 ""
Could you please have a look and let us know what has
gone wrong. Your prompt response is very much appreciated.
Thanks
Solution
Message 1
For the benefit of other customers:
To resolve the error message SBL-BPR-00187 , the following workaround was used:
When WFP Batch Manager runs, it loads the Primary BC and the record in the memory coming from Workflow2 before calling Workflow1. Then for some reason, WFP Batch Manager resets the Object Id to NULL. But since the server process thread has the record in the memory at that point, the Id can be retrieved from the memory again to reset the Object Id before performing update operation. To do so, add a Wait step after Start step to reset the Object Id in the Output Argument as:
Property Name: Object Id
Type: Expression
Value: [Id]
BC: Action
Change Request # 12-Q5DG10 has been logged for this behavior specific to WFP Batch Manager. The issue is not seen when the workflow is invoked from the GUI, script, workflow simulator or workflow process manager component using runtime events.
Siebel Technical Support
תגובות
הוסף רשומת תגובה