IRE Reconciliation Rules Explanation
Reconciliation rules, much like identification rules, are defined on any class within the hierarchy. For instance, a parent class such as "Server" may have reconciliation rules, which are then inherited by child classes like "Linux Server" or "Windows Server." This hierarchical model ensures consistency across related configuration items (CIs).
In the context of the Identification and Reconciliation Engine (IRE), reconciliation rules play a pivotal role during CI update scenarios. These rules determine the authoritative source responsible for updating specific attributes on a CI. By defining the source of truth for these updates, reconciliation rules help maintain data integrity and avoid conflicts when multiple sources attempt to modify the same attributes.
Discovery Source Needs Reconciliation Rule to Update a CI
This means that if ServiceNow is designated as the sole authoritative source for updating attribute values on a Linux Server CI, no other source, including ServiceWatch, is permitted to alter those values. While ServiceWatch may create the CI and populate it with initial attribute values, any subsequent modifications to these values must adhere strictly to the reconciliation rules. In this setup, ServiceNow maintains ultimate control, ensuring consistency and preventing unauthorized updates from conflicting sources.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux1",
"ram": "1024"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceWatch', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceWatch inserts a Linux Server CI with RAM value.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux1",
"ram": "2048"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceWatch', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceWatch is not able to modify the RAM value.
"maskedAttributes": [
"ram"
],
RAM is masked information is provided in IRE output.
In scenarios where priority levels are assigned to reconciliation rules, ServiceNow, designated as the authoritative source, may hold a priority of 100, while ServiceWatch is assigned a lower priority, such as 200. These priority levels further clarify the hierarchy of control, ensuring that updates to specific attributes follow the defined order. For instance, if ServiceNow has priority 100 for updating the RAM value of a Linux Server CI, any changes attempted by ServiceWatch, with its priority of 200, would be overridden in favor of the higher-priority source.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux1",
"ram": "2048"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceWatch', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceWatch is now able to update the RAM value.
The Precedence Battle - Higher Priority Source Protects its Data
One of the most fundamental jobs of IRE Reconciliation is to ensure that more trustworthy (higher priority) data sources maintain control over the attributes they are authoritative for, even when other, less trustworthy (lower priority) sources try to update the same CI.
Linux Server class has reconciliation rule for ServiceNow and ServiceWatch.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux1",
"ram": "1024"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceNow', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceNow creates Linux Server CI with RAM value.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux1",
"ram": "2048"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceWatch', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceWatch is not allowed to update the RAM value.
IRE output shows masked attributes because of reconciliation rule.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux1",
"ram": ""
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceNow', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceNow is not allowed to update the RAM value to empty.
IRE output shows masked attributes because of reconciliation rule.
Update Reconciliation Rule by adding RAM to Update with null list.
ServiceNow is now allowed to update the RAM value to empty.
Purpose of glide.identification_engine.enable_reconciliation_filter_before_update
The primary purpose of this property is to allow administrators to define conditional filters that are evaluated against the target CI just before an incoming attribute update (which has already passed standard data source precedence checks) is applied. If the CI meets the filter's criteria, the update can be selectively prevented or allowed, overriding the normal outcome of precedence rules for that specific update instance.
Define reconciliation rules for SN and SW with filter condition as operational_status is not Retired.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux Server 1",
"ram": "2048",
"operational_status": "6"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceNow', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceNow creates CI with operational_status as retired.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux Server 1",
"ram": "1024",
"operational_status": "1"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceWatch', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceWatch is not allowed to update the attributes like RAM, operational_status
IRE output shows the masked attributes.
ServiceWatch is allowed to update the attributes like RAM, operational_status after adding and enabling the below property:
glide.identification_engine.enable_reconciliation_filter_before_update
IRE uses class in payload for applying Reconciliation Rule
The ServiceNow Identification and Reconciliation Engine (IRE) uses the
sys_class_name attribute in the input payload to determine which Configuration Item (CI) class it's dealing with. This class information is crucial for selecting the appropriate reconciliation rules.
Linux Server has one rule for ServiceNow discovery source.
var payload =
{
"items": [
{
"className": "cmdb_ci_linux_server",
"values": {
"name": "Linux Server 1",
"ram": "1024"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceNow', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceNow create Linux Server CI with RAM value.
var payload =
{
"items": [
{
"className": "cmdb_ci_server",
"values": {
"name": "Linux Server 1",
"ram": "2048"
}
}
]
}
;
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCIEnhanced('ServiceWatch', input, {});
gs.print(JSON.stringify(JSON.parse(output),null,'\t'));
ServiceWatch updates existing CI by downgrading the class from cmdb_ci_linux_server to cmdb_ci_server and updating the RAM value. IRE uses the cmdb_ci_server class from input payload for any reconciliation rules, but in this case, no reconciliation rule is defined for the server class.
Best Practices for IRE Reconciliation Rules
- Start with Out-of-the-Box (OOTB) Rules: ServiceNow provides a robust set of OOTB rules. Understand them before customizing.
- Prioritize Authoritative Sources: For each CI class and key attributes, identify which data source is the most reliable and give it higher precedence in reconciliation.
- Be Specific: Use specific attributes for identification where possible (e.g.,
serial_number
is often better than just
name
). - Test Thoroughly: Whenever you create or modify reconciliation rules, test them with various payload scenarios (including partial data, conflicting data, etc.) in a sub-production environment.
- Monitor IRE Logs: Keep an eye on IRE processing logs (e.g., via
IRE Processing Results
or system logs) to understand how CIs are being identified and updated. - Regularly Review and Audit: Periodically review your reconciliation rules and CMDB data quality to ensure they are still meeting your organization's needs.
Conclusion
IRE reconciliation rules are a cornerstone of a healthy CMDB. By understanding how they work, especially in scenarios like partial data ingestion, you can better manage your CMDB, ensure data accuracy, and provide a reliable foundation for your IT Service Management processes.
We encourage you to share your own experiences and tricky reconciliation scenarios in the comments below!
What do you think of this draft? We can refine it further, add more scenarios if you have them, or focus on specific aspects you'd like to highlight.
