Set SLA state and recalculate with end_time based on incident close_at

[jbg]

We had a wrong SLA setup causing incorrect sla results.   The SLA setup is now corrected.

Is there a way to recalculate my SLA results (task_sla) on the closed tickets that were related to the wrong sla setup?

My SLAs are still In Progress so they don't have an end_time.

I created a script that would grab the incident close_at field, and use that as the end_time for the SLA.

I'm stuck at not being able to figure out how to mark the SLA's state properly, (utilizing the end_time I set), and calculating the correct amount of time.

I found this jbauguess, but after running it, all of the SLAs that were In Progress are still in the same state, and the calculation that was done, but as if the end_time is now.

Here is my script

Any help appreciated.

Thanks,

James

[jbauguess]

Quick tip before I get going on this: setLimit() ->   GlideRecord - ServiceNow Wiki     will help you with your testing so you don't need to add that count loop in your block iterating through the task sla records.

My script was just designed to update the end times.   The PO who wanted this ended up leaving before this was released, and the new PO didn't really care about the historical data, so this went on the shelf.   So after dusting this off, I realized the business rules to update the stage of the record were still just on "display".   Also, whatever is setting the stage of the SLA isn't in the SLACalculatorNG apparently.

So I added a few new lines to handle the stage update.   You will probably need to redefine it to meet your business needs, but essentially if it's paused, breached, achieved, complete, or cancelled, it leaves it alone.   If it's in progress, it looks for the "has_breached" flag, and if it's true sets the stage to breached.   Otherwise, it checks for an end time.   If there's an end time, it'll set it to achieved.

Hope this helps!

[jbg]

Justin,

Thanks for the tip. I'm new to SN, and I knew about it, but I was feeling lazy at the time and didn't want to look up the syntax after looking at it, I should work on being a little less lazy so I can be more lazy. It cleaned up the code quite a bit. 🙂

Also your script didn't update the end times correctly, it always set the duration of time based on the end_time being now, not the end_time (if there is one).

I included my changes in my own gist. I also removed the try/catch, since they can be slow, and I like to live on the edge 🙂

I didn't make any changes to the stage update portion.

Something I noticed that I think might be a SN bug, and SN might know about is, I was watching the logs, and I kept getting this error:

java.lang.RuntimeException: String object has exceeded max size of 16777216
Caused by error in <refname> at line -1

I think its happening when the ORM (Hibernate?) is trying to create SQL queries, with long WHERE statements, but I could be wrong.

I was thinking utilizing limit with this script include, and iterating until 0 records were returned so it might run faster, but it's probably not worth the time.

I'm waiting on a final run to try to fix all of the records I made a mess with on my first run. If I have anything to add I'll try to add it here.

Thanks,

James

[jbauguess]

Ah, good catch on the end times.   I forget why the try/catch was in there originally, probably I ran into an error at some point and was in a rush so I didn't want to spend time debugging it or handling it properly.

As far as that string object size, I've not seen that one before.   I also don't use the join queries like you use from your first example, so I wonder if that has anything to do with it (assuming you're still using it in relation to this script include).