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-00212Hello,
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
.
No comments:
Post a Comment