Advanced Configuration

The Advanced Configuration is the JSON representation of everything set in the Basic Tab. Any configurations or additional changes made in the Basic section will be represented within the advanced tab.

There are a few items in the Integration that can only be configured in the advanced tab. Such as OAuth 2.0 setup, advanced relationship mapping, dot walking, and others. In case you do not see the Advanced tab in your configuration, you may reach out to support at SAP LeanIX Support to activate this feature. If you're an SAP customer, submit a request from the SAP for Me portal.

👍

Tip - Use the JSON in the advanced section to backup and restore configurations

The JSON can be copied and saved locally as a way of version control, backup, and restore tasks. Simply select all in the advanced section and paste it in your IDE of choice and save it as a .JSON file.

👍

Tip - Restore back to default configuration

If you clear out the configuration in the json editor, just put in an empty json document '{}', then the default supported configuration mapping is restored you can use as a good starting point.

Relation Mapping Behaviour

There are some settings on the behaviour of the Relation Mapping, that can only be applied using the Advanced Configuration.

CMDB_REL_CI

REFERENCE_FIELD

There are no additional flags for the REFERENCE_FIELD mapping type.

MAPPING_TABLE

👍

Tip - Advanced Graph Constraint

There is an additional option to define a Graph Rule sync constraint in the Advanced Section: MAPPING_TABLE_CONNECTION. This limits the objects to the one's available in the custom relationship table while pulling into SAP LeanIX.

Example:

"syncConstraint": {
	"graphRules": [
		"APPLICATION_SAM_CONNECTION",
		"MODEL_CATEGORY"
	]
}

Other Settings

The following section details out specific use-cases while configuring the Integration.

Dot Walking

It is possible to dot walk certain field mappings within the advanced configuration of the Integration. This is especially useful if it is required to pull information of some record from its corresponding referenced field.

In the following example, we know that Schedule & Track is linked to the Business Unit of Australia. To bring this information into SAP LeanIX as a relationship, we will have to -

• Map the table which the reference field is from to a SAP LeanIX Fact Sheet type. In this case it would be linking the SAP LeanIX User Group Fact Sheet Type to the business_unit table.
• Create a relationship descriptor of type REFERENCE_FIELD between the Applications and the User Group Fact Sheet Type using the business_unit reference field as seen below in the screenshot.

While the above method works, it is often times too much work just to bring in data from the field. Especially so if it is not required to have as a Relationship. In such a case, dot-walking functionality can be used to bring the name of the Business Unit into SAP LeanIX as a string field.

👍

Example - Bring data of reference fields into text fields in leanix

Use Dot Walking Functionality to get a Business Unit's name which is assigned to a Business Application.

• Step 1
  Review the field in ServiceNow by clicking on the (i) icon

• Step 2
  We notice that the name field is the one that stores the actual value of "Australia" in a string field.

• Step 3
  Logically speaking another way to put this would be business_unit.name. Wherein, the first part before the "." is the name of the field within the main table. Subsequently, the second part after the "." is the name of the field within the referenced table where the value is stored. This is known as dot-walking.

• Step 4
  Within SAP LeanIX, this can be modeled within the advanced tab as follows -

"alias": {
  "fieldType": "FOREIGN_FIELD",
  "foreignFieldName": "business_unit.name",
  "useNormalDirection": true
},

In the code example above, we are pulling the name of the attached business unit to the Application into the Alias field of SAP LeanIX which for the purposes below we have renamed to "Business Unit".

Deletion Ratio

To avoid accidentally the deletion of of Fact Sheets or ServiceNow records because of an erroneous configuration, a deletion ratio threshold can be configured.

The maximumDeletionRatio specifies the deletion ratio in percent. The default value is 50. If the total candidate records for deletion are higher than 50%, then the Integration will not delete those records and output an error in the synclog to review.

If a maximumDeletionRatio is specified and the number of items to delete / synchronized items is less than maximumDeletionRatio, then the synchronization is allowed to delete.

❗️

Tip - Set the Deletion Ratio to lower or higher depending on the preferred result.

Be careful with the use of strict mode and maximumDeletionratio as it can lead to unintended permanent deletion of data.

If the expectation is to delete majority/all of records on either side, then the deletionratio can be set to higher or 100%.

However, if the expectation is to carefully review each and every candidate for deletion within the synclog, the ratio can be set to 1. Further still, for the latter use-case we recommend to not have Strict Mode turned on to begin with as the synsclog will still show records that are not part of the source system, which inherently are deletion candidates.

Disable Partial Sync

🚧

Property skipPartialSyncCondition is No Longer Supported

Please use the Partial Sync Mode Property to decide how the Partial Sync should be executed

Graph Constraint Hardware Filter

While utilizing the graph constraints APPLICATION_SAM_CONNECTION or APPLICATION_HARDWARE_CONNECTION additional parameters can be applied optionally to only retrieve Software Product Models that are linked to Operational Hardware CIs.

The hardwareFilter key within the advanced configuration tab can contain a sysparm_query for filtering the hardware table like the sysparm_query used in ServiceNow REST API.

❗️

Supported Params

Queries only containing AND and OR operators (^ and ^OR in ServiceNow query notation are supported.

A valid example of filtering for the documentation would be:

"hardwareFilter": "operational_status=1^ORinstall_status=1"

In this example, the Hardware Filter is applied to only bring over Software Models which are attached to Hardware CIs that are Operational.

Read Relationship Table Iteratively

In some cases, it can be useful to iteratively load and process relationships during the synchronization. Thus, the readRelCiIterative condition as seen above in Line 188 of the screenshot can be set to true.

In case this is not specified or is set to null, the integrations reads the whole table into the memory to detect relations.

Disable validation for specific foreign fields

Due to issues integrating with ServiceNow, some field metadata may not be read correctly, which can lead to failed validations when saving otherwise valid configurations.
In this case, validation can be disabled specifically for these ServiceNow-fields like so:

{
  "factSheetSyncDescriptors": [
    {
      ...
      "fieldMapping": {
        "mapping": {
          "description": {
            "fieldType": "FOREIGN_FIELD",
            "foreignFieldName": "serviceNow_field_one",
            "useNormalDirection": true
          }
        }
      }
    },
    ...
  ],
  ...
  "validation": {
    "ignoredMissingFields": ["serviceNow_field_one"]
  }
}

List all values of foreignFieldName in ignoredMissingFields that you want to disable validation for.
The integration will still attempt to load the necessary metadata as usual, but will continue if the metadata cannot be found.