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)
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)
