Online Documentation

Here you will find some tips and tricks to help in using the Perspectium Replicator application in your instance. For any questions, please contact support@perspectium.com

The role perspectium_readonly can be assigned to any users accessing your ServiceNow instance. Assigning the perspectium_readonly role will restrict Perspectium Replicator for ServiceNow functionality so that users cannot delete, modify, or create new records for the following:

• Shared/Subscribed Queues
• Bulk/Scheduled Bulk/Dynamic Shares
• Table/Transform Maps
• Perspectium Properties

To assign the perspectium_readonly role to a user in your ServiceNow instance, follow these steps:

1. Log into your ServiceNow instance as a System Administrator.
2. In the top left navigation window, type User Administration and then navigate to User Administration > Users
3. Click into the user whose role you want to change. Then, scroll down to the bottom of the User

form and click the Edit button under the Roles tab.

1. In the left side search window under Collection, type perspectium_readonly. Then, select the perspectium_readonly role and move it to the Roles List by clicking >. Finally, click Save.

Records that exceed either ServiceNow or Perspectium's record size limit cannot be bulk or dynamic shared out. To check which records or fields are too large to send, log into the ServiceNow instance you are trying to share from and navigate to Perspectium > Logs. For any records that are too large to bulk/dynamic share out, you will see an error message indicating the record size limit that was exceeded as well as any fields that were notably large.

If you have a table such as incident that has an activity log showing sys_journal_field entries and you're seeing duplicate entries, try turning off “Run business rules” and “Refresh history set” on the incident table Replicator subscribe configuration.

Since you already are doing “Refresh history set” on the sys_journal_field table itself, running refresh history set on the incident table will cause it to refresh twice and because of the way ServiceNow handles timing and refreshing history set, it can cause two entries to occur.

As well, running business rules can cause duplicate entries to be created as well since a business rule may cause the system to believe two different events are occurring and thus two duplicate entries.

However turning off “Run business rules” will disable the table's events business rule (for example the “incident events” business rule for the incident table) that is run to create events in the event log.

If you want these events to occur, you can execute them in the Before subscribe script of the table's subscribe configuration using the ServiceNow function that actually fires the event (gs.eventQueue()) and the gr_before and repl_gr GlideRecord objects available in Before subscribe script.

For example, to have the “incident.assigned.to.group” event fired when the assignment group is changed, you would have the following script in Before subscribe script:

if (gr_before.assignment_group != repl_gr.assignment_group) {
  gs.eventQueue("incident.assigned.to.group", current, current.assignment_group, previous.assignment_group.getDisplayValue());
}

Note that for fields that are not stored in the table itself and are stored in the sys_journal_field table, such as the comments field in the incident table, you would want to have the script in the Before subscribe script of the sys_journal_field configuration as follows:

if(repl_gr.element == "comments" ){
    var igr = new GlideRecord("incident");
    if(igr.get(repl_gr.element_id)){
        gs.eventQueue("incident.commented", igr, gs.getUserID(), gs.getUserName());
    }
}

In this case, the incoming sys_journal_field record is checked to verify it is a comments record and that is for the incident table by checking if the sys_id in the record exists in the incident table. If it does, then the “incident.commented” event is fired using the incident record itself (igr) to ensure the event is properly created.

v3.2.9 patch1
For replicating between ServiceNow instances, changes to the class name are supported so that subscribing instances will also update the record's class name. This is most useful with configuration items (cmdb_ci) where discovery runs and changes the class name of configuration items (because they were created with the wrong class name) and you want these changes to replicate properly.

For example, if you have a network gear (cmdb_ci_netgear) item:
And you change the class to a different class such as IP Switch (cmdb_ci_ip_switch), Replicator will send out a cmdb_ci_ip_switch record and the subscribing instance will notice the change in class and update it appropriately.

There are occasions when Dynamic Share on a table is not getting triggered because the table modification is performed by a script or Import Set Transform Map that is stopping subsequent business rules from running. In the latter case, the Run Business Rule checkbox may have been unselected. In the other case, the setWorkflow(false) API may have been called.

In either case, you can trigger Replicator directly by inserting the following code snippet in your script at the right position. Note a Dynamic Share configuration for the table will have to be created.

var psp = new PerspectiumReplicator();
psp.shareRecord(GR, "table_name", "operation");

• GR - the current GlideRecord
• “table_name” - the table name of the GlideRecord
• “operation” - the mode you want to trigger replication, options are “insert”, “update”, or “delete”

For tables that have HTML fields, such as the Knowledge (kb_knowledge) table and its text field, use the encrypted_multibyte encryption mode to ensure the HTML fields are sent out properly.

Otherwise, HTML fields may be sent with extraneous characters for spaces as show below:



By default, ServiceNow instances and the Replicator agent support the various encryption modes out of the box so there is no additional configuration required on the subscribing side.

If you are seeing that you are not sending data out of your instance as fast as you would like it is important to understand all the pieces first:

• Is the count of my Outbound Messages [psp_out_message] consistently very high (+250k Ready Message)?
• Is my property for maximum bytes per post too low (should be in the 5 MB to 10 MB range)?
• Is my property for max record per post too low (should be around 2000-4000 records)?
• How often is my Perspectium MultiOutput Processing job running (default to 30 seconds)?

These are the typical things we look at for optimizations first prior to adding in Multiple MultiOutput jobs. If these are all set as expected and the throughput is still not enough you can read about multiple jobs here.

If you see slow subscribe performance in your instance, check System Diagnostics > Slow Queries to see if any slow queries are running on subscribe. See if these slow queries are a result of “Run business rules” selected on the subscribe and turn those off if not needed.

If you see a field that a query is always running on, see if that field is indexed or not, and if not add an index to that field to help improve performance.

If you want to interactively walk through major components of the replicator, use the ServiceNow Tour feature.

To take a tour of a feature of the replicator, click on the question-mark icon in the top-right corner.

A sidebar should pop up. Click on “Take a Tour” in the bottom-right corner to take the tour.

To navigate through the tour click the “next” button in the bubble. To end the tour click the “x” in the top-right corner of the bubble.

The following pages have the tour feature: bulk share list, bulk share, dynamic share list, dynamic share, inbound messages list, log message list, outbound message list, performance stats, queues list, scheduled bulk share list, scheduled bulk share, script include list, script include, subscribe list, subscribe, table compare, table map list, table map.