Preserving table hierarchy in Instance Data Replication
Summarize
Summary of Preserving table hierarchy in Instance Data Replication
This content helps ServiceNow customers understand how to manage parent-child table hierarchies when configuring Instance Data Replication (IDR). Before creating a replication set, you must decide if the table is part of a hierarchy and choose a strategy to either preserve or ignore that hierarchy. The choice affects which columns and records are replicated to the consumer instance, ensuring data integrity and relevance based on your replication goals.
Show less
Key Strategies for Replication
- Strategy 1: Preserve the entire hierarchy and replicate child columns
Create outbound entries for each child table and apply asysclassnamefilter per child table. This approach replicates all columns across parent and child tables, inserting records into the corresponding child tables on the consumer instance. This is ideal when full data fidelity across all related tables is required. - Strategy 2: Preserve the hierarchy but replicate only parent table columns
Replicate the parent table while including theClass Name [sysclassname]field in the included fields list. This keeps the distinction between parent and child records on the consumer, but only columns from the parent table are replicated. Child tables exist on the consumer, but their unique columns are not populated. - Strategy 3: Ignore the hierarchy and replicate only parent table data
Replicate only the parent table and exclude theClass Name [sysclassname]field. This removes the parent-child distinction on the consumer instance, replicating all records as parent table entries with no child-specific data. This is useful for simplified reporting or audit scenarios where child details are unnecessary.
Practical Implications
Choosing the right strategy enables you to tailor data replication based on your operational needs:
- Full hierarchy preservation supports comprehensive data synchronization including child-specific columns.
- Partial hierarchy preservation maintains structural relationships without replicating all child columns, reducing data volume.
- Ignoring hierarchy simplifies data replication by treating all records as parent records, useful for aggregated views.
Understanding these strategies allows you to configure replication sets effectively to meet your use cases while maintaining data consistency on the consumer instance.
Decide if you want to replicate a parent-child table hierarchy and what strategy to use for replicating the data in Instance Data Replication (IDR).
Before you create a replication set, determine if the table that you want to replicate is part of a parent-child table hierarchy. If it is, decide if you want to preserve the hierarchy and whether to replicate the data from the parent perspective (retaining only columns belonging to the parent table) or from the child perspective (retaining all columns that belong to the child tables). Review the following available strategies.
- Strategy 1: Preserve the entire hierarchy and replicate child columns
- You can preserve the entire hierarchy, including all of the child table columns, by creating
an outbound entry for each child table, and specifying a sys_class_name filter for each child
table.
For example, to replicate the Task table and ensure that all of the columns from all of the child tables are included, specify the following:
Table 1. Outbound entries Table Filter Task sys_class_name=task Incident sys_class_name=incident Problem sys_class_name=problem Change Request sys_class_name=change And so forth, for all of the child tables, including filters with each table for the sys_class_name.
With this strategy, records are inserted into each child table on the consumer, including data from the columns that belong to each child table on the producer.
- Strategy 2: Preserve the hierarchy, but don't replicate child columns
- To preserve the hierarchy but only replicate columns from the parent table, replicate the
parent table and include the Class Name [sys_class_name] field in the Included
Fields list. Including the Class Name field maintains the distinction between
parent and child records on the consumer instance.For example, if you want to replicate the Task table and its children (Incident, Problem, Change Request), but only replicate the columns that belong to the Task table, specify the following:
Table 2. Outbound entry Table Included Fields Task Class Name In this strategy, the sys_class_name column on the consumer Task table receives entries for the parent table (task) and child tables (incident, problem, and change), and records are inserted into the respective child tables on the consumer. However, without the sys_class_name filter, the columns that are unique to each child table are not replicated.
- Strategy 3: Ignore the hierarchy, and only replicate parent table data
- To ignore the hierarchy and only replicate parent records, replicate the parent table and
exclude the Class Name [sys_class_name] field from the Included Fields
list. Excluding the Class Name field removes the distinction between parent and child records
on the consumer instance. All replicated records on the consumer will be parent table
records.For example, if you want to replicate records from the Task table and simply consider all records as tasks for reporting or auditing purposes, specify the following:
Table 3. Outbound entry Table Included Fields Task Any fields except for Class Name In this strategy, when you replicate the Task table, all replicated records have a value of task in the sys_class_name column, and no columns belonging to the child tables are replicated.