Running a fix script to update the stop time to be the resolve time of an incident and then resolve the SLA

[matthew_hughes]

I'm trying to create a fix script that will search for incidents created at a certain time where their task SLAs have been breached, take the Resolve time from each incident and update this in the Close time on any associated SLAs, and then repair the associated SLAs of each incident. I've written the below fix script and was just wondering if this would cover the scenario:

var tab = new GlideRecord('task_sla');
//Searches for the affected incident SLAs
tab.addEncodedQuery('task.sys_created_onONThis year@javascript:gs.beginningOfThisYear()@javascript:gs.endOfThisYear()^task.ref_incident.caller_idSAMEAStask.ref_incident.resolved_by^task.ref_incident.resolved_atBETWEENjavascript:gs.dateGenerate('2022-02-03','18:00:00')@javascript:gs.dateGenerate('2022-02-09','18:30:00')^has_breached=true');
//Runs the query
tab.query();
//Helps in prevent running of BR's while updating
tab.setWorkflow(false);
//While it's looping through the records
while(tab.next()){
//Sets the 'Stop time' field to match the resolved field in the related incident
end_time = task.ref_incident.resolved_at;
//Makes the update
tab.update();
}
var repair = new SLARepair();
while (now_GR.next())
repair.repairByGlideRecord(tab);

If there is anything that needs changing or if there's a better way of doing this, please let me know.

[matthew_hughes]

Hi Dan,

When I try running that as a background script, it doesn't update the stop time on the related SLA:

The stop time should be 08-02-2022 15:51:59

When I load the script, I get these updates in the incident record:

I've looked in the 'sys_audit_delete' table and I can see that there are entries for SLA incident resolution that are getting deleted. I'm not sure the fix script would delete the entries.

[Dan H]

Hi Matthew,

I looked into this further, this is what I found.

The stop time is actually being updated in the script, before the SLA is repaired.

Then the SLA repair code runs, which:

• Deletes the Task SLA record (look at sys id of above: '42d8c...')
• Inserts a New repaired Task SLA record (look at sys id below: '8968...')

Newly inserted record:

• This new record is inserted and for some reason repairByGlideRecord() function, is not carrying over the stop time field value, at least in my PDI. I believe the stop time value copied from the incident earlier was used in the repair calculations.

This information about deleting and inserting a record is supported in the docs:

The repair function removes the SLA record, then recreates and recalculates it from the start, including recreating the workflow. The repair uses the history from the Task and if appropriate will also create new Task SLAs that did not previously exist. For example, a new Task SLA may be needed if a new SLA Definition has been added since an associated Incident was created or updated.

Source: https://docs.servicenow.com/bundle/sandiego-it-service-management/page/product/service-level-management/concept/c_RepairSLAs.html?cshalt=yes

I will try to find a way to test this further in my PDI, but thought that I would share this information with you. The updates to the script are correct, but I want to know why the new stop time isn't being carried over to the new task_sla record and confirm that the repair SLA is actually functioning correctly. If you continue to work with this, I still advise to use background scripts + test only on a small group of records.

Furthermore, just incase you are unaware. You can rollback the execution of any background script you run by going to the execution history record created for the execution and clicking the rollback script execution link in the related links. You can also see what records were inserted/updated/deleted during the execution, to help verify your testing.

[matthew_hughes]

Hi Dan,

I appreciate your help with this, please let me know if you find any more details or solutions to my code.

[matthew_hughes]

Me and my colleagues also tried using the below script, but we got the same results:

var sla = new GlideRecord('task_sla');
sla.addEncodedQuery("task=a2733c731b11015009dd5e26464bcbd2");

sla.query();

sla.setWorkflow(false);

while (sla.next()) {

gs.log("8506064 inside while");
var incident = sla.task;

gs.log("8506064 incident" + incident);
var resolved_time = sla.task.ref_incident.resolved_at;
gs.log("8506064 time"+ resolved_time);
//var test = sla.end_time;

sla.end_time =resolved_time;

sla.update();
gs.log("8506064 updatetest"+ sla.end_time);

}

var inc = new GlideRecord("incident");
inc.addQuery("sys_id", incident);
inc.query();
var repair = new SLARepair();
while (inc.next()) {

gs.log("8506064 inside while2");
repair.repairByGlideRecord(inc);

}

[Dan H]

Hi Matthew,

Were you able to confirm that stop time is set before repairing SLA's so that it is used to calculate the new task SLA correctly?

And then the only issue remaining is that stop time is empty on the newly inserted task_sla record?