About LMDX

This article describes the concepts behind the LogicMonitor Data Exchange (LMDX) application which integrates LM Dexda with your ServiceNow instances. 

Using LMDX you can get notified about issues in ServiceNow, and through links access the information in LM Dexda for investigation. You can look at insight details, see associated alerts and type of issue, and understand why they were correlated. For information on how to investigate issues in LM Dexda, see Exploring Data.

LMDX is currently certified to work on all generally available versions of ServiceNow, and also natively works in domain separated instances.

The core application includes the following fully working configuration records:

• Incident (LMDXDefaultInc)—Manages synchronization with the incident table in ServiceNow.
• CMDB (LMDXDefaultCmdb)—Manages synchronization with the cmdb_ci table in ServiceNow (outbound only, for more information see CMDB).

All related configuration artifacts are bundled with the application. All configuration records and related artifacts (where possible) are inactive by default and must be turned on in order to be used. For more information, see Installing LMDX.

You can use these configurations as-is as they utilize standard default fields that lets you install and quickly get up and running with LMDX. If needed, you can also modify the default configurations.

CMDB

LMDX can process updates to ServiceNow CMDB (Configuration Management Database) records and dynamically export them to LM Dexda for processing and storage. This enables LM Dexda to maintain a current copy of selected information contained within CMDB, which is then used for enriching incoming events. 

Event enrichment provides additional business and operations context for LM Dexda’s event processing and machine learning. This also provides the correct record associations for native ServiceNow records, for example reference fields and many-to-many (m2m) tables such as Affected CIs.

LMDX contains a prebuilt Config record for the cmdb_ci table to allow for quick synchronization of core standard CMDB data between ServiceNow and LM Dexda. However, if there are more specific fields that are only available on a child class within CMDB, you can set up that table to be synchronized via LMDX. For more information, see Creating a New table and Artifacts.

Hiearchy Support and Relationship Settings

LMDX utilizes the CMDB hierarchy. If a record in a child table matches the parameters set for a Config record on a parent table in CMDB, that record triggers the parent table’s configuration. However, if there are multiple Config records associated to different CMDB tables that could apply to a record, LMDX will use the closest match (for example lowest) within the CMDB hierarchy.

LMDX also utilizes the domain hierarchy in a similar fashion in the case of a CMDB configuration in a domain separated instance. LMDX can send the relationships between CIs using a simple set of configuration record settings as described in the following.

Configuration Records

A Config (x_lomo_dx_config) record is the main record in LMDX. It indicates a ServiceNow table being marked as synchronizing with LM Dexda via LMDX, as well as having settings to configure when updates should be sent.

Inbound

The Inbound tab has links to the main records required for LMDX to perform processing on inbound messages from LM Dexda. These records are an Import Set Table, and a Transform Map.

Outbound

The Outbound tab contains settings used to configure when updates should be sent to LM Dexda, as well as links to the main records required for LMDX to perform processing for outbound messages to LM Dexda.

Outbound settings include:

• Condition—Lets you set a condition so that only records matching the condition are considered for processing. Used in conjunction with Trigger fields.
• Trigger fields—Indicates fields that, when values are changed in any of the listed fields, LMDX will trigger an update to be sent to LM Dexda. Used in conjunction with Condition.
• Import update fields—Indicates fields that, when values are changed in any of the listed fields, LMDX should not merge the updates with existing pending updates and instead create a new update with the record’s current state. The available list of fields is limited to the selected Trigger fields. For more information, see Payload Merging.
• Only send LMDX created records—Lets you indicate that only records that have been created by LMDX should be synchronized. This means that there is no need for a condition to be set that relies on records being created or updated by a specific user. This field is intended for Config records on “task-like” tables, for example incident.
• Record type—This is filled with a specific value provided by your LM Dexda administrator.

The Outbound tab also has links to the main records required for LMDX to perform processing to send messages to LM Dexda. These records are a Business Rule and Outbound transform map.

CMDB Relationships

The CMDB relationships tab holds settings that determine if a configuration item’s relationships should be transferred to LM Dexda. This tab only appears if the table marked in the Config record is detected as being part of the CMDB hierarchy.

The Maximum height and Maximum depth settings define how many levels of relationships should be processed with each CI record. In the following example image, “4” height and “4” depth means that for each CI record, each level of relationship will be processed up to four times.

Load Historical Records

The Load historical records button lets you easily export all existing records matching the condition set to LM Dexda. These records will be deemed ‘historical’ and will use both insert and update operation type Outbound field maps. 

These records will be considered lower priority when batching outbound payloads to send to LM Dexda. The records will also always be merged with an updated payload if an update occurs on the base record before the outbound payload has been sent. For more information, see Payloads Table.

Domain Separation

LMDX can work natively in ServiceNow instances that have enabled domain separation. This allows for the logical separation of a ServiceNow instance into separate domains, where a single instance can support multiple organizations. As a managed service provider (MSP) you can for example segregate events, alerts and insights by tenant. For more information, see Grouping by Tenant and Domain Separation.

LMDX itself is not domain separated and all scoped application records will be in the Global domain. This is because the SN admin role is required (for security reasons) for users to be able to access and configure LMDX.

All LMDX artifacts (config record, Outbound Transform Map and Outbound Field Maps) must be created within the Global domain to ensure the application works correctly. The only exception is Business Rule – this must reside in the primary domain of your instance. For more information, see the ServiceNow documentation.

Enabled Domains

You can enable domain support for LMDX. This lets you set up specific domains marked as “enabled” in LMDX, where each enabled domain can have its own LM Dexda credentials, allowing for the separation of data within LM Dexda portals. For more information, see Enabling Domain Support.

Domain Hierarchy Support

LMDX utilizes the domain hierarchy. If a record in a child domain matches the parameters set for a Config record in a parent domain, that record triggers the parent domain’s config. This allows for configuration standardization across multiple child domains, for example different customers. You can make changes in one place and LMDX will apply that change across all child domains.

However, if there are multiple Config records associated with different Enabled Domains that could apply to a record, LMDX will use the closest match (for example lowest) within the domain hierarchy.

LMDX also utilizes the CMDB hierarchy in a similar fashion. In the case of a CMDB config in a domain separated instance, the order of matching is first done on the CMDB hierarchy within the same domain, before moving up the domain hierarchy.

Payloads Table

LMDX captures all incoming (inbound) and outgoing (outbound) data in the form of Payload records (x_lomo_dx_payload). This allows you to easily see what information is coming and going from your instance. It also allows for the sequential processing of payloads and recovering from errors.

Payload Sending

LMDX periodically sends outbound payloads in batches. This is done via a Scheduled Job named LMDX – Process outbound payloads, which is set to run every 60 seconds by default.

LMDX prioritizes sending insert and update payloads, for example payloads generated due to a record being inserted or updated, over historical records. If there is not enough space in the batch, any remaining payloads will stay in pending state until the scheduled job runs again.

Payload Merging

Payload merging occurs if there is an outbound payload waiting to be sent, but the base record associated with that payload is updated before that payload is sent. This means that for most updates only a single payload per record is ever sent, with the payload reflecting the most up-to-date values.

However, merging does not occur if any important update field had its value changed during the update. Instead, a new Outbound Payload record is generated and will be added to the end of the queue of insert and update payloads to be sent.

Automatic Retry Policy

Outbound payloads are always automatically retried if an error occurs. This happens when the Scheduled Job runs again to send Outbound payloads to LM Dexda.

Inbound payloads do not have an automatic retry policy. This is because any error or warnings for inbound payloads must be resolved manually by a ServiceNow administrator. Therefore inbound payloads have a sequential processing feature described in the following.

Manual Retry Policy

Outbound payloads have no mechanism for manual retries, as they are always automatically retried.

Inbound payloads allow for manual retries and will display the Reprocess button if the status of the payload is Error or Complete (with warning). Manual retries will perform sequential processing of inbound payloads, if applicable.

Sequential Processing of Inbound Payloads

LMDX has a sequential processing feature for inbound payloads. If an error or warning occurs during the processing of an inbound payload, any subsequent new inbound payload record with the same External reference (external_reference) value will automatically follow the same warning or error.

Once the root cause of the warning or error has been resolved, it is possible to use any of the payloads with the same External reference value to Reprocess all existing payloads in sequential order. This is done using the Created on (sys_created_on) value for each payload. This results in all payloads being processed in the same order in which ServiceNow received them from LM Dexda.

Deletion of Payload Records

Payload records are automatically deleted using the built-in Table Cleaner function in ServiceNow. For more information, see the ServiceNow documentation.

There is no automatic deletion of any payloads with a status Error, or inbound payloads with status Complete (with warning). This is to allow for recovery from errors or warnings.

Outbound Transform Maps and Field Maps

Outbound transform maps work in the same way as ServiceNow transform maps. Using these you can configure which fields on a given record should be sent from ServiceNow to LogicMonitor. The fields are specified using Outbound Field Maps, which are also similar to ServiceNow field maps.

Outbound Field Maps

The following features for Outbound Field Maps are specific to the LogicMonitor integration.

• Value type—Available for fields that have an underlying value along with the value displayed in the user interface. It indicates if a field should send the “real” value (for example, a sys_id for a reference field), the “display value” (the value you see displayed in a reference field), or both values.
  
  Selecting “Both” sets the “display” value to be the value for the field, along with a field with a suffix of “_fv” that will contain the “real” value.

{
    "state": "New",
    "state_fv": "1",
}
{
    "state": "New",
    "state_fv": "1",
}

• Operation type—Indicates if a field is to be sent for a specific record operation type. For example, a field should only be sent if a record has been inserted, updated, or both.

Scripting in Outbound Field Maps

Similar to Field maps in ServiceNow, Outbound Field Maps can run scripts during the transform process. In the Outbound Field Map form, select Use script to display the Script field and the associated Field name.

When adding scripts in the Scripts field you can use the following variables:

• current—A GlideRecord of the record being processed by the outbound transform. The same current object as in Business Rules.
• ignore—A boolean indicating if a field should be ignored. This value does not need to be returned.

To use the script field, you must return a value as shown in the following example. Alternatively, you can set “ignore” to “true”.