Run an Update Set Once Clone Completes

jmiskey
Kilo Sage

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

1 ACCEPTED SOLUTION

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

16 REPLIES 16

Bert_c1
Kilo Patron

Hi,

 

if a Remote Update set can be previewed and committed by a script, then you would use:

 

https://docs.servicenow.com/bundle/utah-platform-administration/page/administer/managing-data/concep...

 

However, I'm not aware if that can be done. Others here can comment on that.

I am not sure that helps.  It looks like he never did quite finish the program (sounds like there were a bunch of issues), and I don't think our Security team would allow us to use a 3rd party program like that anyhow.  It seems like things were left rather unresolved.

 

Maybe I am going about this the wrong way, and maybe we would be better off trying to figure out how to retain this customization through the clone process.  Though it didn't work using the "preserver" option, maybe we will submit a HI Ticket and see what ServiceNow says.

Bert_c1
Kilo Patron

The update set imported, but not previewed and committed, will be in the sys_remote_update_set table.  and that table should be copied exactly to a clone target instance, unless there are Data Preservers/Exclude tables defined for that table.  Then post clone log in and preview/commit those you want in that instance.

 

Seems wrong to import any update sets in the Retrieved Update Sets in a production instance. Best Practice is to develop in the dev instance, promote to test instance, and then to prod.  But anyway, the related tables in the target instance should match those in the source instance.  the clone process uses the most recent instance backup, any changes since that time in the source instance won't be included in the clone.