07/19/2024 UPDATE: The August 2024 release of Service Bridge introduces a new set of features including Service Bridge configuration versioning, and support for mismatched provider-consumer application versions. Even more reasons to migrate from Legacy Service Bridge to the most current release! The August release of Service Bridge will be the first application version 2.x release, and the migration utility that is described in the article below will not support migration from Legacy Service Bridge to the the new 2.x version or beyond. Please migrate now from Legacy Service Bridge to Service Bridge version 1.1.x so you will be ready for the 2.x upgrade.
PLEASE NOTE that Service Bridge (Legacy) is no longer supported on Xanadu or any future releases.
-----------------------------------------------------------------------------------------------------------------
This is the first in what will be a series of best practice and how-to articles focused on ServiceNow’s Service Bridge that is part of our Technology Provider Service Management (TPSM), Telecommunications Service Management (TSM), and Media & Entertainment Service Management (MESM) products. Service Bridge helps providers, their customers, and their partners connect their ServiceNow instances and securely build business workflows across the ServiceNow ecosystem.
Service Bridge went through what was essentially a full technical overhaul for the Vancouver November 2023 store release, and that resulted in the release of new Service Bridge applications. The original applications, Service Bridge for Providers (sn_nowebonding_pro) and Service Bridge (sn_nowebonding_pro) have been renamed in the store with “(Legacy)” appended to the names to distinguish them from the new applications. The new Service Bridge applications are Service Bridge for Providers (sn_sb_pro) and Service Bridge for Consumers (sn_sb_con).
ServiceNow recommends that customers currently using the legacy version of Service Bridge migrate to the new applications as soon as possible. A migration process and utility have been developed (See KB1499823) to facilitate a seamless move from the legacy applications to the new applications.
In this article we will review the why and how of migrating to the new Service Bridge applications.
Why migrate from the legacy Service Bridge applications?
- With the new applications it is much easier to register and onboard new customers.
- The Service Bridge transport technology that is used to connect instances has been changed to REST web services using OAUTH2 for authentication. The change in transport allows the following benefits:
- The addition of support for on-premises instances and for secure instances in the Government Community Cloud where REST web services are permitted.
- With the new Service Bridge transport most troubleshooting can now be performed by the provider instance administrators.
- Migration to the new Service Bridge applications will provide an enhanced experience over the legacy version, and must be completed by Q4 of 2024 when the legacy application versions will be end of life.
- Transformations of remote task data have been part of Service Bridge since the Tokyo release, but only in the Provider application. With the new Service Bridge applications, the Consumer can now define transforms in their instance as well.
- Remote Task Virtual Mappings is a new capability that enables new Service Bridge use cases. Virtual inbound and outbound field mappings will allow fields that do not exist on the source table to be mapped between instances
- Instance Clone excludes and preserves for Service Bridge are now automatically installed with the new Service Bridge applications.
- Remote Task and Provider Task now support a Scratchpad API that allows temporary variables/data to be passed between instances as part of the task workflow.
While the current Service Bridge applications are new, they will instantly be familiar to anyone who has worked with Service Bridge. Except for the improved registration process and the new features, the concepts and configuration in the new applications remain largely the same.
Provider migration
As mentioned above, a migration process and utility have been developed (See KB1499823) to facilitate a seamless move from the legacy Service Bridge applications to the new applications. This section will step through the migration process.
⚠️ The following migration steps are to be completed on the Service Bridge provider instance. Migration is not necessary on the consumer instance and there is no Service Bridge for Consumers migration utility. Consumers will register with the provider on the new Service Bridge application and their defined entitlements will determine which capabilities are delivered to that consumer.
Step 1: Update the current Service Bridge for Providers (Legacy) application to the latest version (3.2.4 or above)
Step 2: Install the latest legacy Service Bridge global script include. See knowledge article KB0999950 for detailed instructions.
Step 3: Install the latest version of the Service Bridge for Providers application (1.x.x or above).
⚠️ The Service Bridge Legacy applications and the new Service Bridge applications will run concurrently without any issue.
Step 4: Install the latest Service Bridge global script include. The current version of the Service Bridge applications required updates to the ServiceNow platform to function. A global script include is necessary to receive those updates and use Service Bridge for Providers. See knowledge article KB1225292 for detailed instructions.
Step 5: Import and run the migration utility
⚠️ Important considerations:
- The migration utility is built to migrate configuration data from the Legacy Provider application to the new Service Bridge Provider application.
The configuration data which will be migrated are:- Remote task definitions and related tables
- Remote Choice definitions
- Transforms and related tables
- Remote record producers and related tables
- Customer criteria for entitlements
- Personas
- Any configuration or customization beyond what is defined above is outside the scope of migration. This may include:
- Transactional data, like tasks. Existing tasks are to be worked using the legacy Service Bridge application and closed as usual.
- ANY customization or configuration such as business rules, flows, client scripts, and script includes.
- It is important to use the Push to current update set option for production environments so that all provider instances (dev, test, prod, etc) have the same sys_ids for the configuration data.
- If Push to current update set is not checked when records are migrated, there will not be another chance through the utility to capture them in an update set.
- Use the migration utility in just one instance, and then use the update set(s) to add the captured configurations to the other instances.
- When using Push to current update set, if you have legacy configurations in different application scopes, only those belonging to your current selected application scope will be migrated. You will need to create an update set for each scope and run the migration once per scope.
- If not using Push to current update set all configurations will be migrated at once regardless of application scope.
- The migration utility can be run multiple times and will not create duplicates.
- Each run will only migrate configuration records that have not been previously migrated.
- Configurations modified in Service Bridge for Providers (Legacy) after migration will not be migrated again.
- The legacy and new Service Bridge applications can be run in parallel. This allows legacy consumers to be registered and migrated to the new application without a gap in service.
- Once a consumer is migrated, their entitlements should be removed from the legacy application to keep new tasks from being created there.
- Once all existing tasks are closed for a consumer the legacy connection should be disabled.
Importing the migration utility update set on the Provider instance:
- Download Service Bridge – Migration Utility.xml to your local machine.
- Navigate to All > System Update Sets > Retrieved Update Sets
- From the header menu, right-click and select Import XML
- Choose the file you downloaded and click Upload
- Open the SB Migration Utility update set you just uploaded.
- Click Preview the Update Set.
- Click Commit Update Set
- Now you should be able to see a new application menu All > Service Bridge Provider > Administration > Migration Utility.
- Only users with the admin role will be able to see this new menu and run migration.
Running the migration utility:
- Login as an admin user
- Navigate to All > Service Bridge Provider > Administration > Migration Utility
- Select from these options and click Save to create a new Migration task:
- Push to current update set - if selected, migrated configurations are pushed into your currently selected update set.
- Migrate Inactive records - if selected, inactive configurations will also be migrated. By default, the utility will migrate only active configurations.
- Once the migration task record is created you will be able to start the migration using the Start migration UI action.
- Successful or Failed migration messages will be added as work notes on the migration task. This is an easy reference to all migrated records.
Step 6: After the migration is complete…
- At this point you are running both the legacy and new versions of Service Bridge. Service Bridge consumers who are registered in the legacy Service Bridge version will continue to function as before.
- Register/onboard your consumers to the new version of Service Bridge. Follow the steps Onboarding Service Bridge consumers on the ServiceNow Documentation site.
- Navigate to All > Service Bridge > Remote Customer Criteria and update each of the customer criteria as required to remove the consumers onboarded in Step 2 above from the legacy Service Bridge entitlements. This will stop any new legacy Service Bridge task creation for the excluded consumer.
- The migration utility does not migrate existing legacy Service Bridge tasks or other transactional data. Existing tasks should be addressed through normal business process to closure before de-activating the related consumer’s legacy Service Bridge connection.
- Once all existing tasks are closed for a specific consumer the legacy connection (IDR replication set) should be deactivated.
Navigate to All > Instance Data Replication > Producer Replication Sets, open the replication set for the migrated consumer, and choose Deactivate.
Click OK in the warning dialog box.
The legacy Service Bridge connection with this customer will now be deactivated. - If desired after all consumers have been migrated from the legacy Service Bridge application, the related tasks have been closed, and the IDR connections have been deactivated the legacy Service Bridge application can be uninstalled (with the option to retain or delete the legacy Service Bridge tables).
Consumer migration
There is no Service Bridge Consumer migration utility. Migration is only necessary for Service Bridge providers. Consumers will register with the provider on the new Service Bridge application and their defined entitlements will determine which capabilities are delivered.
The legacy and new Service Bridge applications will run concurrently, and consumers will continue to function on the legacy Service Bridge application until entitlements are changed or the legacy connection is deactivated.
⚠️ While connected to a provider in both the legacy and new Service Bridge applications, the same consumer task should not be attached to a remote task in both the legacy and new applications. Work any existing legacy application tasks to closure in the legacy Service Bridge application so that there is no duplication or mapping confusion.
Summary
Migrating to the new Service Bridge applications offers significant advantages over the legacy versions, including an improved registration process, a more secure and reliable transport technology, enhanced troubleshooting capabilities, and a host of new features. With the legacy applications reaching their end of life in Q4 2024, migrating to the new versions is not just recommended, but essential to ensure continued access to the full range of benefits that Service Bridge provides. The migration process is straightforward and facilitated by a well-documented migration utility, making it easy for existing users to make the transition seamlessly. While the applications themselves offer a familiar experience, the new features and enhanced capabilities elevate Service Bridge to a new level, driving further efficiency and collaboration across the ServiceNow ecosystem.
