Background Script to delete records

[Mike Cumbee]

I have a regular task that requires me to clear out a specific table when the new records are imported.   Since there are thousands of entries, I decided to create a script that would delete all of the entries older than ones I just imported.   This started off as a Background Script, though since it will be used regularly, I transformed it into a Script includes.

Test lines are included, but commented out.   I have not included user input error checking yet, or a try/catch:

var ClearTableByDate = Class.create();
ClearTableByDate.prototype = {
       initialize: function(tbl, DT, rmv) {
       // function to delete records from the Bin Numbers Table:
               // removes all entries in the table older than today:
               // requires 3 inputs:   Table, Date and a boolean:
               // var clearRecords= new ClearTableByDate('TableName', gs.nowDateTime(), false);
               // input table name as a string: 'myTableName'
               // use Today's date to delete records that were created PRIOR to today
               // use false to see the number of records that will be deleted
               // use true to delete records.
       var lrd = ""; // date of last record
       var i = 0;
       // if DT, get the table & records:
       if(DT)
       {
               var reqs = new GlideRecord(tbl);
               reqs.addQuery('sys_created_on', '<', DT);
               reqs.query();
               if(rmv != true)
               {
                       // run through the records and get a count:
                       while(reqs.next())
                       {
                               i++;
                       }
                       //lr = "IF: ot TRUE ";   //for testing
               }
               else
               {
                       //delete the old records in the table:
                       while(reqs.next())
                       {
                               //----   COMMENT OUT, to prevent accidental removal of records when testing
                               reqs.deleteRecord();
                               i++;
                       }
                       // lrd = " ELSE,   true ";// for testing
               }
               lrd = lrd + reqs.sys_created_on;               
               gs.print(DT+" Records: "+i +'.   Date: '+lrd);
       }
       /////   total record count:
       var reqt = new GlideRecord(tbl)
       reqt.query();
       i = 0;
       while(reqt.next())
       {
               i++;
       }
               gs.print("Total Records: "+i +';   Last Record Date: '+reqt.sys_created_on +": current date: "+DT);
       },
       type: 'ClearTableByDate'
}

If this has been useful to you please mark the thread useful.

If you have comments on how to work this better, please reply and discuss.

MC

[NRHinton]

Activating plugins is a lot like installing applications to your smart phone; there's the method that comes with your phone (some type of app/play store), secondary application distributors, and independent developers/distributors.

When you navigate to the 'System Plugins (Plugins)' table of your instance, you are using the OOB 'app/play store' of your instance. Just like how your phone's app store only allows you to install an application without being able to make any changes to it prior to that install, the OOB Service-Now 'System Plugins' function the same way. But, rather than hitting 'Install', you go under the 'Related Links' and click the blue-linked 'Activate/Upgrade'. That will 'install' the plugin to your instance, give you some related lists like 'Plugin Activation Logs' and set the Plugin's status to 'Active'. That's all the simpler it is

Something to note though, is that most of the time System Plugins can only be deactivated by a Service-Now support member through a Hi incident. Please also note that some plugins come with additional licensing fees or require a request for activation be placed with Hi. Each plugin should be reviewed and evaluated separately before activation. Please also note that plugin activations are localized to the Instance they are carried out on, as the actual activation of the plugin is not capturable in an Update Set. So if you have 3 Dev environments, 2 Test environments and 1 Prod environment, you will have to activate each plugin on each Instance, for a total of 6 activations. Once a plugin has been activated, Update Sets will treat changes to it normally and capture such changes like any other part of your instance.

Service-Now publishes quite a bit of documentation on their plugins, including the following list of their plugins for Istanbul

List of Istanbul plugins

To demonstrate what I meant by different types of Plugins, I used the 'List of Istanbul plugins' to grab this screen shot of three different types: Available by Request (Ticket with Hi), Available as a separate subscription (separate fee for that specific plugin), and finally a plugin without bold text (indicating it can be activated on any instance by any admin, without a Hi ticket, without incurring costing)

Secondary application distributors might include Service-Now's Share and Store, which both host plugins for users to download for free or for a cost, respectively.

I have found Share to be an excellent resource of niche functionalities for rebuilding/improving a feature that Service-Now neglected a little more than another User found functional (hence why they built the plugin to make or improve said functionality). Share can be thought of as Freeware to improve your Instance's performance and/or functionality in any number of ways.

ServiceNow Share

Store consists of plugins that all incur a cost, but rather than paying Service-Now, the fee goes to the company/group/individual that constructed the plugin. Numerous companies use Store to distribute custom integrations they have built to link their applications and Service-Now. Think of Store as a type of Premium App Store.

https://store.servicenow.com/sn_appstore_store.do#!/store/home

Finally, individual Users can distribute their own Plugins by building out fully scoped applications and then sharing the XML records or independently hosting them for download. I would be highly wary of any plugins acquired through this method, unless it is a known valid source or other Users have been able to successfully vet the plugin maker. Even then, for third-party sources like these, I almost always install them to a 'sacrificial personal developer instance' from ServiceNow Developer, because if the plugin does end up breaking that instance, there's no real harm done and I can just easily go and reset it, or simply request a new one.

If you have any other questions, please review the documentation I have already linked.

Edits: Spelling/Grammar/Elaboration of a very small number of areas.