User Tools

Site Tools


Shared Queues

Shared queues are a way to specify message queues a table should share to when creating a share configuration. This can be useful in cases where you want a specific set of data (such as one company's data) be shared with one particular instance.

Please ensure you have the proper credentials to create the message queue or the queue has been created by the Perspectium team ( on the Perspectium server before creating it here inside ServiceNow.

1) To create a shared queue, go to the Replicator > Shared Queues option in the Perspectium app:

2) Click the “New” button at the top to create a new shared queue:

3) The Shared Queue form will appear with the following fields:

  • Name : This is the name of the message queue itself. This will generally be in the format of



    where <instance_name> is the name of the subscribing ServiceNow instance or <agent_name> is the name of the subscribing replicator agent that will be receiving messages on this queue. For any questions about the proper queue name for your subscribing instance, please contact

  • Endpoint URL : Click on the lock icon to edit the field and enter the server URL as provided by Perspectium (this will usually be the same URL as found in the Configuration > Properties page). Note the value here should be entered starting with “https:” and with an ending slash “/” such as
  • Queue user : The message queue username as provided by Perspectium.
  • Queue user password : The message queue password as provided by Perspectium.
  • Direction : The field will default with the value “Share” and should be left as is.
  • Order : The order for which the data is being processed, a smaller number will cause the data to be sent sooner.
  • Active : A checkbox to indicate if this shared queue is active and available to be used.

Note that in v3.16 multiple queues cannot have matching names and endpoint regardless of direction (share or subscribe).

Note that in v3.17 queues cannot have the default subscribed queue's name (i.e “psp.out.servicenow.<instance>”).

Note that in v3.20 the instance field is removed from the form as it is unused

4) When finished, click “Submit” to save this new shared queue. This shared queue will now be available for use in the “Target queue” field when creating a new share configuration.

Targeting a specific ServiceNow Instance or Replicator Agent

All ServiceNow instances that are integrated with Perspectium are provisioned with a message queue that is read by default. This message queue will have the format of


So for example, is provisioned to read from


However, to read or write to this message queue, the client would first have to have the credentials and the server endpoint configured. The Shared Queue entry allows you to configure all three of these parameters.

Replicator agents are similarly provisioned with a message queue that is read by default. This message queue will have the format of


and is based on the “Agent Name” as specified when first installing the agent. For example, the agent named demo_mysql is provisioned to read from


For the case when another Replicator agent or ServiceNow instance wishes to enqueue replication records specifically to target another ServiceNow instance or Replicator agent, just create a new Shared Queue entry with the right credentials, endpoint, and queue name for that instance and use it in your Bulk Share or Dynamic Share. The following example shows a Shared Queue configuration for the ServiceNow instance

Separate encryption and decryption keys per queue


Normally, within the same company implementation of Replicator the use of one universal encryption key for both outbound and inbound messages is sufficient and convenient.

There comes a time when an external integration with another company such as a service provider is required but giving out the universal encryption key is both insecure and unmanageable. This feature allows separate encryption and decryption keys to be defined for both outbound messages and received message symmetrically so that a pre-agreed key can be shared with an external consumer of integration data without risk.

Shared Queue Record Encryption Key

By specifying a 24 or more character encryption key in the following Shared Queue definition, ensures that all data flowing through this queue will be encrypted using only this key.

Subscribed Queue Record Encryption Key

By specifying a 24 or more character encryption key in the following Subscribed Queue definition, ensures that all data coming in through this queue will be decrypted using only this key.

2016/06/02 16:09 · David Loo

Get Queue Status

In v3.13.0, a “Get Queue Status” button has been added that will allow you to test the connection of the queue and display the current number of messages in the queue.

When clicked, “Get Queue Status” will use attempt to connect to the endpoint URL using the queue user and password to query the queue name for the number of messages it currently contains. The result of trying to connect and query the queue will be displayed in the “Status” field:

In v3.18.0 of both the update set and MBS, the message will display if the queue does not exist instead of displaying an error as in previous versions. We've also added the ability for include your Queue Status within the Replicator Overview page.

Purge Queue


Purging queues is only supported if you have been provisioned in a vhost. Please contact to set this up and for more information.

The “Purge Queue” UI action allows you to purge a queue of all messages in it. This is useful if you ran a large bulk share and no longer want or need a subscriber to consume these messages.

When clicked, “Purge Queue” will attempt to connect to the endpoint URL using the queue user and password to purge the queue of all the messages it currently contains. The result of trying to purge the queue will be displayed in the “Status” field.

Proceed with caution when purging a queue as the messages cannot be recovered.

In v3.24.0 the user can no longer purge a queue that contains over 1 million records. The user must contact support to purge the queue.

2017/03/07 13:47 · Paul Nguyen

Instance Created On


Shared queues contain an “Instance Created On” field which is auto-populated based on the name of the instance in which the queue was created. This field is leveraged in cases of instance migrations where shares should not be triggered on migration.

Resetting "Instance Created On"

At the bottom of your shared queue, there is a UI action where you can reset the “Instance Created On” field to be your current instance. This should be used in cases where you migrated your instance and then want to reactivated a shared queue.

Perform a Load Test


You can determine the impact a dynamic or bulk share will have on your sharing ServiceNow instance by enabling the Load Test option. To do this:

  1. Log into your sharing ServiceNow instance and navigate to the Shared Queues module.
  2. Create a new shared queue record or click into the shared queue record that you want to perform a load test for.
  3. At the bottom of the form underneath the Active checkbox, check the Load Test box. Then, click Update
  4. Navigate to the Bulk Share or Dynamic Share module and locate any bulk/dynamic shares with the same target queue which you have enabled a load test for. For bulk shares, the Duration field will indicate the approximate time it will take for your sharing instance to process the bulk share.
replicator_snc_shared_queues.txt · Last modified: 2019/03/13 21:56 by timothy.pike