Will importing objects from a dev instance to prod ever cause a conflict in sys_ids?

HugoFirst · ‎08-24-2016

I heard a presentation yesterday where a development team reported that they moved update sets from dev to test to prod, that they also imported XML files for the objects needed that are not in the update set. I'm thinking that "import XML" could be used for new groups required for assignment groups in a new workflow, scheduled jobs, etc. When I heard this, I thought that the XML file contains the sys_id as assigned on the dev instance ( or wherever the change was originally made ).

My question is this: Isn't there a risk that the sys_id of the imported object might already exist on the prod instance? And if not, what stops the prod instance from creating a duplicate sys_id for future objects? I suppose that it's a small risk, but I would "sleep better" if I know that the prod instance can be relied upon to always generate a unique sys_id and that there is no chance of a duplicate being created or used.

zica · ‎08-24-2016

Yeah you are right, it should be ( 16^32 ) * N, (32 for the fat that GUID is 32 digit), but still the number is loo large, I never wanted to be a friend with maths

Yes i you are right that some customisations aren't take into a update set and you have to create them manually over instances, however as said, the number is too large that the probability of two accidently being the same is negligible.

However, update sets are not seen as a custo, but if you want them to push within an update set, there is share app that adds a UI Action you can use to manually push a job to an update set :

ServiceNow Share

It's called Add to Update Set Utility published by Ben Hollifield.

View solution in original post

zica · ‎08-24-2016

Steve,

Always move customization through Update Set to maintain the same SYS_ID.

When you manually create a record in two instance, it takes a sys_id randomly. The chance to get the same sys ID is : 9^32 (you can even sleep like a baby )

Furthermore, here is : A different way to do data

HugoFirst · ‎08-24-2016

Thank you AKb for the quick response.

I'd like to amend your formula for the chance of a collision for a sys_id.

Shouldn't it be ( 16^21 ) * N?

The 16 comes from my observation that the number appears to be hexadecimal and not base 10.

The N is the number of sys_id's issued on the instance.

Still an extremely miniscule chance of a collision and I'm not really going to loose much sleep over it. 🙂

But I would feel better if I knew for a fact that the system has checks to prevent a duplicate sys_id from being created.

On your statement that customizations should be moved via an udpate set, I definitely agree. But some changes do not get included in update sets.

In my experience, scheduled jobs are not included, and data changes ( like a new group ) are not.

When I've needed to do this in the past, we either created it manually after the install and then "rewired" the customization to use the newly created object.

Or in the case of scheduled jobs, we export to XML from the dev/test instance and then "Import XML" on the prod instance.

HugoFirst · ‎08-24-2016

One more thing AKb, I read the article linked in your reply and I find it very interesting. I'm going to try the process out and see how it goes.

Thanks again!

Brad Tilton · ‎08-24-2016

Hi Steve,

I believe that the sys_ids should be unique across all ServiceNow instances, although I have heard of something like that happening once between two different customers. Moving data via xml is a pretty standard practice.