Temporarily disable update set tracking

[guycotton]

Hi all,

Is there a JavaScript way to disable update set tracking during a glide script transaction (i.e. business rule/ UI action etc)?

Rationale:

We've built a management wrap around Record Producers, this wrap programatically creates and tears down record producers. We did this because record producers did not fully satisfy our requirements, nor was it possible to customise the sc_cat_item_producer table as we wanted.

The idea is that the user interacts with a single "managed producer" which in turn creates multiple record producers on the fly. During development there would be multiple iterations of record producer creation/ deletion. Ultimately, the user hits a "publish" button which constructs a production ready record producer and pubishes it into a catalog. By default (as cat items are update_synch) all of the development deletions/ creations are tracked in the current update set which creates a lot of noise when migrating changes across instances - only the final set of changes are necessary.

Ideally, we'd like to temporarily "turn off" update set tracking using javascript for a given transaction - is this possible?

Thanks,

Guy

[christen_mitche]

You can always use: setWorkflow(false). GlideRecord - ServiceNow Wiki

[guycotton]

Thanks Christen,

Have tried this previously (and just checked again for sanity) - unfortunately it does not work. The update/ insert is still recorded in the update set. The Docs you reference don't mention update sets, just the possibility of stopping business rules/ cascades when setWorkflow(false). What is expected behaviour?

My test was the following code in a background (on demand) scheduled job:

// JavaScript

var gr = new GlideRecord('sc_cat_item_producer');

gr.initialize();

gr.name = 'testing update set';

gr.short_description = 'testing update set short desc';

gr.setWorkflow(false);

gr.insert();

// End JavaScript

Any ideas?

[bernyalvarado · Accepted solution]

Hi Guy, have you thought on setting to the default update set your change by manipulating directly the sys_update_xml table?

Thanks,

Berny

[guycotton]

Hi Berny,

That's an awesome idea. I can sandbox all the irrelevant changes in one isolated update set. That fixes the overall problem of noise in updates set that are going to be promoted between instances.

I did a bit of Googling and experimentation and this should absolutely stand as a solution. For anyone who finds this a later date, you don't need to actually manipulate the sys_update_xml table itself, but it seems it's possible to programmatically switch a user's current update set using the code along the lines of:

var user = gs.getUser();

user.setPreference("sys_update_set", "[UPDATE SET SYS ID]");

Naturally caveat emptor! If you're switching update sets for a user you should be very careful - tell them via the UI and of course wrap any subsequent logic with robust exception handling if you need to switch back.

(There may be a cleaner way to do this with GlideUpdateManager2, but I couldn't find the API)

Massively appreciated Berny - cheers!