Siebel: Purge Workflow Instance Monitor Data

The first step to debug a workflow process in the runtime environment is by increasing the "Monitoring Level" of the workflow process in Administration Business Process > Workflow Deployment > Active Workflow processes view.
When Siebel CRM creates a workflow process instance, it reads the monitoring level from the workflow process. This level remains constant throughout the lifetime of the instance unless Siebel CRM pauses it. If Siebel CRM pauses an instance, then it rereads the monitor level from the workflow process when it resumes this instance.

The "Monitoring Level" has 5 values:

0 - None
1 - Status
2 - Progress
3 - Detail
4 - Debug

Depending on what value is selected for a workflow process, the amount of data collected varies as described below:

Once, the workflow process is executed, we can view the results in the Administration Business Process > Workflow Instance Monitor view.
All the data related to the Workflow Process Instance, Workflow Step Instance and Workflow Process Properties Instance are recorded in their respective tables which are:

Workflow Process Instance Monitor  =  S_WFA_INST_LOG
Workflow Step Instance Monitor  =  S_WFA_INSTP_LOG
Workflow Process Properties Instance Monitor  =  S_WFA_STPRP_LOG

If there is no need to monitor the process at all, set the value "0 - None" which prevents any data to be written into these tables.
If the workflow processes that the monitoring is set on are frequently executed, the amount of data written can be excessively large. Therefore, it is possible that the size of the above tables may increase to several gigabytes of data.
If monitoring level is enabled, regularly use the "Purge" button located in Site Map > Administration - Business Process > Workflow Instance Monitor >   Process Instances applet, to keep only the relevant data in these tables.

If due to incorrect settings of the "Monitoring Level" leads to the tables reaching very critical stage and also could lead to the database failure. In that case, purging may not help to recover and the 3 tables have to be entirely cleared directly connecting to the database.

Siebel: How to convert a long running Web Service call to Asynchronous

We often have Siebel inbound web services, which take a lot of time to complete and finally time out.
We can create a web service which will accept the request for processing and then free the client instead of waiting for a response.

The basic thought is to convert the Synchronous call to an Asynchronous call.

Assume we have a workflow "Create Contact wf" which takes a long time and we want to call it Asynchronously.
We create a wrapper workflow in which we call a custom business service.
This custom business service will have the code to invoke "Server Requests" and submit a WfProcMgr job to run "Create Contact wf" asynchronously.
"Server Requests" business service can be used to submit a job to Workflow Process Manager Component (or any other component that accepts jobs) with one of the asynchronous modes: DirectDb / Async / Schedule
Find more details on how the Asynchronous server requests work here






Below is the sample code for the custom business service to take a workflow process property named "ContactIO" containing an IO named "EAI Contact" and pass it to an inner workflow that is called asynchronously and which has the same input process property "ContactIO" also containing an IO named "EAI Contact".


function Service_PreInvokeMethod (MethodName, Inputs, Outputs)

if (MethodName == "CallAsynchronousWf")
{

// instantiate the Business service "server requests" 
var svc = TheApplication().GetService("Server Requests"); 

// create the variables for "server request" Business service input and output

var SRBSInputsPS= TheApplication().NewPropertySet(); 
var SRBSOutputsPS= TheApplication().NewPropertySet(); 

// set the input arguments for the "Server Requests" business service

SRBSInputsPS.SetProperty("Component", "WfProcMgr"); 
SRBSInputsPS.SetProperty("Method", "RunProcess"); 
SRBSInputsPS.SetProperty("Mode", "Async"); 


// set the inner workflow input and output
// the top level of inputs is empty 
// child 0 is the IO instance

var wfInputsPS =  Inputs.Copy();
wfInputsPS.SetProperty("ProcessName", "Create Contact wf"); 

/***********************
you have to set the type of the propertyset at the level where the integration object starts as the workflow process property name, so the workflow is able to read the integration object and you do not get the error  "Input message is missing header properties.(SBL-EAI-04024)".
To make it simple, name the processproperty the same name as the IO.
********************/
wfInputsPS.GetChild(0).SetType("ContactIO");

var wfOutputsPS = TheApplication().NewPropertySet();

// workflow inputs is the IO instance and the process name and is a child of Server requests business service input.
SRBSInputsPS.AddChild(wfInputsPS); 

// invoke the  workflow 
svc.InvokeMethod("SubmitRequest", SRBSInputsPS, SRBSOutputsPS);

}
return (CancelOperation);
}

Siebel: Workflow Monitor Agent

Workflow Monitor Agent is a Background mode server component in the Workflow Management component group.

In the entire Siebel architecture, we should enable only 1 monitor agent for one Workflow Policy Group however we can have different Monitor components each monitoring different Workflow Policy Groups.

When a Workflow Policy condition is met, a record is created in the S_ESCL_REQ table.

Below is a sample illustration of a record in the S_ESCL_REQ table:

where:

BT_ROW_ID is the value of the ROW_ID of the record which violated the policy condition.

GROUP_ID is the ROW_ID of the Policy Group.

RULE_ID is the ROW_ID of the Workflow Policy.

TBL_NAME is the Table name to which the record belongs to.

REQ_ID is an incremental sequence number which defines the sequence in which the Monitor Agent processes the records from the S_ESCL_REQ table.

Each Monitor agent is assigned to monitor a single Workflow Policy Group which is controlled by the component parameter "Group Name".

As the Workflow Monitor Agent component is a Background mode component, we want a task to be created as soon as the component is started to monitor the S_ESCL_REQ table for any Policy violations for the respective Policy Group.

To Achieve this, we set the parameter "Default Tasks" = 1.

The task will initially load the rules that belong to the Workflow Policy Group.

It will issue an SQL to get all the records from the S_ESCL_REQ table for the specific GROUP_ID and sorting by the REQ_ID. It looks like below:

select 

T1.REQ_ID,

T1.BT_ROW_ID,

T1.RULE_ID,

T1.TBL_NAME,

T1.CREATED_BY,

T1.CREATED

from

SIEBEL.S_ESCL_T1 T1

where

T1.GROUP_ID = '1-2E299'

order by T1.REQ_ID

Then, Workflow Monitor Agent will process each record for each Policy. First, it queries the record in the database if the Policy Condition is still valid. 

Ex: assume in the above example, the Policy Condition is "Activity Type" = "Alert"

Siebel will run a SQL like below to check if the record is still valid to process:

SELECT

T0.ROW_ID

FROM

SIEBEL.S_EVT_ACT T0

WHERE

T0.TODO_CD = 'Alert' AND

T0.ROW_ID = '1-2IKAG'

Once, Workflow Monitor Agent gets a record, it is good to process the record and invoke the Action defined in the Workflow Action for the specific Workflow Policy.

But, before doing this, Monitor Agent will check if the record exists in the S_ESCL_LOG.

The parameter "Action interval" defines when actions for a Policy are re executed for a record. This parameter limits the number of times Policy Actions are executed if the record keeps going in and out of the matching condition.

The default value for "Action interval" = 3600 (secs)

So, if a record is already processed in the previous 1 hr, then Monitor Agent will not process the record again in S_ESCL_REQ table.

This is checked by the Monitor Agent, by issuing the below SQL:

select

T1.VIOLATED_DT

from SIEBEL.S_ESCL_T1 T1

where T1.RULE_ID || null = '1-2IKAG' and

T1.BT_ROW_ID  = ? and

T1.VIOLATED_DT > current_date - to_number(?)/86400

After this, the Workflow Monitor Agent will invoke the Policy Action.

If the Policy Action errors out, then the Workflow Monitor Agent will get stuck and does not go forward. If the Policy Action is successful, it will move to the next record in the S_ESCL_REQ table.

Note: Workflow Monitor Agent will not Insert the record in S_ESCL_LOG table and delete the record from S_ESCL_REQ table yet.
Workflow Monitor Agent has a parameter "Requests"  which controls the maximum number of rows processed from the S_ESCL_REQ table in each iteration. Between iterations, the Workflow Monitor Agent component will delete requests from the S_ESCL_REQ table and commits and will also optionally sleep in between.
The default value for the parameter "Requests" = 5000.
It means, even though there are 20,000 records waiting to get processed in the S_ESCL_REQ table, Workflow Monitor Agent will process it in iterations of 5000 records each.
Assume the 6001 th record is a failure case.
Workflow Monitor Agent component will process the first 5000 record successfully and then after iteration1 is completed, it will remove the 5000 rows from S_ESCL_REQ table and insert these 5000 rows in S_ESCL_LOG table.
Then it starts iteration2 from 5001th record. It will complete processing the 1000 records from 5001th to 6000th records. Then it will encounter error while processing the 6001th record and will get stuck.
If you observe, you can see in the Siebel application, the 1000 records are successfully processed, but the rows still exist in S_ESCL_REQ table and no corresponding rows in S_ESCL_LOG table.



The insert statement to S_ESCL_LOG table will look like below:

insert into SIEBEL.S_ESCL_LOG (
ROW_ID, CREATED, CREATED_BY, LAST_UPD, LAST_UPD_BY, MODIFICATION_NUM, CONFLICT_ID, RULE_ID, BT_ROW_ID, TABLE_NAME, VIOLATED_DT, USER_KEY, RULE_NAME)
values (?, current_date, ?, current_date, ?, 0, '0', ?, ?, ?, current_date, ?, ?)

The delete statement from the S_ESCL_REQ table will look like below:

delete from SIEBEL.S_ESCL_REQ
where
REQ_ID = '221127'

The "Sleep Time" determines the time the Workflow Monitor Agent component sleeps once it has finished processed the records. This affects the performance and the responsiveness of the component.
The default value of the parameter "Sleep Time" = 60 (secs)

Siebel Error: SBL-BPR-00158: Cannot execute workflow process definition 'xxx-xxxxxx' because it either does not exist, it is not Active, it has expired, or it was recently updated and re-published using a different Row ID.

This error will mostly occur when you Activate a workflow process and there are runtime events events defined for the same workflow process for an older version of it.

We need to identify the exact Action set that is called and the Event.
To get these details, the easy way is to increase the log level for the Object Manager component.

In the logs, you will easily find the error message, if you query with the error code "SBL-BPR-00158"






Below is an example of one such error:

SBL-BPR-00158: Cannot execute workflow process definition '0CM-1E4CZK' because it either does not exist, it is not Active, it has expired, or it was recently updated and re-published using a different Row ID.

Now Query for the exact Process Id from the logs, in this case it is '0CM-1E4CZK'

This will result in a statement from the log file, which looks something like below:

Input: @0*0*5*0*0*0*7*EventId7*0-8FJJK9*ProcessId10*0CM-1E4CZK9*Sub Event23*EventMethodPMTConfigure10*Event Name12*InvokeMethod6*StepId10*0CM-1E4D42

From this, we know the Event Id = "0-8FJJK"

Navigate to Administration - Runtime Events>Events view.
and Issue a query like below in any of the list coulmns to query for the record:

[Id]='0-8FJJK'

From the above example, the Action Set = "Workflow_0-8FJJJ
Drilldown on the Action Set to navigate to Administration - Runtime Events>ActionSets view.
From the below image, you can clearly see the Id of the erroring workflow in the action.
Just Inactivate the record and do "Reload Runtime Events"

Siebel: Increase Tracing for Workflow Process Manager and Workflow Process Batch Manager

Workflows in Siebel can be run in the below ways:

• Server Component: Workflow Policy, Repeating component request, srvrmgr, submitting a task for the component, eScript (submitting request for the component), Runtime events (submitting request for the component). In all the above ways, the request for the Workflow process execution is done by the Workflow Process Manager component (WfProcMgr) or the Workflow Process Batch Manager (WfProcBatchMgr) component.
• Application Object Manager:  Runtime event, Scripting and simulation in the Thin Client.
• Client: Runtime event, Scripting and simulation in the mobile web Client or the Dedicated Client.

Tracing on Server:

Increase the Log level for the below events for the Workflow Process Manager component (WfProcMgr) or the Workflow Process Batch Manager (WfProcBatchMgr) component.

Event Type	Log Level
Task Configuration	5
Object Manager SQL Log	5
Workflow Definition Loading	5
Workflow Engine Invoked	5
Workflow Process Execution	5
Workflow Step Execution	5
Object Manager Business Component Operation and SetErrorMsg Log	5
Object Manager Extension Language SetErrorMsg Log	5
Object Manager Business Service Operation and SetErrorMsg Log	5
SQL Tracing	5

The changes will take effect immediately and does not need a server bounce.The Workflow Process Batch Manager log file (WfProcBatchMgr_xxx.log) and the Workflow Process Manager log file (WfProcMgr_xxx.log) are located in the SIEBSRVR_ROOT\log directory.

Tracing on the Application Object Manager:

Increase the log level for the below for the Application Object Manager component like the Callcenter Object Manager.

Event Type	Log Level
Task Configuration	5
Object Manager SQL Log	5
Workflow Definition Loading	5
Workflow Engine Invoked	5
Workflow Process Execution	5
Workflow Step Execution	5
Object Manager Business Component Operation and SetErrorMsg Log	5
Object Manager Extension Language SetErrorMsg Log	5
Object Manager Business Service Operation and SetErrorMsg Log	5
SQL Tracing	5

The changes do not need a server bounce and the log for the application Object manager is generated at SIEBSRVR_ROOT\log directory.

Tracing on the Client:

Set the below environment variable and the siebel.log will be generated in <ClientRootDir>\log directory

SIEBEL_LOG_EVENTS = 5