Restoring custom app after cloning

Rick Marsha · ‎06-03-2015

So, here's my scenario:

-Built a custom scoped app in DEV instance

-Published app to PROD instance and installed as a release

-Exported the app from DEV as an update set

-Cloned PROD instance over DEV

-Imported update set to DEV after cloning

My issue is that when I imported my update set back to DEV, it didn't restore to 'sys_app'. The app package didn't seem to import and is not editable. Has anyone encountered this issue yet? I'd like to avoid rebuilding it from scratch.

Rick Marsha · ‎06-05-2015

After an insightful discussion with SN support, there are a few different issues at play:

- The cloning process doesn't preserve the original sys_app (app creator) record for a custom app that was created in the target clone instance

- The 'Publish to update set' feature doesn't include the sys_app record, but creates the update set from a customer perspective (should be optional to include, IMO)

- The target clone instance receives the sys_remote_app & sys_store_app (app repository) records for the custom app from the source clone instance, and ACLs prevent the customer from deleting the records on the target clone instance. This could be by design, but mucks up the DEV instance with app store installs I originally pushed to PROD.

Their recommendation was to restore my DEV instance from backup and retrieve the sys_app record, but I'm choosing to build another app container for my code since it was a small app. Their workaround to avoid this issue in the future is below.

BEFORE the clone, on the source clone instance:

1) Add sys_app to the "Exclude Tables" module

2) Add sys_app to the "Preserve Data" module, and make sure "Theme" is false

Thanks,

-Rick

View solution in original post

Admin Pro · ‎06-13-2016

Jeremy,

Which version of ServiceNow contains the fix you have mentioned?

coryseering · ‎01-06-2017

This is incorrect. Publishing to an Update Set (using the Publish to Update Set Related Link on the sys_app page) does include the sys_app record. When you publish to an Update Set, you get the entire application in that set. You can then save to XML, and import the Update Set back into your cloned-over instance (or onto a new instance) as you would any other Update Set saved to XML- by bringing it in via Retrieved Update Sets -> Import from XML, previewing, and applying.

When you clone over an instance, the engine will get a list of the in-development applications currently on the target instance. After the clone finishes, the engine compares the list of in-development apps (from the target, pre-clone) to the list of *installed* applications currently on the target (post-clone). Any matching applications are automatically made editable.

If you had an app in-development on the target, but there is no version of that app on the source instance prior to cloning, then that application will not be on the target post-clone either.

Additionally, if the version of the app in-development ont he target is different than the version of the app installed on the source, then you will end up with *an editable app at the version as it was on the source instance*.

So, to sum up:

1. Pre-clone, please Publish to an Update Set and save that set as XML.

2. Post-clone, please import your Update Set as you would any other in-development work you would have saved.

3. If you are on Helsinki-forward, an alternative to Update Sets is to link your applications to a git repository, so you can push your in-progress changes there pre-clone, and apply the remote changes from there post-clone.

Thanks,

Cory

samwallace881 · ‎05-30-2018

Thanks Rick. I just ran into the same issue!

chris_lo · ‎01-26-2016

To add on to Jeremy's comment uploading a scoped app to the repository is done by publishing the application using the 'make app available to another instance' UI action or the 'publish to store' UI action. If you have not published the scoped app cloning over will result in the loss of the developed app.

chris_lo · ‎10-10-2016

This issue has not been fixed although there was information previously saying that it was. The current work around for this is publish your applications to an update set and the import following a clone. Our development team is still working on a proper fix for this. This pertains only to developed apps.