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 (support@perspectium.com) 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:
psp.out.servicenow.<instance_name>
or
psp.out.replicator.<agent_name>
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 support@perspectium.com.
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.
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
psp.out.servicenow.<instance_name>
So for example, demo001.service-now.com
is provisioned to read from
psp.out.servicenow.demo001
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
psp.out.replicator.<agent_name>
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
psp.out.replicator.demo_mysql
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 dev291.service-now.com.
v3.10
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.
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.
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.
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.
Purging queues is only supported if you have been provisioned in a vhost. Please contact support@perspectium.com 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.
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.
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.
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: