Why did Jakarta change Application File field labels for "Customer update" and "Replace on upgrade"?

maynartt · ‎08-24-2017

We upgraded one of our instances to Jakarta Patch 1 Hotfix 1 (released 2017-07-18 according to the release notes) to test our current functionality in preparation for an upgrade, and I saw that the field labels on the Application File table (sys_metadata) for these fields changed:

Column name	Istanbul Column label	Istanbul's Label Updated (US Eastern)	Jakarta Column label	Jakarta's Label Updated (US Eastern)
sys_customer_update	Customer update	2015-06-05 00:01:51	Customer update (No Longer Used)	2017-03-17 13:43:57
sys_replace_on_upgrade	Replace on upgrade	2015-06-05 00:01:51	Replace on upgrade (No Longer Used)	2017-03-17 13:44:30

I am concerned by this (we definitely use them today), and I looked and looked in the release notes etc, and didn't see any reference to these fields, and what, if they are indeed no longer used, replaces their functionality.

I also looked to see if someone else manually updated these labels in our instance that we cloned the Jakarta instance from, and didn't see any.

Does anyone have the same on their Jakarta (same patch and hotfix) instance? The bigger question is, does anyone know why these label changes were made? If so, please explain or point me to it.

Thanks!

maynartt · ‎08-31-2017

I received an answer for this from HI. They verified the following process needs to be done before upgrades (scoped apps included, which is what we're concerned with):

What we do today in Istanbul…

If, on the application object (anything extended from Application File — sys_metadata) the Customer update value is true, and on the next application update we want to override that object, we'd bring up that object in the associated list, add Replace on upgrade as a column on that list, and change its Replace on upgrade value to true before running the application update.

What we'll do in the future once we upgrade to Jakarta…

The fact that the application object has an associated record on the Customer Update (sys_update_xml) file, it means that at some point in time an update was made to it in that instance. There is no longer a need for a "Customer Update" field. Therefore, for each one of those that exists in the sys_update_xml file that we want to override, we'll need to change its Replace on upgrade value to true before running the application update (meaning the replace_on_upgrade field on sys_update_xml, not the sys_replace_on_upgrade field on the application object).

The quote from the HI agent that worked on my incident concerning any documentation on this: "I verified and found that these two fields are in fact not available anymore on the sys_metadata table as per an internal KB." I still can't find it mentioned in docs.servicenow.com.

I've copied below a matrix the agent sent me for further explanation.

sys_metadata.sys_customer_update	sys_metadata.sys_replace_on_upgrade	sys_update_xml exists	sys_update_xml.replace_on_upgrade	Outcome
ignored	ignored	yes	true	overwritten on new-family and optimized upgrades
ignored	ignored	yes	false	Preserved
ignored	ignored	no	not applicable	overwritten on new-family and not-optimized upgrades

View solution in original post

maynartt · ‎09-11-2017

My educated guess is it's just Jakarta and higher, mainly because we've updated our scoped app on Istanbul a couple of times and used the "old way" of ensuring/skipping object update (as I noted above in a previous post), but you have a good question in that maybe using replace on upgrade on the Customer Update record in earlier versions would have worked just as well. I didn't dig into that since what we were doing was working for us.

hadyndickson · ‎09-18-2017

What do you think is the better approach?:
1.) Mark "replace on upgrade" and then upgrade to revert an item, OR
2.) Upgrade, then revert the item.

maynartt · ‎09-19-2017

To be honest, I haven't worked with them outside of our scoped apps, so I'm not sure what the best approach is when preparing for a servicenow version/patch/hotfix upgrade that affects the whole instance. In our case with the scoped apps, in the past, when we were first learning, we directly manually updated objects in production (this permanently marks Customer Update as true and creates a sys_update_xml record for that object in prod). On subsequent updates of our scoped apps, if we made changes to those same objects in our dev instance, we must set Replace on upgrade to true on the prod object because we want those dev changes to come over. We never retain what we did in prod - dev is always king. We have to do this for every scoped app update for the same object because the presence of that sys_update_xml record (which never goes away once it's touched) will prevent the update from changing that object unless its Replace on upgrade is true.

Having said all this, I'm not sure what approach, 1 or 2, is best. I think it depends on what you've changed in your target instance. If you want to retain your change, then leave Replace on upgrade as false on the object's sys_update_xml record. If you want your change replaced, then set that same field to true. My gut feel is to go thru the exercise to id what sys_update_xml records exist and why, change or leave alone the Replace on upgrade based on what you've found, then do the upgrade. Then after your team does testing/checkouts after the upgrade and all is OK, then you're done. Feel free to disagree.

roy_dreijling · ‎11-22-2017

1)

That way you can make sure an item will be upgraded up front.

I have had the 'pleasure' of analyzing 3600 Skipped updates in the istanbul upgrade. 😞