ServiceNow Integration

Fundamentals of the LeanIX integration with ServiceNow (CMDB)

📘

Knowledge

Before enabling the LeanIX-ServiceNow integration, please make sure you or a colleague/consultant working with you has fundamental knowledge about ServiceNow, including:

  • Adding Users, Groups, and Roles
  • Managing data with tables in the the configuration management database (CMDB)
  • Protecting ServiceNow data

It is recommended that your knowledge cover the key topics of the ServiceNow Certification

Introduction / Synchronization Mechanism

Generally speaking, ServiceNow (SN) and LeanIX have a lot in common. Both maintain tables and relations, and both offer a browser-based application for viewing and updating those tables.

For synchronization purposes, every mapping between tables in both systems defines the following:

1

Name of table in LeanIX

2

Name of table in SN

3

Whether SN or LeanIX holds the source ('master') record

4

Whether one should use the 'strict' mode, i.e. whether unsynchronized slave objects should be deleted right away

5

Whether there are any synchronization constraints, e.g. only synchronize applications with a specific lifecycle status or only synchronize software product models which are actually installed on a server belonging to a managed business application

For every Field to be held in Sync:

Type of mapping (see types of mapping further below)

Name of field in LeanIX (if applicable)

Name of field in SN (if applicable)

Whether the attribute is to be synced from master to slave object or vice versa.

How values are being mapped (as is or explicit mapping of one value to another)

❗️

Do Not Synchronise Huge Tables with LeanIX

LeanIX is intended to be 'lean' - it is not advisable to synchronise tables with hundreds of thousands (or even millions) of entries with LeanIX. All the key advantages of LeanIX will be nullified if too many objects clutter the reports and inventory.

Based on that, the configuration can be saved if it is in a valid json format (don't worry, the editor will tell you if the syntax is wrong).

The synchronization mechanism works independently of state information, i.e., the integration code only gets the information that a particular object (uniquely identified by table name and sys_id or type of Fact Sheet and UUID respectively) has changed (created, updated, deleted) and then figures out by itself what to do. The sync mechanism retrieves (if not already done) slave and master object and checks whether a change is necessary. Afterwards, relations are checked in LeanIX and corrected if necessary.

LeanIX will not create a copy of any tables that are not being synchronised with LeanIX within the configuration. Objects that are not in synchronisation even though the table itself is synchronised (due to some sync constraint) won't be transferred to LeanIX either.

Communication to ServiceNow

The communication between the LeanIX integration running on LeanIX servers and the ServiceNow system depends on the configuration specified in ServiceNow URL. In case the ServiceNow URL is configured with an https schema, the communication uses TLS encryption.

🚧

HTTPS

The TLS version and cipher suites used for communication between LeanIX integration and ServiceNow depends on the negotiation to the ServiceNow HTTPS server. In general, TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is used for any HTTPS connection to ServiceNow.

Settings from LeanIX Side

Once your LeanIX point of contact has confirmed the integration is active in your LeanIX workspace, you can follow the steps below.

Below are the Fact Sheet types that you can link to ServiceNow out-of-the-box:

1

"ITComponent"

2

"TechnicalStack"

3

"Application"

4

"BusinessCapability"

If you would like to include additional Fact Sheet types, please inform your LeanIX point of contact, as they will need to adapt the data model of the workspace as shown below.

{
 "serviceNowExternalId": {
  "quickSearch": true,
  "fullTextSearch": true,
  "urlTemplate": null,
  "uniqueFactSheet": false,
  "autoIncrement": false,
  "readOnly": true,
  "forFactSheets": [
   "ITComponent",
   "TechnicalStack",
   "Application",
   "BusinessCapability"
  ]
 }
}

Create a new Technical User in LeanIX under whose credentials the synchronization shall be run and create an API-token with the new user. The token will be required in the SN configuration later on.

🚧

API-Token

Do not forget to copy the token content to a secure location, as you will need it later.
LeanIX suggests using an expiration date within a reasonable time frame, since it is good practice to change these credentials regularly.

Default ServiceNow Configuration

The default mapping, which is created on a new configuration, works in this way:

1

Business Applications to Applications

2

Hardware Product Models to IT Components

3

Software Product Models to IT Components

4

Model Categories to Technical Stacks

The default configuration is detailed below:

Data Flow for Default Scenario

All involved ServiceNow tables and used connections among each table and the LeanIX Fact Sheet types (and their relations) are shown below. This image helps illustrate the relations between ServiceNow tables and data flow conditions when constrains are used within the configuration.

On the left (in blue) are the LeanIX Fact Sheet types, and on the right are the tables in SN. Double-lined arrows show synchronization directions, while the other arrows show relations. On the SN side, these can be connections via CI Relation or foreign key values.On the left (in blue) are the LeanIX Fact Sheet types, and on the right are the tables in SN. Double-lined arrows show synchronization directions, while the other arrows show relations. On the SN side, these can be connections via CI Relation or foreign key values.

On the left (in blue) are the LeanIX Fact Sheet types, and on the right are the tables in SN. Double-lined arrows show synchronization directions, while the other arrows show relations. On the SN side, these can be connections via CI Relation or foreign key values.

The default mapping represents a complete example of an integration between LeanIX and SN. The tables and how they are connected is detailed below.

Workflow for Default Scenario

Workflow

More Details

Applications are created and maintained in LeanIX.

The integration application synchronizes these applications to Business Application table (cmdb_ci_business_app) in SN.

Business Applications are linked indirectly to Hardware objects via the Application Services and the CI Relation tables (cmdb_rel_ci). These hardware objects are further then directly associated with Hardware Product Models (cmdb_hardware_product_model) and via Software Instance (cmdb_software_instance) and Software (cmdb_ci_spkg) to Software Product Models (cmdb_software_product_model).

If you use the Software Asset Management (SAM or SAM-Pro) module of SN, then other tables are used, but the methodology remains the same.

The LeanIX integration will synchronize only the Hardware and Software Product Models (cmdb_hardware_product_model + cmdb_software_product_model) that have a link to a synchronized Business Application (see step 2) or a Hardware (cmdb_ci_hardware) depending on selected constraints.

Additionally, Model Categories (cmdb_model_category) are synchronized from SN to LeanIX.

If a relation exists in SN between a Business Application (cmdb_ci_business_app) and a Hardware or Software Product Model (cmdb_hardware_product_model + cmdb_software_product_model) as explained in step 3, then a relation between the corresponding objects in LeanIX will be created.

If a relation exists in SN between a Model Category (cmdb_model_category) and a Hardware or Software Product Model (cmdb_hardware_product_model + cmdb_software_product_model), then a relation between the corresponding objects in LeanIX will be created.