Comments on: Calendar or Schedule-based Incident Autoclose

By: Jim Pisello

Jim Pisello — Fri, 14 Jul 2017 16:23:45 +0000

In reply to JM. Hi JM, This code hasn't been tested in Istanbul specifically. If you want to try it we recommend applying it to a sub-production instance and thoroughly testing it before moving it into production.

By: Sidarth Wangneo

Sidarth Wangneo — Thu, 18 May 2017 09:46:13 +0000

No they don’t.
But if we try to print out the variables “actualDateTime.setDisplayValue(gs.nowDateTime())” and gr.sys_updated_on.getGlideObject() they give the time in GMT format.
What if I wanted the time in system’s/user’s time zone?

By: JM

JM — Thu, 18 May 2017 06:50:02 +0000

Hi Mark,

Can we use this code in Istanbul version?

By: Mark Stanger

Mark Stanger — Tue, 09 May 2017 13:18:32 +0000

In reply to Sidarth Wangneo. I don't think the scripts above display the time anywhere, do they? If you're looking for help with the notifications or business rules that set field values associated with autoclose you should post that on the ServiceNow community. If I'm missing something please let me know and I'll attempt to address that.

By: Sidarth Wangneo

Sidarth Wangneo — Tue, 09 May 2017 12:47:09 +0000

Hi.
The above script works fine except for the fact that it displays the time in GMT. I know that we can change that by adding a setDisplay() method but that converts the variables into string format and they can’t be used in Schedule.Duration function. Any idea how can I do it in system’s time zone?

By: Mark Stanger

Mark Stanger — Mon, 02 Jun 2014 12:50:22 +0000

In reply to Adam. Sounds like the autoclose job isn't the source of the performance issues if setting the 'setWorkflow' flag to false removes the performance issue. The only thing I can say is to review the business rules on the incident and task tables. You can use business rule debugging and manually change an incident from resolved to closed to see which business rules are being run.

By: Adam

Adam — Mon, 02 Jun 2014 09:58:32 +0000

Hi,
Do you have any idea what may be the reason that incident autoclose scheduled job causes performance problems? I used exactly the same code as in this article. Code is run as scripted scheduled job, once per hour. Did a test and closing 10 incidents takes approximately 14 – 18 seconds. That’s very bad because we have 40 000 incidents to be closed every day. After switching of the workflow (gr.setWorkflow(false)) before calling gr.update() – it works very fast. Is there any good way how to check what business rules, workflows and other kind of events are run on “incident_state” and “active” fields update? I found 15 custom or in-built business rules that are triggered but none of these is performance killer. Thanks in advance for any tip.

– Adam

By: Andreas

Andreas — Thu, 06 Jun 2013 17:54:11 +0000

In reply to Mark Stanger.

Thx – yes, I saw that one :) Looking at the code it works great. I am using your approach to prepare our own code for the upgrade to Calgary.

I was thinking of tackling this similar but I am missing one piece to get it working.
The idea is to perform the date and time calculation in the beginning (also based on a schedule) and then adding it to the query to find only those records which have been updated last on the calculated date and time or earlier.
This would make the code less expensive for the server as the difference no longer needs to be calculated for each found record.
Depending on the amount of found records it could make a difference.

All functions and methods I found so far were about to “add” time but not to “subtract” it. Any idea if there is something out there?

By: Mark Stanger

Mark Stanger — Thu, 06 Jun 2013 17:42:39 +0000

In reply to Andreas. No reason other than the Packages call provided a working solution. I've updated all of the code above to work for both Packages calls and non-packages calls so it shouldn't be an issue when Calgary comes along.

By: Andreas

Andreas — Thu, 06 Jun 2013 17:40:06 +0000

Hi,

I was wondering, if there is/was a specific reason to use the Package call instead of the DurationCalculator. (Beside the fact that a working solution was found which works well)
Looking at the wiki article (http://wiki.servicenow.com/index.php?title=DurationCalculator) also here it is possible to define a schedule for the calculation.

Andreas