1315 views

Description

Multiple quick succession updates from Tivoli (possibly any integration), in conjunction with a user action on a record, can result in multiple task_sla records running against an incident. On the surface it seems that the task_sla is being created, even though the start condition does not apply. Processing that many updates that are occurring, sometimes within the same second, is likely a rare timing issue.

Steps to Reproduce

Create a new SLA (using the Default SLA Workflow):

Start: Priority is 2 High AND Assignment Group is Network AND Incident state is Active.
Stop: Incident State is Resolved.
Pause: Priority is not 2 High OR Assignment Group is not Network OR Incident state is Awaiting User Info.

  1. Create a new incident and meet the start conditions.
  2. Write a loop to go through and update the incident (simulate getting multiple quick succession updates from an integration).
  3. In another window (while the below is processing) open the incident and mark it Resolved (to meet the Stop condition).


Reload the form and note that you will have two task_sla records. The second one seems to have started at the same time the incident was resolved. This second task_sla has been known to show a variety of stages, such as Achieved, In Progress, and even Breached at times. The second task record should have never been created.

Script used to handle steps 1 and 2:

var inc = new GlideRecord('incident');
inc.initialize();
inc.assignment_group.setDisplayValue('Network');
inc.priority = 2;
var inc_sys_id = inc.insert();
gs.sleep(3000);

var i1 = new GlideRecord('incident');
i1.get(inc_sys_id);
i1.incident_state = 2;
i1.comments = 'Update to Active - SLAs should start';
i1.update();
gs.sleep(500);

for (var i = 1; i <=100; i++ ) {
var i1 = new GlideRecord('incident');
i1.get(inc_sys_id);
if (i1.incident_state != '6') {
i1.comments = ("Update " + i);
i1.update();
} else {
for (var j = 1; j <=2; j++) {
var i2 = new GlideRecord('incident');
i2.get(inc_sys_id);
i2.comments = ("Update " + i + "(" + j + ")");
i2.update();
}
break;
}
}

 

Workaround

Set the Process SLAs business rule to run after instead of async.

This reduces the chance of multiple SLAs being attached by preventing multiple SLA actions from being queued for execution.

For a complete solution, change to the 2011 SLA engine, as described in the product documentation topic Legacy SLA engines.

 


Related Problem: PRB420494

Seen In

Aspen Patch 2
Aspen Patch 2 Hot Fix 10
Aspen Patch 2 Hot Fix 5
Berlin Hot Fix 4
Berlin Patch 1
Berlin Patch 7
Berlin Patch 8
Berlin Patch 9
Calgary Patch 2 Hot Fix 5
Dublin EA 8
Dublin Patch 1 Hot Fix 1
Eureka Patch 10
Eureka Patch 10 Hot Fix 1
Eureka Patch 7 Hot Fix 1
Eureka Patch 7 Hot Fix 4
Eureka Patch 8
June 2011 Release Patch 3

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2017-12-10 20:58:09
Published:2017-10-16