Setting up dynamic share allows a ServiceNow instance to share table data in real time. The consumer or subscriber of this data can be another instance of ServiceNow or a Perspectium Agent. You will need to create a share configuration for each table you want to share.
1) Go to the Replicator > Dynamic Share option under the Perspectium app:
2) The Perspectium app comes with some of the more common tables to be replicated such as incident and problem. Click on one of those tables or choose the “New” option at the top to go to the table share configuration form:
3) On the table share configuration form, the following options are available:
To quickly set up a table for sharing, choose a table from the dropdown and then have the “Active”, “Create”, “Delete” and “Update” checkboxes all checked. You can choose the “Activate all” (15) option at the bottom of the form and this will checkmark all four checkboxes (and “Deactivate all” (16) will in the opposite case uncheck all four).
Name: The name of Dynamic Share configuration. This helps to distinguish and organize different configurations i.e. Oracle Database, ServiceNow DEV to UAT, SIAM Jira, etc. C Release
Table : The name of the table to share data.
Active : A checkbox to indicate if this table is actively sharing.
Users are validated from choosing tables that do not support dynamic share business rule. Here is the list of tables that are not supported:
When selecting a table to dynamically share, keep in mind that the actual child table record could be shared instead. See ServiceNow tables and classes. For example, when sharing cmdb_ci_server table will produce shared output for any child table records like cmdb_ci_unix_server or cmdb_ci_win_server because these tables extend cmdb_ci_server. This design will prevent parent records from being shared without their absolute child records which would cause data corruption at the subscriber.
Direction : Share - This field will not be editable as it is used for both share and subscribe configurations and indicates the type of configuration.
Shared Records : The number of records that have been shared as of this time. This field can be ignored.
Interactive Only : a checkbox to indicate if the replication should only happen when a record changes from the user interface (i.e ignore replicating changes from background jobs).
Specifies the order number for the replication business rule. In certain situations, you may want to change this value in order for the dynamic share trigger to execute prior to any other business rules. There may be a situation that a system our custom business rule executes the setWorkflow(false) API such that our trigger is bypassed, you will want to identify that business rule and adjust our trigger to run before that.
The default value is 50 but changing the value may be useful for when conflicts with other business rules on the table lead to the following error:
Exception (TypeError: Cannot convert null to an object. (; line 1)) occured while evaluating'Condition: PerspectiumReplicator.isReplicatedTable(current.getTableName(), "share", current.operation().toString())' in business rule 'Perspectium Replicate' on cmn_location:Test; skipping business rule
In this case you will want to change the business rule order to a lower number (such as 1) so that dynamic sharing happens before other business rules are processed which create this error.
Update or Insert : A checkbox to indicate that this dynamically shared record is subjected to an update (by sys_id) or insert if current record is not found, at the consumer. v3.1.8
In general, it is suggested to select this option. If this option is not selected and an update to a record is shared where the record does not exist on the consumer, the consumer will skip processing the message since it does not have the record to update. Selecting this option ensure the record will be created in this scenario.
Not selecting this option is usually only best for performance considerations (such as a table that is dynamically sharing thousands or millions of records each day) and when you know this sharing instance and its consumers have the same records when dynamically sharing was enabled for this table.
Share Base Table Only : By default, Dynamic Share will share the child table records of the configured table. By checking the new option Share base table only, you are instructing the dynamic share process to only share the table records of the table that is configured.
Create : A checkbox to indicate if this table will share records on creation.
Delete : A checkbox to indicate if this table will share records on deletion.
Use Audit Delete Listener : This feature allows Dynamic Share configurations to capture delete events for records that may have bypassed the ordinary “delete” business rule, for example an up stream business rule that calls “setWorkflow('false')” or cascade deletes. Setting this option will create an “on insert” business rule on the sys_audit_delete table and enqueue deleted records noticed through this approach.
Update : A checkbox to indicate if this table will share records on update.
Delete On Class Change : This is a feature introduced in vCarbon. You can read more about it here. In summary it is to delete the “orphaned” record left over in your external database when you change the class of a record.
A checkbox to indicate if sys_journal_field entries related to records in this table should also be shared.
When this option is selected, the “Include audit log” checkbox option will appear allowing you to specify if you want to share related sys_audit records as well.
As of release v3.19.0 the sys_journal checkbox option is no longer needed for the Include audit log checkbox to appear. This allows the user to share the sys_audit records without sharing the sys_journal records.
For ServiceNow to ServiceNow replication you will want to select both journal field and audit log options to accurately update the history/activity log on the subscribing instance. As well, you will want to either have a “global” subscribe or subscribe to both the sys_journal_field and sys_audit tables on the subscribing instance to receive these records.
Prior to v3.11.0, selecting the “Include journal fields” option would automatically share both sys_journal_field and sys_audit records. By upgrading to v3.11.0+, the “Include audit log” option is not selected by default on any current dynamic or scheduled bulk shares and thus sys_audit records will not be shared out. You will have to go into each dynamic or scheduled bulk share and select the “Include audit log” option in order to continue sharing sys_audit records.
A checkbox to indicate if attachments related to this table should also be shared.
Note that on the instance where you set up subscribe, you will need to set up the sys_attachment and sys_attachment_doc tables as active subscribers for this option to work.
Because attachments are included using script actions to capture them when they're attached to a record, attachment deletes will also require their own Dynamic Share as the “Include Attachments” button does not account for attachment deletes.
Attachments do not honor the ignore flag in the before share script and thus any attachments will be shared out if it meets the dynamic share's conditions.
Include embedded images/videos : A checkbox to indicate if embedded images/videos related to this table should also be shared.
A checkbox to indicate if referenced field records related to this table should also be shared.
You can read more about this feature Include Referenced Field Records here.
Table Map : This feature is used to map and/or transform the outbound SericeNow field data for the record being replicated.
Target queue : A specific queue that data from this table should be sent to for reading by another instance. This queue will need to be defined in Shared Queues. This is useful for a case where you want to send specific data to one instance (such as a specific customer's data you indicate in the Condition section) and you don't want that instance to be able to subscribe to other data from your sharing instance. In general you can leave this option blank.
A set of conditions in order to share data from this table. For example, if you want to share only data related to one customer you would specify a condition here. Using this in combination with “Target queue” allows you to configure it such that only a specific set of data will be shared with one particular queue/instance so as to restrict that subscribing instance to only receive a set of data such as one customer's data.
This is a script that gets executed right before the shared object is being queued up. The object is in GlideRecord type and can be accessed via the globally available variable called current. For an example of how to use this script, go here. v3.1.8
Activate Sync : Check this box to start the sync.
Started : The time syncs started
Stopped : The time syncing stopped
Interval : The intervals for syncing, choice of 5, 30, or 60 minutes
Last Time Sync : The last time syncing occurred, this also marks when the data should start for each sync
Number of Records Synced Last Interval : The number of records from the Last sync time that needed to be sync
Note if you have multiple share configurations for the same table (such as different share configurations that each have a different target queue), any changes to the current object may affect any conditions you have to share since this same current object is referenced as we iterate through the table's different share configurations.
For example, if your have multiple share conditions for the ticket table (one will share to the target queue psp.out.servicenow.test and the other shares to the queue psp.out.servicenow.dev) and all have the condition short_description is 'test' in order to share records, if one of your share configurations has the before share script of: current.short_description = 'test123'
Then other share configurations for this will not share the record to their target queues since the short_description of the current object has been changed to 'test123'.
4) Once done, click “Submit” (new table configuration) or “Update” (current configuration) to save your changes. Next you will need to setup a subscribe configuration on SNC instance you wish to receive data from this sharing instance.
Note if any fields do not appear on your form, right-click on the “Replicator Configuration” title and choose Personalize > Form Layout and then add the missing fields to the form.
In version v3.16.0 users can create multiple dynamic shares with the same table and queue name. Dynamic Share's creation will be blocked on uniqueness only when there is a matching dynamic share with matching: Table, Target Queue, Business Rule when, Insert, Update, and Delete.
By default, dynamic and bulk share will share all fields available in a table. There are times when you want to control the number of fields being shared from your ServiceNow table. By specifying a UI Form View in the definition for Dynamic Share or Bulk Share you can limit the fields to only those that appear on the form view that you have personalized. See Personalizing Form Views in ServiceNow
Using Form View to restrict fields does not make sharing data run faster, rather it is slower because more work needs to be done to remove the fields you don't want to share
The dynamic share example below shows using the Self Service (ess) Form View for Incident to limit the sharing only to the fields in that view.
You want to use the actual Form View name, not the Title for the View Name value. For example, use ess instead of Self Service.
The example below show the same view being used in a bulk share.
The number of records returned in a view is based on the glide.db.max_view_records system property. Bulk shares of any views that have more records than this property will only be able to share this number of records and because of the way ServiceNow stores records, you will need to specify a condition on the bulk share to query based on a field that you know will not be empty on all records.
This feature allows Dynamic Share configurations to capture delete events for records that may have bypassed the ordinary “delete” business rule, for example an up stream business rule that calls “setWorkflow('false')” or cascade deletes. Setting this option will create an “on insert” business rule on the sys_audit_delete table and enqueue deleted records noticed through this approach.
You can identify this Business Rule within your Business Rule table by filtering for those on the sys_audit_delete table and whose name starts with “Perspectium DL”.
Known Issue: There is currently a bug set to be fixed with Update Set v3.20.0. This bug can allow multiple Business Rules to be created for a single Dynamic Share configuration with this enabled. This would happen with each subsequent update to the Dynamic Share form. If you are using this it is recommended to verify the “Perspectium DL” Business Rules match the expected number.
If you would like instructions on how to circumvent this without a full version Upgrade contact email@example.com for instructions.
This tab is only available if the “Advanced” box is checked
On domain separated instances you will have to take into account the domain of the Dynamic Share's Business Rule. Each Dynamic Share will have a corresponding Business Rule to process the insert/update/delete of a record. This Business Rule will be created in the domain of the current user. That Dynamic Share will then only apply to that domain of records.
For example, if the user creates a new incident record in the Top/Alpha domain, the record's domain will be saved as Top/Alpha. If the Dynamic Share was created by a user in the Top/Beta domain the Business Rule will be created in the Top/Beta domain. This will then mean that this Business Rule, and therefore this Dynamic Share, won't replicate the incident we just created in the Top/Alpha domain.
We recommend you to change your domain to “Global” prior to creating your Dynamic Shares. If the Dynamic Share was created under the Global domain than there is no issue as it will then apply to all domains. It is possible to set the domain of this to Top which in our example above would apply for both Top/Alpha and Top/Beta.
You can see all your Dynamic Share's Business Rules, and their domain, by going to the Business Rules module under Replicator.
The Business Rule's domain will be set to the user's domain upon creation. This is handled internally by ServiceNow's scripts. So we cannot enforce / override this by setting the domain to global automatically. This issue currently being reviewed and may change at a future date.
If you are on domain separated instance, then you can now see the domain and application scope the share's business is created in under Business Rule. For example if you created a dynamic share's business rule in global domain and application scope, then it will look something like this
If you are not on domain separated instance, then the domain field in the business rule will be hidden. This is because the domain for domain non-separated instance will always be global. The business rule will look something like this for non-separated instances
You can also find a general picture of where all of your dynamic share business rules are created in on Dynamic Share Business Rule Dashboard. Click here for more information.