Relation Mapping Between ServiceNow and SAP LeanIX

After configuring how you want to map fact sheets to ServiceNow tables—or vice versa—you can also map relations between those fact sheets or records to the other system.

On the ServiceNow configuration page, under Relation Mapping, find the mapping you need or create a new one. Configure the following:

• Active: Activate or deactivate a relation mapping.
• Fact Sheet Mapping: Choose entities between which you want to configure relation mapping.
• Source System: Select the source system for relations.
• Configuration: Configure details for the relation.

Selecting an SAP LeanIX Relation

First, select the relation that is to be used on the SAP LeanIX side. Depending on the Source you selected in the previous step, this is either the relation in SAP LeanIX that is read from or the relation that is created based on a relation within ServiceNow.

Configuring a ServiceNow Relation

Next, you need to configure the relation to be used on the ServiceNow side. Depending on the Source you selected in the basic tab, this is either the relation in ServiceNow that is read from or the relation that is created based on the relation within SAP LeanIX.

Depending on the relation that you choose, you may need to configure additional information.

📘

Note

In the ServiceNow integration, relations between applications and hardware/software items are configured differently from other relations. For details, see Relations Between Applications and Hardware/Software Items.

CMDB_REL_CI

This mapping type is used to create or pull from relations between two ServiceNow tables that use the cmdb_rel_ci table. A common example is the relation between a Business Capability and a Business Application in ServiceNow.

For this relation mapping, you need to select the type of the relations in the cmdb_rel_ci table that should be read or pushed (in case of reading from ServiceNow, you can also decide to read all of the available types).

Configuring query filters is only possible using the Advanced Configuration, in this dialog you can only view them. Please ask for guidance from Customer Success, as these filters can have subtle effects on the mapping (e.g. performance).

REFERENCE_FIELD

This mapping type is used when pulling or pushing to a Reference or Glide List field in ServiceNow that refers to a table in sync. During the synchronization run, the integration will automatically detect the exact technical type behind the field which is selected in the following dropdown and apply the suitable updates.

MAPPING_TABLE

The MAPPING_TABLE configuration defines the case when a custom table which holds two columns of field type Reference in ServiceNow are used to hold relations between two items in arbitrary tables.

This case is analogous to a mapping table concept as used in databases.

📘

Note

This configuration is only supported when ServiceNow is the source of truth for a relation.

For this relation mapping, please select the table and fields you want to read the relation from.

GRAPH_RULE_CONSTRAINT

For this relation to work, at least one of the involved ServiceNow tables needs to have a Graph Rule Constraint configured (see above). The respective Graph Rule that is configured to constraint the number of records to be mapped will then be used to model this very graph as a relation in SAP LeanIX.

📘

Note

This configuration is only supported when ServiceNow is the source of truth for a relation.

This relation type does not need any additional configuration.

Relation Sync Behavior

📘

Note

Relation synchronization is always set in strict mode. Unlike fact sheet descriptors, relation descriptors don't have a strict flag to turn off. This design allows the integration to delete relations if they're no longer present in the source system, ensuring consistent parity.

Before syncing relations, ensure fact sheet descriptors are active. For example, when syncing relations between applications and business capabilities, ensure both the application and business capability are set to Active in the section above.

Here we define a few cases and the intended action the Integration will take for each of them about the relations.

The following above cases can be illustrated in the following example of an Application to IT Component relation. Consider an Application Fact Sheet called "AC Management LeanIX" which is linked to two IT Components -

For the Fact Sheet above, the two connected IT Components are all coming from ServiceNow and thus are also linked to ServiceNow. If the Integration is not able to read the relation between these two IT Components and the Application in the next sync, they will be deleted (case 1).

Subsequently, We then consider adding another manual relation to this Application, an IT Component Fact Sheet which is not linked to ServiceNow, but rather created manually in SAP LeanIX either by the user or other Integrations.

In the case above, the Integration's logic knows not to touch the third relation as it could be managed by the user and/or another Integration. This is also known because the third Fact Sheet, illustrated by its name, is not linked to ServiceNow. In the case of a sync run, if the Integration sees no relations in the source system, it can, at best, delete the first two relations but not the third one. (Case 2).