SBL-BPR-00212: Invalid parameters used to request creation of new workflow instance.

Applies to:

Product Release: V7 (Enterprise)


Version: 7.7.2 [18325]


Database: Oracle 9.2.0.4


Application Server OS: Microsoft Windows 2000 Server


Database Server OS: Sun Solaris 2.8





This document was previously published as Siebel SR 38-1642446131.


Symptoms

SBL-OMS-00107, SBL-SRB-00047, SBL-SRB-00061, SBL-BPR-00212

Hello,

Please review VerioVEAWrkFlwMon_15388.log that I am attaching. I have also

included the logs around that one just in case....

I am looking for guidance b/c I cannot

find any on supportweb. We have recently upgraded from 7.5.2 and this workflow works there, but

it does not work in our test or dev 7.7.2 envrionment. The wfprocmgr works on it until it is done

retrying and then moves on. I am in the process of troubleshooting and I will update this as I

discover new info.




Solution

Message 1

For the benefit of other readers:





From further investigation into the log files, the logs revealed that when the Workflow Monitor Agent calls the workflow process, the Workflow Process Manager runs the workflow process and then the business service within this workflow process calls a secondary workflow, passing in the Workflow Process Name and Row-Id of the account as the inputs for the secondary workflow process. From the WfProcMgr log file that was generated, it seems that the business service did invoke the 2nd workflow, but the 2nd workflow did not receive a value for the RowId argument. Here is the essential part of the log file:





StpExec    Task    4    663430    2004-12-14 01:11:16    Invoking method 'PublishAccountComInvoiceProfile' on business service 'Verio Publish Account'.


StpExec    TaskArg    4    663430    2004-12-14 01:11:16    Input: @0*0*2*0*0*0*13*WFProcessName23*Verio Output XML to VEA12*InvProfileId8*1-1JE306


ObjMgrBusServiceLog    InvokeMethod    4    663430    2004-12-14 01:11:16    Begin: Business Service 'Verio Publish Account' invoke method: 'PublishAccountComInvoiceProfile' at 35c36800





// Workflow Process1 calling the custom business service, which calls another workflow process "Verio Output XML to VEA": ....








[1/6]


Message 2

[2/6]








EngInv    EngInv    3    663466    2004-12-14 01:11:16    Workflow engine requested to perform method 'RunProcess'.


EngInv    Arg    4    663466    2004-12-14 01:11:16    Input: @0*0*2*0*0*0*11*ProcessName23*Verio Output XML to VEA5*RowId0*


PrcExec    PrcExec    3    663466    2004-12-14 01:11:16    Executing process definition 'Verio Output XML to VEA'.


PrcExec    Create    4    663466    2004-12-14 01:11:16    Instantiating process definition 'Verio Output XML to VEA'.





// Here we can see the the 2nd workflow is executed in the same thread as the first one because the call to the secondary workflow is using "Workflow Process Manager" service which runs in local synchronous mode to the caller (which is workflow process # 1). However, what we observe is that "Verio Output XML to VEA5" was started, but it did not receive any value for the RowId argument. Then, the workflow process calls the 'Get Acct Txn Info' step, which calls the 'EAI Siebel Adapter' with these inputs:





StpExec    TaskArg    4    663467    2004-12-14 01:11:17    Input: @0*0*2*0*0*0*12*PrimaryRowId0*19*OutputIntObjectName11*VeaCustomer


ObjMgrBusServiceLog    InvokeMethod    4    663467    2004-12-14 01:11:17    Begin: Business Service 'EAI Siebel Adapter' invoke method: 'Query' at 13f22fb8





......


Message 3

[3/6]








We see here that the 'PrimaryRowId' also does not have a value and in the log file, this is the last step, but the log shows that the 'EAI Siebel Adapter' did a null query and issued select statements against every Account in the database, this accounted for why customer saw the log file was growing to over 100MB in size.





Siebel Support received the customer's custom business business service and two workflow processes for testing, and was able to reproduce the same behaviour where workflow process # 2 was started but it did not receive any value for the RowId and thus failed to execute the rest of workflow process # 2's logic.





Since the secondary workflow process was called/launched from the custom business service, the culprint was within the custom business script. When using the Siebel Tools Debugger and Watch Window to step through the lines of code in the business service method, this revealed the source of the problem from the script, (please see the comments "<--" next to the code):





var objAccountBO = TheApplication().GetBusObject("Account");


var objInvProfileBC = objAccountBO.GetBusComp("Com Invoice Profile");





    objInvProfileBC.SetViewMode(AllView);


    objInvProfileBC.ActivateField("Row Id");


    objInvProfileBC.ClearToQuery();


    objInvProfileBC.SetSearchSpec("Row Id", strInvProfileId);


    objInvProfileBC.ExecuteQuery(ForwardOnly);


    brsInvProfileRecord = objInvProfileBC.FirstRecord();





    ....


    ....


Message 4

[4/6]








    inputpropset.SetProperty("ProcessName", strWFProcess);





    // Get Row_Id of selected Account


    objInvProfileBC.ActivateField("Account Id");        // <-- this line being here is the culprit


    strAccountID = objInvProfileBC.GetFieldValue("Account Id");


    inputpropset.SetProperty("RowId", strAccountID);





    // Submit the request


    SrvrReqsvc.InvokeMethod("RunProcess", inputpropset, outputpropset);


.....


.....





Whenever using ActivateField(), it will destroy the context of the results set from the previous query. Thus, ActivateField() should only be used with ExecuteQuery(). Once the problematic line of code "objInvProfileBC.ActivateField("Account Id");" was moved into the block of code for the search/query, the script ran correctly and the 'strAccountID' variable was set to a value, which was then passed to and received by the secondary workflow process as the "RowId". So, the 2 changes to the custom script would be:





1. Activate the "Account Id" field in the block of code that does the query, the script should look like this:





    objInvProfileBC.SetViewMode(AllView);


    objInvProfileBC.ActivateField("Account Id");


    objInvProfileBC.ActivateField("Row Id");


    objInvProfileBC.ClearToQuery();


    objInvProfileBC.SetSearchSpec("Row Id", strInvProfileId);





.....


Message 5

[5/6]








2. Remove the .ActivateField("Account Id") line from here, the script should look like this:





    // Get Row_Id of selected Account


    strAccountID = objInvProfileBC.GetFieldValue("Account Id");


    inputpropset.SetProperty("RowId", strAccountID);





Customer applied these changes to their script and the secondary workflow process is now able to execute correctly to completion.





The usage and effect of the "ActivateField()" method can be found in the Siebel Bookshelf > Siebel Object Interfaces Reference Version 7.7, Rev. A > Interfaces Reference > Business Component Methods > ActivateField Method > Usage:





" After a business component has been executed, if additional fields are activated, the business component must be requeried before field values can be accessed. Failure to requery the business component results in a value of 0 being returned. The ActivateField method destroys the context of a query when it is used after the ExecuteQuery method.





The ActivateField method forces the specified field to be included in the SQL statement that is initiated by an ExecuteQuery method that follows. ActivateField should always be followed by ExecuteQuery. If a field is activated and then referenced by a GetFieldValue or SetFieldValue statement prior to an ExecuteQuery statement, the activation has no effect. The activated field is not


retrieved through a query, so it contains an empty value. "





......


Message 6

[6/6]








Search keywords:    workflow, process, script, business service, missing, input, argument, RowId, value, method, ActivateField(), ActivateField, query, search, specification, expression, 0, zero, null, results, return, SetSearchSpec, GetFieldValue, GetFieldValue(), SetProperty





.






תגובות

הוסף רשומת תגובה

פוסטים פופולריים מהבלוג הזה

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 Prima
המשך לקרוא

Profile Attributes and Open UI

תמונה
Yes, Profile Attributes! As the ever attentive, up-to-date Siebel CRM expert that you are when you read this, you know that in Siebel Open UI (since version 15), it is no longer allowed/supported to  set  Profile Attributes from browser-side script. But  getting  them is not a problem, since the  GetProfileAttr  function works perfectly fine. Recently I found a few vanilla Profile Attributes that came quite handy in my work in Open UI JavaScript: Navigation Type : stores the navigation type such as "NAVIGATION_TAB" ActiveViewName : does what it says on the tin IsOpenUI : returns "1" when the application runs in Open UI Is SUI Theme : when "TRUE", the application theme is Synergy (aka SUI) Position:  returns the currently active position Primary Responsibility Name : guess what this one is… Profile Image : returns the URL of the user's profile image Org.Name : returns the name of the user's organization Here's a sample line of
המשך לקרוא

FINS Data Transfer Utilities

תמונה
The best thing while working on siebel is you are never short of options. Recently we had requirement of updating a Service request from contact. Finally we did that using "EAI Siebel Adapter" business service. However during that time i came across another business service "FINS Data Transfer Utilities" popularly known as DTU business service. As i was not having prior knowledge of it going by the rule of not learning swimming lessons while drowning i decided not to go for it. Lately i have tried to explore this service and trust me it can do wonders. Here is a sample example update of Service Request from contact. We need to follow below steps in order to understand strength of this business service. 1 - Navigate to Site Map. Go to Administration - Application -> Data Map Administration tab. Create a new Record with following options: Name: Service Request Test Source Business Object: Contact Destination Business Object: Service Request Here the source business
המשך לקרוא