Global Queue proof of concept v.2 - Support and Troubleshooting

Global Queue proof of concept v.2 Global queue is an alternative to expensive and time-consuming processes.

You can learn more information about Domain Separation on the product documentation site.

Global Queue proof of concept - Quebec release onward A proof of concept (POC) application is available as a reference to get started ( https://github.com/BobbyNow/GlobalQueueV2.git ). Here are the requirements and setup for using the application.

Summary

Service Providers with agents working on tasks from multiple systems tend to integrate the data back to a central instance, or a “swivel chair” between instances. While this method might be appropriate in some cases, it can be expensive and time-consuming to build and maintain. This method also opens the provider up to potential auditing and data requirement considerations such as General Data Protection Regulation (GDPR) in all of the instances where the data now lives.

Global queue is an alternative: With this method, agents can see data assigned to them from a single instance without sovereign data persisting on the instance they are logged into. For example, in cases where clients have data residency requirements, but allow access by agents from other countries, the provider could use a “follow-the-sun” Help Desk using global queue.

The POC application is available on GitHub (see Step 8 below). The POC uses a hybrid approach that assumes replication of some base data from the target instances back to the global queue instance to allow for reporting and greater performance with large numbers of records. Sovereign and other sensitive data is viewed non-persisted when previewing a single record, or accessing a records form. Below are requirements and setup for using the application.

Global Queue is intended to be used between instances that have common base data and process. For example, service providers can offer the same global service to customers from regional instances to adhere to data sovereignty laws.

Requirements

The same tables and fields (to be synced) exist on all instances that are part of the global queue The assigned to users exist on all instances with the same sys_id (for filtering) The assignment groups exist on all instances with the same sys_id (for filtering) The Companies exist on all instances with the same sys_id (for filtering and domain) State and Priority exist on all instances with the same names and values (for filtering) All tables in the global queue are extensions of task

NOTE: The Global Queue v2 application does not handle the replication of base data on an ongoing basis.

You can use “Instance Data Replication” or other suitable ServiceNow technology for that.

As part of this demo and setup there is a built-in mechanism to pre-populate the base data.

In addition, every time a record is queried from a target system, the base data is updated if out of sync.

Administration

Note: You will configure two instances for this POC. One instance is called the Source Instance and the other instance is Target Instance . You will need to complete all steps below for both instances. When complete, each instance can be used as a Global Queue instance.

Install the Global Queue V2 application from GitHub

Navigate to Connections & Credentials > Credentials . Click New . Click Basic Auth Credentials . Fill in the following fields: Name : User name : Password : Click Submit . Navigate to System Applications > Studio . Select Import From Source Control .

Fill in the following fields: URL : https://github.com/BobbyNow/GlobalQueueV2.git Branch : Clear this field Credential : Select your basic auth profile for GitHub from above Click Import .

Create Endpoint Auth Profiles for each target instance

Create a service account on your Target Instance and give it the admin role. Save the User ID and Password for the next step. Note : The admin role if for testing/demo only. If you build a global queue app for production, you should determine the minimum access required at that time.

2. Navigate to Global Queue V2 > Endpoint Auth Profiles on your Source Instance .

3. Click New .

4. Give the auth profile a name and fill in the Username and Password fields with the service account data saved from Step 1.

5. Click Submit .

Set up a new Endpoint

Navigate to Global Queue V2 > Endpoints . Select New . Fill out the form Name - Name of your record URL - Full URL of the Target Instance (e.g. https://myinstance.service-now.com) Credential - Select the magnifying glass and select the auth profile you created above. List URL – Used by the Map page. This is the URL for the list you want the user to end up in on the Target Instance when selecting the instance from the map. The default is https :// > .service-now.com/now/gq/agent/list/params/list-id/5842fed6db8fa010dc273027f396196e/tiny-id/e162321adb8fa010dc273027f3961983 For standard Agent Workspace enter: Latitude – The Lat for this target instance (Use https://www.latlong.net/ to determine) Longitude – The Long for this target instance (Use https://www.latlong.net/ to determine) Click Submit .

Associate endpoints to a virtual table

Navigate to Global Queue > Virtual Tables . Open the virtual table record you want to add the endpoint to. Select Edit under the Endpoints related list and associate any endpoints that you want to query for this table. Select Save .

Development

The following are Development modules under the Global Queue V2 application. No changes are expected to these to use the POC as designed.

GQ Task Table (Local)

This is the local table. It is labeled Remote Task (x_snc_gq2_task). This is the table you replicate base data into from other target instances that is not sovereign. For example: Number, Company, Assigned to, Assignment group, Priority, State. When troubleshooting, this is a good place to look to see if data is loaded correctly.

Virtual Table Definition

This is the definition for the Virtual table. No changes are needed here to use the POC, but it’s valuable in understanding how virtual tables work in case you build more for your Global Queue application.

GQ Task Table (Virtual)

This is the virtual table that was created using the Remote Table feature of the ServiceNow® platform. Notice that the virtual table is labeled Remote Task (x_snc_gq2_st_remote_task), just like the local table, but this table never stores data in this instance. The _st_ tag (Scripted Table) in the table name, just after the scope ID of x_snc_gq2 , signifies this table is virtual. You can also look at the Table record to confirm the Remote Table flag is set to true. This link pulls data from targets in real time and loads base data for those records into the GQ Task Table (Local) . Base fields are set in the GlobalQueueUtil script include using the insertRow method. GQ Map Page

This is an example map page using the system native Map Page capabilities. The map plots the various instances based on their Longitude and Latitude and shows how many open tasks exist in each instance.

- end of article -