User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
replicator_snc_share [2018/08/07 16:19]
replicator_snc_share [2019/01/17 10:48] (current)
timothy.pike [Overview]
Line 1: Line 1:
-====== Dynamic Share ======+====== ​ServiceNow ​Dynamic Share ====== 
 +===== Overview ===== 
 +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_new|Replicator Agent]], or one of Perspectium'​s supported [[start#​siam|SIAM integration]] endpoints.
-Setting up dynamic share allows a ServiceNow instance ​to share table data in real timeThe consumer or subscriber ​of this data can be another instance ​of ServiceNow or a [[replicator_agent|Perspectium Agent]]. You will need to create ​share configuration for each table you want to share.+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: 
 +  * Creating ​Dynamic Share 
 +  * Trigger Conditions 
 +  * Additional Settings 
 +  * Filter and Enrichment 
 +  * Advanced Settings 
 +  * Notes 
 +  * UI Actions 
 +  * Related List Tables
 ===== Creating a Dynamic Share ===== ===== Creating a Dynamic Share =====
-//1) Go to the Replicator > Dynamic Share option under the Perspectium app://+==== Initial Setup ====
-{{:​ne_dynamic_share.png?200|}}+1Go 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://+{{:​ne_dynamic_share.png?​150|}} 
 +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.
 {{:​replicator_configurations2.png|}} {{:​replicator_configurations2.png|}}
-//3On the table share configuration form, the following options are available://+2. Choose the "​New"​ option at the top to go to the table share configuration form: 
 +3On the table share configuration form, the following options are available:
 {{:​share_configurations2.png|}} {{:​share_configurations2.png|}}
-<WRAP round tip> +To quickly set up a table for sharing ​you will have to specify the following fields: 
-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" ​(15option at the bottom of the form and this will checkmark all four checkboxes ​(and "​Deactivate all" (16will in the opposite case uncheck all four). +^ Field  ^ Description ​ ^ Example ​ ^ 
-</​WRAP>​ +| Name  | The name of this Dynamic Sharejust used for display purposes ​ | Incident DB Sync  | 
-**Name**: The name of Dynamic Share configuration. This helps to distinguish and organize different configurations i.eOracle Database, ServiceNow DEV to UAT, SIAM Jira, etc. +| Table  | The table that you want to share from  | incident ​ | 
-<wrap info>​[[updateset_releases|C Release]]</​wrap>​+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 | 
 +| [[:replicator_snc_shared_queues|Target Queue]] | The destination queue that you will be sharing ​to  | psp.out.replicator.example ​|
-{{::dyn_name_field.png?​nolink|}}+If you have not created a target queue yet you can see [[::replicator_snc_shared_queues|here]] on creating them.
-**Table** : The name of the table to share data.+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.
-**Active** : A checkbox ​to indicate if this table is actively sharing.+---- 
 +====== Configuration ====== 
 +The following sections are broken down by tab of the Dynamic Share covering the tabs: 
 +  ​Trigger Conditions (when to Share) 
 +  ​Additional Settitngs (what and where to Share) 
 +  ​Filter and Enrichment (what to skip and add) 
 +  ​Scheduled Sync Up (how to backup) 
 +  * Advanced options
-{{:​table.png|}} +=====Trigger Conditions===== 
-<WRAP round info> +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.
-Users are validated from choosing tables that do not support dynamic share business rule.  +
-Here is the list of tables that are not supported:​ +
-  - Sys Audit[sys_audit] +
-  - User Role [sys_user_has_role] +
-<WRAP round info> +{{::​dynamicshare_trigger_conditions.png|}}
-When selecting a table to dynamically share, keep in mind that the actual child table record could be shared instead. See [[​index.php?​title=Tables_and_Classes|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.+==== Interactive Only ==== 
 +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.
-{{:direction.png|}}+From a technical standpoint this utilizes [[​bundle/​jakarta-application-development/​page/​app-store/​dev_portal/​API_reference/​GlideSystem/​concept/​c_GlideSystemAPI.html#​r_GS-isInteractive|ServiceNow'​s interactive check]] to determine if the session is a user session or not.
-**Shared Records** : The number of records ​that have been shared as of this time.  ​This field can be ignored.+==== Business Rule ==== 
 +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.  ​
-{{:​shared_records.png|}}+Through the Dynamic Share you can specify when this Business Rule runs with respect to other Business Rules and the actual updateThis may impact your sharing with regards to Sharing between ServiceNow instances or other platforms such as for [[:​snc_comment_handling|comment handling]]. ​
-=====Trigger Conditions=====+The options are: 
 +  * Before (share the record before the insert/​update/​delete) 
 +  * After (share the record after the insert/​update/​delete) 
 +  * Async (share the record asynchronously to the insert/​update - deletes not allowed)
-{{:trigger_conditions.png|}}+For more information on this option, see [[::​snc_business_rule_when|Business Rule When]].
-**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).+==== Create / Update / Delete ==== 
 +These will correspond ​to the created Business Rule's allowed operations for the Dynamic ShareBy marking these True (checkedthe Dynamic Share will be triggered for each action of: 
 +  * Creating a record 
 +  * Updating a record 
 +  * Deleting a record
-{{:interactive_only.png|}}+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: 
 +  * incident.insert 
 +  * incident.update 
 +  * incident.delete
-====Business Rule When==== +Which will be handled by the Subscribing source as that action.
-<wrap info>​[[updateset_releases|v3.8.0]]</​wrap>​\\ +
-\\ +
-Specifies [[http://​​index.php?​title=Business_Rules#​When_Business_Rules_Run|when]] ​the replication business rule should run.  For more information on this option, see [[snc_business_rule_when|Business Rule When]].+
-{{:​business_rule_when.png|}}+=== Update Or Insert === 
 +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.
-====Business Rule Order==== +==== Audit Delete Listener ​==== 
-<wrap info>​v3.2.7 patch3</​wrap>​\\ +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.
-\\ +
-Specifies the [[http://​​index.php?​title=Execution_Order_of_Scripts_and_Engines#​|order number]] ​for the replication ​business rule.  In certain situationsyou 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.+
-{{:business_rule_order.png|}}+For more information on this option, see [[::​use_audit_delete_listener|Use Audit Delete Listener]].
-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:+==== Delete on Class Change ==== 
 +This is a feature was introduced in <wrap info>​[[updateset_releases|Carbon]]</​wrap>​. 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.
-<​code>​ +ServiceNow will handle class changes automatically,​ so you do not need to enable this for a ServiceNow to ServiceNow integration.
-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+For more information on this option, see [[snc_delete_on_class_change|Delete on Class Change]].
-**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<wrap info>v3.1.8</wrap>+==== Parent / Child Hierarchy ==== 
 +When selecting a table to Dynamically Share it is important ​to keep in mind the parent/​child hierarchy of the record ​ServiceNow covers that [[http://​​title=Tables_and_Classes|here under their Tables and Classes]] documentation. ​
-{{:​update_or_insert.png|}} +=== Child Table Only (Default) === 
-<WRAP round info> +By default we share out the records as the child classThis means that if you are sharing [cmdb_ci] you will receive Windows ServersLinux Servers, Network Gear, etcYou will receive the record ​as it is defined (by the sys_class_name) in the single table it is defined by (Windows Server, Linux ServerNetwork Gear).  ​
-In generalit 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 consumerthe 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 === 
-</​WRAP>​+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].
-**Share Base Table Only** : By default, Dynamic Share will share the child table records ​of the configured tableBy 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.+=== Include All Child Tables === 
 +If you choose “Include All Child Tables ​Only” this will share out all the layers ​of the dataFor 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 [[:​replicator_servicenow_hierarchy|ServiceNow Hierarchy here]].
 +===== Additional Settings ===== 
 +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.
-**Create** ​A checkbox to indicate if this table will share records on creation.+{{::​dynamicshare_additional_settings.png|}}
-{{:create.png|}}+==== Sharing Related Records ==== 
 +Through the Dynamic Share you can also share out any records related to the initial table recordsThis includes any: 
 +  * Attachments 
 +  * Embedded Images / Videos 
 +  * Journal Fields 
 +  * Audit Log 
 +  * Referenced Fields
-**Delete** : A checkbox to indicate if this table will share records ​on deletion.+Of the main record. By default ​this will share the related ​records ​per table __as they are created__
-**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 deletesSetting this option ​will create an “on insert” business rule on the sys_audit_delete table and enqueue deleted records noticed ​through this approach.+=== Attachments === 
 +The attachment options will share out the sys_attachment ​(metadataas well as the sys_attachment_doc (data) records for the attachmentsSo 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 
-{{:delete_audit_lister.png|}}+{{page> ​::​snc_attachment_outbound_queue&​noheader&​nofooter}}
-**Update** : A checkbox to indicate if this table will share records ​on update.+=== Embedded Images / Videos === 
 +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
-{{:update.png|}}+You can read more about sharing [[:include_embedded_images_videos|embedded images / videos here]]. ​
-**Delete On Class Change** : This is a feature introduced ​in <wrap info>[[updateset_releases|vCarbon]]</​wrap>​. You can read more about it [[snc_delete_on_class_change|here]]. In summary it is to delete ​the "​orphaned" ​record ​left over in your external database when you change ​the class of a record. ​+=== Journal Fields and Audit === 
 +Comments ​in ServiceNow are stored within the table Journal Field [sys_journal_fieldand are related ​to the base record. In other words, they are not stored directly on the base record. ​ 
-{{::delete_on_class_change.png|}}+You can read more about the handling for these two from the following 
 +  * [[:include_journal_fields_audit_log|Journal and Audit Records here]] 
 +  * [[::​snc_comment_handling| ServiceNow Comment Handling]] 
 +  * [[dynamic_share_limits|Limiting Journal and Audit Data]]
 +==== Include Referenced Field Records ==== 
 +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.
-=====Additional Settings=====+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.
-{{:additional_settings.png|}}+You can read more about this feature [[::​include_referenced_field_records|Include Referenced Field Records here]].
 +==== Table Maps ====
 +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 can be easily sent to other ServiceNow instances or platforms (Jira, Salesforce, Remedy, etc).
-{{page>​include_journal_fields_audit_log&​noheader}}+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.
-====Include Attachments====  +You can read more about this feature[[::​snc_table_maps| Table Maps here]].
-A checkbox to indicate if attachments related to this table should also be shared. ​  +
-<WRAP round info> +
-Note that on the instance where you set up subscribeyou will need to set up the sys_attachment and sys_attachment_doc tables as active subscribers for this option to work. +
-<WRAP round tip> +=== PSP Share Table Map === 
-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. +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.
-<WRAP round tip> +You can read more about this feature, ​[[share_table_map|Share Table Maps here]].
-Attachments do not honor the [[ignoring_share_in_before_share_script|ignore flag]] in the before share script and thus any attachments will be shared out if it meets the dynamic share'​s conditions. +
-{{:​include_attachment.png|}}+====Target queue==== 
 +The specific queue that data from this table will be sent to for Subcribing/​consumption by another instanceThis queue will need to be defined in [[Replicator_SNC_Shared_Queues|Shared Queues]]. ​
-{{page> snc_attachment_outbound_queue&​noheader}}+A target queue must be specified for a Dynamic Share to be created.
-**Include embedded images/​videos** : A checkbox ​to indicate if embedded images/​videos related to this table should also be shared.  ​ +====View Name==== 
-{{page> include_embedded_images_videos}}+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. ​
-====Include Referenced Field Records====  +You can read more about this feature, [[replicator_ui_view| Field Restriction Using UI Views here]].
-A checkbox to indicate if referenced field records related to this table should also be shared+
-{{:​include_reference_field_records.png|}}+====Conditional Share==== 
 +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 [[include_referenced_field_records|Include Referenced Field Records ​here]].+You can read more about this feature[[conditional_shares|Conditional Shares ​here]].
- +----
-**Table Map** : This feature is used to map and/or transform the outbound SericeNow field data for the record being replicated. +
- +
-{{:​table_map.png|}} +
- +
-**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 [[Replicator_SNC_Shared_Queues|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. +
- +
 =====Filter and Enrichment===== =====Filter and Enrichment=====
- +---- 
-{{:filter_and_enrichment.png|}}+The filter and enrichment tab allows you to control what type of operations you are skipping as well as giving you the option to use scripts to enrich the message you are sending out. 
 ==== Condition ==== ==== Condition ====
-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. +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.
- +
 ==== Before share script ====  ==== Before share script ==== 
-This is a script that gets executed right before the shared ​object ​is being queued up.  The object is in [[http://​​title=GlideRecord|GlideRecord]] type and can be accessed via the globally available variable called //​current//​. ​For an example of how to use this script, go [[before_share_script|here]]. <wrap info>​v3.1.8</​wrap>​+This is a script that gets executed right before the shared ​message ​is being queued up.  The object is in [[http://​​title=GlideRecord|GlideRecord]] type and can be accessed via the globally available variable called //​current//​. ​
-{{:​before_script_share.png|}}+For an example of how to use this script, go [[before_share_script|here]]. ​
 ==== After share script ==== ==== After share script ====
-{{page>​snc_dynamic_after_share_script&​noheader}}+This is a script that gets executed right after the shared message is being queued up.  The object is in [[http://​​title=GlideRecord|GlideRecord]] type and can be accessed via the globally available variable called //​current//​. ​
-=== Ignoring records in before share script ​=== +For an example of how to use this script, go [[snc_dynamic_after_share_script|here]]. ​
-==== Share only selected fields ​==== +==== Sharing column updates to ignore / share on ==== 
-{{page>​share_only_selected_fields&​noheader}}+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.
-==== Share only updated fields ==== +===Select Column Updates To Ignore On=== 
-{{page>​share_only_updated_fields&​noheader}}+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.
-=====Scheduled Sync Up=====  +===Select Column Updates to Share On=== 
-<wrap info>v3.2.7</​wrap>​+This is really the reverse of the previous option where you are specifying the updates to certain columns to trigger onFor example if you only want to update your CI information when the "​Install Status"​ or "IP Address"​ changes than you can configure that here.
-{{:​screen_shot_2016-01-19_at_11.26.10_am.png|}}+You will specify columns to ignore onIf you put in columns A, B, C and a message will only be sent if __anyone of those__ columns are updated.
-**Activate Sync** ​Check this box to start the sync.+=== Implementation === 
 +How to implement these two options are detailed [[::ignoring_share_in_before_share_script|here]],​ along with how to manually configure ​the same within a Before Share Script instead.
-{{:​active_sync.png|}}+==== Share only selected fields ==== 
 +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.
-**Started** : The time syncs started+You can read more about this feature,​[[share_only_selected_fields| Share only Selected Fields here]].
-**Stopped** : The time syncing stopped+==== Share only updated fields ==== 
 +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.
-{{:​started_and_stopped.png|}}+You can read more about this feature, [[share_only_updated_fields|Share Only Updated Fields here]].
-**Interval** :  The intervals ​for syncing, choice of 5, 30, or 60 minutes+---- 
 +=====Scheduled Sync Up=====  
 +Scheduled Sync Up can be used to shared data out as a backup (for redundancy) ​or as an alternative option to the real time aspect of the Business Rules (for inserts/ updates). ​  
-{{:interval.png|}}+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.
-**Last Time Sync** : The last time syncing occurred, this also marks when the data should start for each sync+This can be helpful to provide redundancy in your Sharing or to account ​for records which are being updated without triggering the Business Rules.  ​
- ​{{:​last_time_sync.png|}}+You can read more about this feature, [[scheduled_sync_upScheduled Sync Up here]].
-**Number of Records Synced Last Interval** : The number of records from the Last sync time that needed to be sync +---- 
- +===== Advanced ===== 
- {{:​number_of_records.png|}} +---- 
- +<​WRAP ​left round info 30%
-<WRAP round info> +This tab is only available ​if the "​Advanced"​ box is checked
-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 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'​.+
 </​WRAP>​ </​WRAP>​
 +==== Enable Debug Logging ====
-//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.//+==== Enable Data Obfuscation ==== 
 +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| Data Obfuscation here]].
 +===== Notes =====
 +====== Actions & Related Lists ======
 +===== UI Actions =====
 +==== Run a bulk share ====
-<WRAP round info> +===== Related Lists ===== 
-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. +==== Outbound Messages ==== 
 +====== Troubleshooting ======
 +===== Unsupported Tables =====
 +Users are validated from choosing tables that do not support dynamic share business rule. 
 +Here is the list of tables that are not supported:
 +  - Sys Audit[sys_audit]
 +  - User Role [sys_user_has_role]
-{{page>replicator_snc_shared_queues}} +===== Domain Handling ===== 
-<WRAP round info> +==== Domain separation ==== 
-In version [[updateset_releases|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**. +{{page>::​domain_separation&​noheader&​nofooter}}
-{{page>​replicator_ui_view}} +==== Display Domain ​and Scope ==== 
- +{{page>::​display_domain_and_scope&​noheader&​nofooter}}
-{{page>​snc_message_set_activity}} +
- +
- +
- +
-===== Use Audit Delete Listener ===== +
-{{page>​use_audit_delete_listener&​noheader}} +
- +
-===== Limit Journal Entries ​and Audit Records ===== +
-{{page>dynamic_share_limits&​noheader}} +
- +
-===== Outbound Messages ===== +
-{{page>​delete_this_share_messages&​noheader}} +
- +
-===== Run a bulk share ===== +
-{{page>​snc_dynamic_run_a_bulk_share&​noheader}} +
- +
-===== Notes ===== +
-{{page>​snc_share_notes_field&​noheader}} +
- +
-===== Advanced ===== +
-<WRAP left round tip 100%> +
-This tab is only available if the "​Advanced"​ box is checked +
-</​WRAP>​ +
- +
-==== Enable Debug Logging ==== +
-{{page>​enable_share_debug_logging&​noheader&​nofooter}} +
- +
-====Domain ​separation ===== +====Create a Domain-specific Dynamic Share====
-===== Display Domain and Scope ===== +<wrap round info>​[[europium_release|Europium]]</​wrap>
 +As of the [[europium_release|Europium release]], you can create a dynamic share that will be run within a specific domain. To create a domain-specific dynamic share:
-===== PSP Share Table Map ===== +  - Log into your [[https://​​bundle/​london-platform-administration/​page/​administer/​company-and-domain-separation/​reference/​domain-sep-landing-page.html|domain-separated ServiceNow instance]] and navigate to **Perspectium** ​**Replicator** > **Dynamic Share** or simply type and then select **Dynamic Share** in the left side navigation window. 
-{{page>share_table_map&​noheader}}+  - At the top of the form next to **Replicator Configurations**,​ click **New** to create a new dynamic share. Alternatively,​ to edit an existing dynamic share, click into the dynamic share you want to change from the list. 
 +  - Check the **Advanced** box on the right side of the form. Then, click the **Advanced** tab. 
 +  - Next to **Business Rule Domain**, click the **magnifying glass** icon and then click the domain that you want to run the dynamic share in.
replicator_snc_share.1533683972.txt.gz · Last modified: 2018/08/07 16:19 by seung.suh