Once you have installed and configured DataSync for ServiceNow, and have successfully set up a bulk share and understand how it works, there are various bulk share settings you can configure. These optional features can help you customize your DataSync experience and leverage DataSync's robust capabilities to make your organization's integration processes more powerful and streamlined.
Explore all of these available features below!
This feature allows you to share history set data for the table that you are bulk sharing. History sets in ServiceNow identify which particular records from an audited table contain historical information. History set records only contain a recent subset of historical information (within the past 30 days of inactivity). The following fields will be visible to you in list view for history sets:
Field | Description |
---|---|
ID | An identifier for the record whose history is being recorded |
Table | The audited table for the record whose history is being recorded |
Load Time | The amount of time it took to generate the history set |
For more information about ServiceNow history sets, see history sets and differences between audit and history sets.
Here's how to enable the sharing of history set data for a bulk share:
With DataSync Agent, this option will create a sys_history_xxx table on the target database. |
This feature allows you to simply clone an existing bulk share or clone and immediately run an existing bulk share.
This feature allows you to preview a bulk share before executing it. You can see how many records will be shared out and details about when the shared records were created.
|
Here's how to preview a bulk share:
This feature allows you to run a bulk share as another user, rather than the default system user that has access to all of the table's records. This feature can be useful when you want to limit the bulk share to a subset of data that certain users have access to, such as records in one domain in your domain separated instance.
Here's how to enable this feature:
This feature allows you to run an existing bulk share again, once it has a status of Completed. You may want to run the same bulk share multiple times if your intent is to migrate the same table data intermittently.
Here's how:
This feature allows you to bulk share out only the sys_ids for specific records. This is useful for when you don't want to create filters for a bulk share.
Here's how:
This feature allows you to properly share database views with a bulk share. By default, bulk shares run by querying for records from the selected table in 1,000 record increments, with records ordered by sys_id in ascending order. This is done to minimize performance impact on the ServiceNow instance. However, the records of database views do not have sys_ids and therefore cannot be shared in the same way. In order to properly share database views with a bulk share, you need to query for all records from the view at once.
To do this, you need to specify the glide.db.max_view_records integer system property to a number above the records in your view. If this property is not set, it defaults to 10,000. A good number to use is 999,999.
This feature allows you to limit the number of records shared once bulk share reaches a specific limit.
Here's how to turn it on:
This feature allows you to share only records that have been inserted or updated since the last time the bulk share ran. This is useful for Scheduled Bulk Shares when you want to ensure you capture all records changed since the last execution of the bulk share.
Here's how to turn it on:
This feature will share archived records as regular table records as part of a bulk share, if and when there is an archived table for a specified table in the bulk share. If you choose to share child records, it will also share the records from the archived child tables.
This feature is to be used with the temporal feature in the DataSync Agent (see step 3).
Here's how to enable share as archive:
|
This feature allows you to distribute the work load of your bulk shares by allowing them to run on multiple nodes in your instance. This is useful if you're running multiple bulk shares or scheduled bulk shares, since they will run on the same node by default, and this could impact performance. If you use this feature, nodes will only be used if they are online ad set to accept "any" scheduler.
Here's how to turn it on:
This feature allows you to choose the number of jobs (1, 2, 4, 8, or 16) it will take to process the bulk shared records. Each job will process a subset of the total records, split by sys_id.
Here's how to customize the number of jobs:
This feature is not compatible with the following bulk share features:
|
This feature allows you to specify which node a bulk share will run on by referencing the sys_cluster_state table in ServiceNow. You need admin access (or a custom ACL rule) in order to see and set this value. You may want to run this feature in order to distribute the Perspectium processing across several nodes.
Here's how to specify nodes:
This feature allows you to customize the order in which your records in bulk share are sent out by choosing which field (such as Active, Updated, Created On etc.) the records will be ordered by when sending out the records. For example, if you choose the Created On field, the bulk share will send the records in ascending order based on the date and time at which they were created. By default, bulk shares will order records by the Sys ID (sys_id) field when querying for records to share out.
Here's how to send records in a specific order:
This feature allows you to share records from one or more related lists of the table being bulk shared. Here's how:
This feature allows you to create new tables in a subscribing ServiceNow instance by sharing a schema from one instance to another. This will create the table, field types, choices, labels, values, as well as the following:
Upon receiving the schema message, the table will be created in the instance and a generic subscribe record will be will be created to allow for replication of any records that come with the table schema.
Here's how to use share schema to replicate tables in a subscribing instance:
This feature allows you to include only specific fields in records shared out. This can be useful when you don't want to share out every field of the table to the target system.
If you are using this feature when bulk sharing to a database with the Table Compare feature (Enable confirmation option on the bulk share), see below for how to properly configure the DataSync Agent to work with both features. |
Here's how to share only selected fields for a specific dynamic share:
When bulk sharing to a database with the Table Compare feature (Enable confirmation option on the bulk share), the DataSync Agent by default relies on comparing the sys_mod_count column in the table.
So if you are using the Share only selected fields option, to ensure the Agent is able to properly compare records, you can do one of the following two options:
Then, in databases.xml, you will need to change the following values in the <database_type></database_type> section that corresponds to your target database. For example, if you are sharing to a MySQL database, you would modify the values in the <database_type>mysql</database_type> section:
Old Value | New Value |
---|---|
<most_recent_record_query>SELECT sys_id FROM %s WHERE sys_id = "%s" AND %s = "%s"</most_recent_record_query> | <most_recent_record_query>SELECT sys_id FROM %s WHERE sys_id = "%s"</most_recent_record_query> |
This change will remove the second part of the query (AND %s = "%s") where it checks for sys_mod_count.
Snippet of databases.xml with this change:
<database> <database_type>mysql</database_type> . <most_recent_record_query>SELECT Id FROM %s WHERE Id = "%s"</most_recent_record_query> . </database> |