Update Sets between two different Instances where the same plugin is installed manually

[Oliver D_sereck]

Hi everyone,

Maybe a bit of a strange question, and I know it works but I would like some more Information to get my head around it.

Situation:
1. On Instance A you install Plugin A
2. On Instance B you install Plugin A (you do NOT clone Instance A onto B)
3. Using an update set, you make changes to Plugin A on Instance A
4. Transfer the Update Set to Instance B, Commit the changes and everything works and gets applied.

My brain is currently thinking:
Installing a Plugin (current example was the Software License Management Plugin) creates Tables with fields, Applications, Modules, reference lists, script libraries and more fun stuff. I would assume each "design element" also gets a kind of sys_id, like a record does, that is used as an internal identifier. Installing the same plugin on different instances would mean every element gets its own unique "sys_id". So the slm_license_base table sys_id would be different on each instance. This would also mean, making a change on a table (adding a column for example) would be documented in the update set as changing a specific table sys_id and transfering this change over, would mean it wouldnt work on the other side.

So the actual question: Why does this work anyway? I just tested it on two instances and my updates worked without any errors. Yes yes, I know ServiceNow is a smart piece of software, I am just wondering how the mechanism works 🙂

Cheers,
Oli

[guy_yedwab]

Hi Oli,

I can shed some light -- there's one piece of information you need to know that makes it all clearer.

When you upgrade, or activate a plugin, don't think of the records that are added to the instance as being "created" -- think of them as being "loaded" from our build server. I make that distinction because both instances are loading the same xml file for the records that the plugin adds.

When ServiceNow checks a record in to a plugin, it already has a sys_id specified. So, when ServiceNow checks in, say, a business rule, it has a sys_id already. Every instance that loads that UI action will have a business rule with that same sys_id. The business rule 'mark_closed' has a sys_id of bf3f8917c0a8016400a867dc0794e8ad on every instance.

When you create your own record, it gets its own sys_id. And when you move it from instance to instance in an update set, the XML payload that defines the record has the sys_id included -- so it'll have the same sys_id on the target instance as on the source.

ServiceNow designed it that way to avoid exactly the sort of error that you're expecting!

Hope that clears things up.

[Oliver D_sereck]

Thanks a lot Guy, perfect answer that also makes perfectly sense 🙂