Subscribed queues are a way to specify message queues a ServiceNow instance should read messages from. By default, ServiceNow instances subscribe to a queue named after its instance name (i.e. psp.out.servicenow.instancename) so this can be useful in cases where the agent should read messages from another queue in additional to its default one.
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.
2) Click the “New” button at the top to create a new subscribed queue:
where <name> is a name that is only letters and numbers with no spaces. For any questions about the proper queue name for your subscribing instance, please contact email@example.com.
4) When finished, click “Submit” to save this new subscribed queue.
Once a subscribed queue is created, the ServiceNow instance will automatically start listening for messages on the subscribed queue along with its default subscribed queue each time the Perspectium Replicator Subscriber scheduled job runs in the background (which by default is every 30 seconds).
For example, if your instance is named “dev” and you create a subscribed queue name “psp.out.servicenow.dev1”, every 30 seconds the Perspectium Replicator Subscriber job will first read form the default queue “psp.out.servicenow.dev” and then read from the subscribed queue “psp.out.servicenow.dev1”.
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.
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.
In v3.19.0 each instance's default subscribe queue will appear in the Subscribed Queues list. The Finish Install module will create the queue record in the list. This record can not be modified and will only update when Perspectium Replicator Properties is configured. Updating the properties will set the Endpoint URL, Queue Username and Password in the default subscribe queue automatically.
In v3.25.0 each record of the subscribe queues table will have a field referencing the instance the record was created on. This field will auto populate once a new record is created on the subscribe queues table.
This feature provides protection against cloned instances. The background job that subscribes to records from MBS for each queue will automatically check the instance created on field and deactivate any queues that were created on a different instance.