IDR works on the idea of Producer -> Consumer instances.
Producer is the source instance of data, consumer being the instances that utilize it.
Data is synced down automatically.
IDR plugin (com.glide.idr) needs to be activated for this. This will be activated by SN as part of a subscription model. Roles: admin, idr_admin.
Steps to configure IDR:
Create producer config (Replication set) on producer instance
'Producer entries' will decide which tables and fields to be synced.
Table-wise information needs to be filled in, and fields that need to be carried over will all be presented in a slushbucket to select.
Attachments can also be included.
Create consumer config (Replication set) on consumer instance, and tag the exact name of the producer config and instance name from step 1.
Once the consumer config is created, an approval needs to be done from the producer instance to activate data transfer
Once approval is done on the producer instance, 'Activate' button will be visible to select on the consumer instance.
Under inbound entries related list for consumer replication set, use the 'Seed' button to initiate first-time transfer. Auto-sync will happen post this, when newer table records are created
'Seeding Requests' will help to track the status
In order to do this bidirectional, repeat the above process switching the consumer and producer replication sets.
IDR workflows help manipulate data every time it is synced - it is done on replication set individually - for example, for inbound entry 'incident' can have its own IDR workflow.
IDR workflows can be run every time after the data is synced - using business rules:https://docs.servicenow.com/bundle/paris-servicenow-platform/page/administer/instance-data-replication/task/post-replication-actions.html#post-replication-actions
IDR cannot differentiate domain separation as it run on SN datacenter. If domain-based records need to be synced, only option is using record filtering.
Comments