Setting up a Dynamic Share allows a ServiceNow instance to share table data as it updates in real time. The Subscriber (consumer) of this data can be any Perspectium supported integration: another ServiceNow instance, the Perspectium Replicator Agent, or one of Perspectium's supported SIAM integration endpoints.
You will define these Dynamic Shares per table that you want to share and specify the format, conditions, and destination of the messages. This setup can share multiple tables through the table hierarchy, run through advanced filters and scripts, share out related/auxiliary records, and more.
This page documents each of the core components of the Dynamic Share and the features related to it:
1. Go to the Replicator > Dynamic Share option under the Perspectium app:
Here you should see the list of your current Dynamic Shares, what they trigger on, and what queue they are pointing to. We will cover these settings further down.
2. 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 you will have to specify the following fields:
|Name||The name of this Dynamic Share, just used for display purposes||Incident DB Sync|
|Table||The table that you want to share from||incident|
|Active||Whether the Dynamic Share will replicate data or not||True (checked)|
|Create||Trigger the sharing when a record is created||True (checked)|
|Update||Trigger the sharing when a record is updated||True (checked)|
|Delete||Trigger the sharing when a record is deleted||False (unchecked)|
|Target Queue||The destination queue that you will be sharing to||psp.out.replicator.example|
If you have not created a target queue yet you can see here on creating them.
Once those fields are populated the Dynamic Share will be created and records should be getting shared out per your specifications. There are a lot of options available to you for Dynamic Share, so the further sections will cover how you can customize, filter, enrich, and backup your Sharing.
The following sections are broken down by tab of the Dynamic Share covering the tabs:
The Trigger Conditions control how and when the Dynamic Share is activated for a given base record. Base record referring to the table you specify in the “Table” option. This involves what type of operations you are triggering on, when the Business Rule is fired, and how to interact with the parent/child hierarchy.
When True (checked) this checkbox indicates to the Dynamic Share to only replicate data when a User has performed the operation, not some background job. For example: an interactive update is a user commenting or resolving an incident. A non-interactive update is a job closing resolved incidents after 7 days, the email engine creating records, discovery updating CI records.
From a technical standpoint this utilizes ServiceNow's interactive check to determine if the session is a user session or not.
The Dynamic Share is the configuration on how to share out a record. These are triggered by Business Rules on the table you specified. If you are unfamiliar with Business Rules, these are rules/actions defined per table that are ran when you create, update, or delete a record.
Through the Dynamic Share you can specify when this Business Rule runs with respect to other Business Rules and the actual update. This may impact your sharing with regards to Sharing between ServiceNow instances or other platforms such as for comment handling.
The options are:
For more information on this option, see Business Rule When.
These will correspond to the created Business Rule's allowed operations for the Dynamic Share. By marking these True (checked) the Dynamic Share will be triggered for each action of:
A message will be generated with respect to each action type. For example an incident message will generate a message with the following respective name:
Which will be handled by the Subscribing source as that action.
When marked True (Checked) messages will be marked as “bulk” (incident.bulk). The Subscribing source will then treat this as an “upsert” message and will query to see if this records exists. If so update that record otherwise insert that record. Checking this will automatically check the “Create” and “Update” checkboxes.
You may want to use this if the destination may not have been pre-seeded with the Dynamic Share's data.
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 Audit Delete [sys_audit_delete] table and enqueue deleted records noticed through this approach.
For more information on this option, see Use Audit Delete Listener.
This is a feature was introduced in Carbon. If you are changing the Class of a record, for example converting it from an Incident to a Problem you may want this. When you convert the class of a record you are retaining the primary key of the record, however, it belongs in new table. If you are sharing to a database this will mean that you have a record in the incident table that is orphaned as it no longer exists in ServiceNow. Enabling this will delete that orphaned incident record.
ServiceNow will handle class changes automatically, so you do not need to enable this for a ServiceNow to ServiceNow integration.
For more information on this option, see Delete on Class Change.
When selecting a table to Dynamically Share it is important to keep in mind the parent/child hierarchy of the record. ServiceNow covers that here under their Tables and Classes documentation.
By default we share out the records as the child class. This means that if you are sharing [cmdb_ci] you will receive Windows Servers, Linux Servers, Network Gear, etc. You will receive the record as it is defined (by the sys_class_name) in the single table it is defined by (Windows Server, Linux Server, Network Gear).
If you check “Share base table only” you are sharing the base table only as defined in your “Table” reference. This means that you are explicitly sharing the version of this record for the table that you will select. So if you are sharing [cmdb_ci] you will receive all records as the base [cmdb_ci] record into the [cmdb_ci] table with only the columns related to [cmdb_ci].
If you choose “Include All Child Tables Only” this will share out all the layers of the data. For our Windows Server example above that means a share on Configuration Item [cmdb_ci] will share out a Configuration Item, Hardware, Computer, Server, and Windows Server record, into the respective 5 tables.
You can read more about the handling for the ServiceNow Hierarchy here.
The additional settings of the Dynamic Share control how you share out the base record, share out related records, and where you share them to.
Through the Dynamic Share you can also share out any records related to the initial table records. This includes any:
Of the main record. By default this will share the related records per table as they are created.
The attachment options will share out the sys_attachment (metadata) as well as the sys_attachment_doc (data) records for the attachments. So if Sharing to another ServiceNow instance you will need to Subscribe to both sys_attachment and the sys_attachment_doc to get the entire attachment. Attachment deletes are not currently supported through this checkbox. This will require you to create a Dynamic Share against those if you want to support this.
A checkbox to indicate if embedded images/videos related to this table should also be shared. This is in general more for legacy knowledge records where data was embedded in their wiki / html as opposed to an attachment.
You can read more about sharing embedded images / videos here.
Comments in ServiceNow are stored within the table Journal Field [sys_journal_field] and are related to the base record. In other words, they are not stored directly on the base record.
You can read more about the handling for these two from the following:
This feature can be used to share referenced field records related to you base table. For example, you can set this up on your Incident Dynamic Share to Share the “Assigned To” User [sys_user] and the Configuration Item [cmdb_ci] of the Incident, for each Incident.
You may want to use this if you cannot easily define the parameters to share out the referenced records otherwise. However, if you can we recommend you to set up individual Dynamic Shares for those records instead.
You can read more about this feature Include Referenced Field Records here.
This feature is used to customize the payload of the Outbound Message in a very granular way. These are utilized in our SIAM integrations to create a message that be easily sent to other ServiceNow instances or platforms (Jira, Salesforce, Remedy, etc).
If you are just replicating to a database you will likely not need these, however, if you are creating an integration between two parties this will likely be of assistance.
You can read more about this feature, Table Maps here.
As an advanced option you can configure Table Maps per referenced record. So when using the “Include Journal Fields” option you can apply a Table Map to modify the payload of the Journal Field message.
You can read more about this feature, Share Table Maps here
The specific queue that data from this table will be sent to for Subcribing/consumption by another instance. This queue will need to be defined in Shared Queues.
A target queue must be specified for a Dynamic Share to be created.
You may specify a view name within the Additional Settings to limit the fields shared out to just the fields available in a view. By default we share out all fields on the table.
You can read more about this feature, Field Restriction Using UI Views here.
These are an advanced option to provide greater control within a single Dynamic Share. You may use them if for example you are sharing Incident to 5 clients. They each have their own Shared Queue and their own Table Map. Within this single Dynamic Share you can create 5 conditional shares to route off the data appropriately. It is helpful when you are Sharing the same table with several configuration with minor differences.
You can read more about this feature, Conditional Shares here.
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 or one assignment group you would define that condition within here. Using this in combination with “Target queue” allows you to configure strict Sharing configurations to defined endpoints.
This is a script that gets executed right before the shared message 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.
This is a script that gets executed right after the shared message 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.
You can have greater control on when to Dynamically Share out records by selecting certain updates to trigger the Dynamic Share or certain updates to skip the Dynamic Share.
You may want to use this for example you are Sharing the User [sys_user] table. Every time a user logs in it updates the “Last Login Time” column. If this is the only column that was updated you might not care to share this out every time they login. Another common example is using discovery which updates the “Last Discovered” column frequently despite not anything else.
You will specify columns to ignore on. If you put in columns A, B, C and a message will only be sent if anything other than those columns are updated.
This is really the reverse of the previous option where you are specifying the updates to certain columns to trigger on. For example if you only want to update your CI information when the “Install Status” or “IP Address” changes than you can configure that here.
You will specify columns to ignore on. If you put in columns A, B, C and a message will only be sent if anyone of those columns are updated.
How to implement these two options are detailed here, along with how to manually configure the same within a Before Share Script instead.
You can specify within this to Share Only Selected Fields. After marking this True (checked) and saving the form you will add in records into the related list to specify which subset of columns you want to replicate. You may want to use this to restrict what data you are sending between destinations. You can equivalently use a Table Map to accomplish something similar.
You can read more about this feature, Share only Selected Fields here.
You can specify to share only the fields which have been updated. This is a fairly uncommon use cases as most of the Subscribing tools we have will account for this automatically. However, if you want to limit the outbound data you can utilize this feature.
You can read more about this feature, Share Only Updated Fields here.
For the most part if you want to utilize this you will just specify an “Interval” and hit “Activate Sync”. You can choose an interval of 5, 30, or 60 minutes to say every interval Share out all the records which have been updated since the last time I ran.
This can be helpful to provide redundancy in your Sharing or to account for records which are being updated without triggering the Business Rules.
You can read more about this feature, Scheduled Sync Up here.
This tab is only available if the “Advanced” box is checked
You can enable Data Obfuscation to comply with the General Data Protection Regulation (GDPR) to obfuscate patterns/sets of data as they are leaving the instance.
You can read more about this feature, Data Obfuscation here.
Users are validated from choosing tables that do not support dynamic share business rule. Here is the list of tables that are not supported:
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.
As of the Europium release, you can create a dynamic share that will be run within a specific domain. To create a domain-specific dynamic share: