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

.

חפש בבלוג זה

siebel