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:
To assign the perspectium_readonly role to a user in your ServiceNow instance, follow these steps:
form and click the Edit button under the Roles tab.
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.
The subscribing instance will need to be subscribing to all tables that the class name can be changed to (in the above example the cmdb_ci_ip_switch table as if you were only subscribed to the cmdb_ci_netgear table Replicator would “skip” the cmdb_ci_ip_switch update).
It is recommended you subscribe to global or the base table (such as cmdb_ci) in order for class name changes to replicate properly.
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");
On occasion there is a need to access a fields value using ServiceNow's http://wiki.servicenow.com/index.php?title=Dot-Walking feature.
The following example leverages this feature by sending the display value of a sys_domain's name value, subscribing it to update another instance of Servicenow.
Place the following line in the Before Share Script of your Bulk Share's or Dynamic Shares
current.sys_domain = current.sys_domain.name;
This will modify the outgoing record's payload to have the domain's name in the sys_domain column.
If you are Subscribing this into another ServiceNow instance you would have to handle it either with a Transform Map, or, you could set up a similar Before Subscribe Script to mirror this by grabbing the Domain corresponding to this name.
var domainVal = repl_gr.sys_domain; if(domainVal != null){ var dGR = new GlideRecord('sys_user_group'); dGR.addQuery('name', domainVal); dGR.queryNoDomain(); if(dGR.next()){ current.sys_domain = dgr.sys_id; } }
Date/Time fields in ServiceNow are stored in the database in UTC timezone. They are adjusted for the individual user’s local timezone as defined by their profile at runtime in the UI. This allows anyone viewing the data to see date/time values in their local timezone to avoid confusion. When we replicate that data we just replicate it as is in UTC, and write it to the target without doing any kind of timezone offset since there isn’t one in the context of a machine integration. Typically reporting solutions can account for this and adjust based on your end user’s needs.
This is fairly standard across most enterprise applications.
If you want to explicitly convert all data to a specific timezone for replication you can use a “BeforeShare Script” in bulk shares and dynamic shares to do this. We don’t recommend it, as it can cause issues if the reporting or viewing technology being uses then adjusts it again in their UI. You also need to consider the impact of Daylight Savings. Something converted and replicated during Standard Time, could be off by an hour compared to something converted during Daylight Savings time.
A simple example script to do this here shows converting sys_updated_on and opened_at to US/Eastern timezone during replication.
// Date/Time variables you want to update var timesToUpdate = ["opened_at", "sys_updated_on"]; var curTimeZone = "America/New_York"; // Get the specified timezone var tz = Packages.java.util.TimeZone.getTimeZone(curTimeZone); // Edit specified variables with the offset var time; var timeZoneOffset; for(var t in timesToUpdate){ time = new GlideDateTime(current.getValue(timesToUpdate[t])); time.setTZ(tz); timeZoneOffset = time.getTZOffset(); time.setNumericValue(time.getNumericValue() + timeZoneOffset); current.setValue(timesToUpdate[t], time); }
You would place this in the BeforeShare Script section for any shares where you need it, and specify those fields you want to convert. Here is some information on Before Share Script.
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:
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.