Session TimeOut

An idle mind is Devil's workshop...an orphaned session is inefficient resource allocation...

"SessionTimeout" is one of the parameters in the eapps.cfg that is more to do with competent usage rather performance. This specifies the time in seconds when the session times out in case of inactivity. The larger the value the longer it takes for the orphaned session to timeout. Orphaned sessions are undesirable beacuse they occupy AOM task slots preventing other users to use that slot.

There are instances when session never times out despite setting this parameter. Following parameters should be kept in mind before setting SessionTimeout parameter.

1 - "Application Message Bar Update Interval"

This parameter is used in Message Broadcasting feature. The value of this parameter should be set to greater than the SessionTimeout parameter.

2 - "Alarm Manager Load Frequency"

The "Alarm Manager Load Frequency" system preference determines how frequently the calendar alarm queries the server for alarm-enabled appointments. The value for this should be set to value greater than the Session Timeout Parameter.

3 - "PushKeepAliveTimer" and "ChannelCleanupTimer"

"PushKeepAliveTimer" is basically used in CTI configurations. The Value for this parameter in the Communication profile should be greater than SessionTimeout .

4 - CommReqTimeout(CTI)

This parameter is used in Communication toolbars. The value of this parameter should be less than the SessionTimeout parameter.

5 - Connidletime

This parameter helps session manager to close connections based on the time the connection remains idle. It is used in conjunction with third party load balancer. The value of this parameter should be greater than the session timeout parameter.

It is always better to specify the SessionTimeout parameter to a value which satisfies own requirement. This avoids dangling sessions and thus efficient resource allocation.

Have a great active year ahead...

"IS UPDATED" in Workflow Policy

Statuary Warning: This is not for the old horses.

My romantics with siebel goes on and so Siebel mysteries. Newbies better be careful while using "IS UPDATED" condition in the workflow policies. It can lead to undesirable/wrong results. Lets consider below problem statement.

"Any service request which is not worked within 2 hours of assignment, i.e. Assigned status , should be escalated."

The obvious solution which comes in mind is to configure workflow policy with duration and Owner Id update condition.

Unfortunately it didn't work for me. The issue when using "IS UPDATED" criteria in combination with Workflow duration is that criteria is considered only at the time of the first update by the user. Until the configured policy duration has completed, all subsequent updates to the record are discarded by Workflow Policy Manager. As a result at any point of time only one record is available in "S_ESCL_STATE" table for this policy. At the end of the configured duration, Workflow Policy Manager looks at the other configured criteria on the policy. If they evaluate to true policy Action is fired. If they do not evaluate as configured, then the record is discarded and the next time the record is updated a new record will is inserted into S_ESCL_REQ and subsequently, S_ESCL_STATE for the duration. At times, this may result in undesirable behavior as follow.

Lets consider we assign a SR to user A at 7:00 AM. As per our configured policy it should be escalated at 9:00 AM if status is "Assigned". User A works on this request and again re-assigns request to user B at 7:30. Now ideally escalation should happen at 9:30 AM and not at 9:00 AM. But if we check "S_ESCL_STATE" table there will be only one record for this policy with END_TM set to 9:00 AM. If user B doesn't work on this request till 9:00 then this request will be escalated resulting in unwanted escalation.

There are multiple workarounds for the above mentioned issue.

a) Workflow Batch processing

b) Batch workflow policies

One potential solution could be to maintain "Last Assigned" date field and set this to current timestamp whenever assignment/re-assignment is happening. Use this date in the searchspec to find records which are in assigned status for more than 2 hours. Create workflow Process Batch Manager RCR with following parameters:

SearchSpec: [Last Assigned] < (Timestamp() - 0.084)

WorkFlow: SR Escalation Workflow

This will process all records which are in Assigned status for more than 2 hours.

DVM on drilldown

Recently we encountered a scenario which involved certain validations on drilldown. The go to solution was to invoke DVM on drilldown method. Lets consider a basic example of SR list applet where we need to perform certain validations when user clicks on SR-Number. Following steps are required to achieve desirable.

1 - Create a DVM rule set with name "Test Orchestration". Add desired rules as per validation requirement.

2 - Create User Property on the SR business component with following values:

Name: Named Method 1
Value:"SRDrill", "INVOKESVC", "Service Request", "Data Validation Manager", "Validate", "'Rule Set Name'", "'Test Orchestration'", "'Enable Log'", "'Y'", "'Object Id'", "[Id]"

3 - Navigate to SR list applet and edit server side script. Add following code in PreInvokeMethod event :
if (MethodName == "Drilldown")
this.BusComp().InvokeMethod("SRDrill");

The key here is if any of the validation fails execution will stop and drilldown will not happen. Data Validation Manager business service returns true/false based on whether validations are passed successfully or not.