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 (firstname.lastname@example.org) 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:
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 email@example.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
So for example,
demo001.service-now.com 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 dev291.service-now.com.
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, an “Update Queue Status” UI action 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, “Update 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 in you have been provisioned in a vhost. Please contact firstname.lastname@example.org to set this up and for more information.
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.
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.