Run an Update Set Once Clone Completes

jmiskey · ‎02-14-2023

We have a situation where we have scheduled a weekly clone from our PROD environment to a special DEV2 environment that was set up for us. We have created some Custom Themes that we would like transferred to this DEV2 environment. We tried setting "Preservers", in hopes that the Clone would not overwrite these Custom Themes, but it did not work (and research into old Community questions seems to suggest that this may not work quite as expected).

So we have a different approach that we would like to try. We want to create an Update Set that we import, but do not Post/Commit, in our PROD environment. Then, the Clone should copy that uncommitted Update Set to the DEV2 environment. We would like to then run this Update Set once our Clone is completed. So we have a few questions regarding the best way of doing this, including:

- What is the best way of running this Update Set once the clone is complete?

- Would you do that with a Scheduled Job, or in some other manner?

- Can a Scheduled Job actually run/commit an update set?

- If it can be done with a Scheduled Job, is it possible to make it wait until the Clone is complete, or do I just need to pick a time to run it when I know that the Clone should be complete (in a perfect scenario, it will run automatically upon completion of the clone)?

Thanks

Kirby R · ‎02-16-2023

Customer Update name is basically <table_name>_<sys_id of the record in that table>. So what you need to do is add these tables in your preservers similar to what you have done for sys_properties.

Example:

sys_ux_style, m2m_theme_style

You can do more granular and include the sys_id in the filter in your preserver

View solution in original post

jmiskey · ‎02-16-2023

OK, I will try that. One question though. I am obviously setting up the Preservers in my (PROD) instance (where I am cloning from). However, the records only exist in the DEV2 instance (where we are cloning to), as we have only applied the custom themes to our sub-instances.

Will it cause any issue if the sys_ids I am referring to in the Preservers I am building in the PROD instance don't actually reside/exist at all in the PROD instance (and are only found in the Target instances)?

Kirby R · ‎02-16-2023

there should be no issue. By defining preserver, you are basically telling the system to not change these in target instance

jmiskey · ‎02-16-2023

Got it! We have another clone running Monday morning. I added these new records to my Preservers. We will see how it works! I will report back next week.

Kirby R · ‎02-16-2023

Great. Other way I can think of testing it instead of waiting til monday is to have two PDI and perform clone as long as you have admin role in those instances.

Bert_c1 · ‎02-15-2023

That is described here:

https://docs.servicenow.com/bundle/tokyo-platform-user-interface/page/administer/navigation-and-ui/t...

It Seems you have done that from the above. there is the "Preserve Theme" clone option that should help with other related instance differences.

And the sys_update_xml, sys_update_set, sys_remote_update_set tables should NOT be in the Preservers or Exclude Tables if you want the source and target instances to have the same update sets.

A general description of the clone process is here:

https://docs.servicenow.com/bundle/tokyo-platform-administration/page/administer/managing-data/task/...

Here are links to discussions on how to preserve Application development and Update sets in dev/test instances that have not be promoted to production prior to the clone:

https://docs.servicenow.com/search?q=CSHelp:Preserve-unpublished-apps

The clone option "Preserve In Progress Update Sets" is limited.