How to migrate new business services to a different instance - Support and Troubleshooting

How to migrate new business services to a different instance Description Warning: The purpose of this article is to assist with migrating NEW business services (with entry points that were not used as entry points of any existing business services) from one Service Now instance to the other. Do not use the scripts supplied with this article to migrate modified (existing) business services (and entry points), as it might overwrite existing data or cause duplications. *** USE WITH CAUTION ** The “Add all business services to update set” script is a fix script whose purpose is to add all business services and their associated entry points to the current update set to make it easier for the Migration Engineer to migrate this content, initially migrated from ServiceWatch, from one ServiceNow instance to the other.

Note that the script is not limited to the migrated business services. It adds ALL business services and their entry points to the update set regardless of whether they are added with migration.

This script was implemented as a fix script because fix scripts are easy to run on demand, and doing so doesn’t require maint permissions.

For more information regarding update sets, see the documentation topic Update sets and its subtopics.

For more information regarding fix scripts, see the documentation topic Fix_scripts .

Scripts This document provides the content for the following two fix scripts and then describes them:

sys_script_fix_b801dd21c3002200ab8f9624a1d3ae31.xml – "Add all business services to update set” fix script sys_script_fix_90545218db852200e2c27a6eaf9619b0.xml ‐ "Synchronize BS with Service Model” fix script sys_script_fix_b801dd21c3002200ab8f9624a1d3ae31.xml ‐ “Add all business services to update set” fix script true false false Add all business services to update set true if (us.get(setID)) { gs.log("About to add all business service groups to update set id=" + setID + " (" + us.name + ")"); addBsGroupsToUpdateSet(); gs.log("About to add all business services and their entry points to update set id=" + setID + " (" + us.name + ")"); addToUpdateSet(); } function addBsGroupsToUpdateSet() { var um = new GlideUpdateManager2(); var gr = new GlideRecord('cmdb_ci_service_group'); gr.query(); while (gr.next()) { um.saveRecord(gr); gs.log('Business Service Group id=' + gr.sys_id + ' (' + gr.name + ') added to update set'); } } function addToUpdateSet() { var um = new GlideUpdateManager2(); var m2mGr = new GlideRecord('sa_m2m_service_entry_point'); m2mGr.query(); while (m2mGr.next()) { var m2mId = m2mGr.getValue('sys_id'); var bsId = m2mGr.getValue('cmdb_ci_service'); var epId = m2mGr.getValue('cmdb_ci_endpoint'); var bsGr = new GlideRecord ('cmdb_ci_service_discovered'); if (bsGr.get(bsId)) { bsGr.setValue('layer',''); um.saveRecord(bsGr); gs.log('Business Service id=' + bsId + ' (' + bsGr.name + ') added to update set'); } var groupGr = new GlideRecord('sa_service_group_member'); groupGr.addQuery('service', bsId); groupGr.query(); while (groupGr.next()) { um.saveRecord(groupGr); gs.log('Association of Business Service id=' + bsId + ' to group id=' + groupGr.service_group + ' added to update set'); } var epGr = new GlideRecord('cmdb_ci_endpoint'); if (epGr.get(epId)) { // Getting the specific ep var clazz = epGr.getValue('sys_class_name'); var specificEpGr = new GlideRecord(clazz); if (specificEpGr.get(epId)) { um.saveRecord(specificEpGr); gs.log('Entry Point id=' + epId + ' (' + specificEpGr.name + ') of type ' + clazz + ' added to update set'); } } var assocGr = new GlideRecord('svc_ci_assoc'); assocGr.addQuery('service_id',bsId); assocGr.addQuery('ci_id',epId); assocGr.query(); if (assocGr.next()) { um.saveRecord(assocGr); gs.log('Association of endpoint id=' + epId + ' to service id=' + bsId + ' added to update set'); } um.saveRecord(m2mGr); gs.log('M2m record id=' + m2mId + 'added to update set'); } }]]> sys_script_fix admin 2016-06-16 07:37:26 false b801dd21c3002200ab8f9624a1d3ae31 5 Add all business services to update set global false global sys_script_fix_b801dd21c3002200ab8f9624a1d3ae31 admin 2016-08-01 08:05:31 true sys_script_fix_90545218db852200e2c27a6eaf9619b0.xml - “Synchronize BS with Service Model” fix script true false false Synchronize BS with Service Model true ('sa.service_modeling.use', true)) { var utils = new ServiceMappingUtils(); var gr = new GlideRecord('cmdb_ci_service_discovered'); gr.query(); while (gr.next()) { if (gr.layer == '') { utils.resetModel(gr); } } } else { gs.log("*** sa.service_modeling.use property is false ***"); } ]]> sys_script_fix tal.benari 2016-08-01 08:21:22 false 90545218db852200e2c27a6eaf9619b0 4 Synchronize BS with Service Model global false global sys_script_fix_90545218db852200e2c27a6eaf9619b0 admin 2016-08-01 08:33:52 true

Script Logic The script starts by adding all existing Business Service Groups to the update set. It then queries the sa_m2m_service_entry_point table, which binds business services to endpoint records, making them the business service’s entry points. It uses each record to fetch the business service (cmdb_ci_service_discovered) record and the endpoint (cmdb_ci_endpoint) record, using their sys_ids. To find out the exact endpoint type, it uses the sys_class_name field in the cmdb_ci_endpoint record. The specific endpoint record is fetched using this field’s contents. To find out which group each service is bound to, it uses the business service’s sys_id to fetch the group member records (sa_service_group_member). Using the sys_ids of the business service and endpoint records, it also fetches the CI association (svc_ci_assoc) record. (This is most important in Geneva, where the current map nodes are based on CI associations.) Finally, the m2m record, group member record, CI association record, business service record and specific endpoint record are all added to the update set. The script uses the GlideUpdateManager2 API to do that. Messages printed to the log let the user know which records were added to the update set. How to use the script Make sure that the update set you want to add the business services to is your current update set. If not, make it current.

For more information, see the documentation topic Update sets .

Import the “Add all business services to update set” fix script XML to the instance.

Navigate to System Definition > Upload File . Browse to choose the file. Click the Upload button. Navigate to System Definition > Fix Scripts and search for the fix script.

On the fix script form, click the Run Fix Script related link, and click OK .

Click either Proceed or Proceed in Background .

Proceed – Runs the script interactively. When the script finishes, a window displays a script log that shows which records were added to the update set. You can copy this log and save it elsewhere for future reference. Proceed in Background – Click the Show Program Workers link in the fix script form to go to the Progress Workers table to monitor the script’s progress. The script log will appear in the Message field of the relevant Progress Worker. When you are done, click Close and go to your update set to see that the records were added.

Important Notes After importing the update set to the target instance, you need to synchronize all business services with Service Model through the related UI action. The script removes the reference to the layer prior to adding the business service record to the update set without saving the business service record itself.

The layer reference is removed because Service Model records are not added to the update set. Adding Service Model records to the update set and transferring them from one instance to another is unsafe as it might break the model. If the reference were to be left intact, an error message regarding a nonexistent reference to the layer would appear during import.

If you don’t have access to this UI action, upload the “Synchronize BS with Service Model” fix script to the target instance and run it the same way you ran the previous fix script on the source instance.

This fix script is safe as it synchronizes only business services missing from Service Model. (Otherwise, the history of existing business services would have been reset.)

A record may appear more than once in the log. However, a record cannot exist in an update set more than once; therefore, it won’t appear as a duplicate.

When using the GlideUpdateManager2 API, a record is created in the sys_update_version table, and an XML file is created under the customer update folder because it is a part of the mechanism that allows adding records to an update set. It should not have any side effects because these tables are not defined as update_synch.