Sciencelogic Integration Service Servicenow 1-8-0

Integration Service: ServiceNow
Integration
Version 1.8.0
Table of Contents
Introduction to ServiceNow Integration 3
Incident Sync Solution Prerequisites 4
Version Prerequisites 4
Installation Prerequisites 4
CMDB Sync Solution Prerequisites 5
Architecture Overview for ServiceNow Integration 6
Integration Applications Included in the ServiceNow Integration 6
ServiceNow Default Integration Applications 6
Internal Integration Applications 8
Monitoring the Integration Service 9
PowerPacks for Monitoring Elements of the Integration Service 9
Integration Service System Diagnostics 10
Integration Service Endpoints 11
Flower API 11
Couchbase API 11
Docker Statistics 12
Integration Service Log Files 12
Accessing Docker Log Files 12
Accessing Local File System Logs 13
Understanding the Contents of Log Files 13
Incident Sync Integration 14
Installing the ScienceLogic Update Set in ServiceNow 15
Installing the ServiceNow Base Pack PowerPack in SL1 17
Event Data Flow: Integration Service to ServiceNow 18
Event Data Flow: SL1 to Integration Service 20
Validating Network Communications 21
Checking DNS 21
Checking HTTPS and JSON 22
HTTP Codes 22
Creating a ServiceNow Group 23
Creating a ServiceNow User 24
Creating an Integration Service Credential 26
Incident Sync Setup 27
Configuring Run Book Automation 30
Aligning Run Book Action Snippet Credentials 31
Enabling Run Book Action Policies 31
Customizing Run Book Action Policies 33
Enabling Run Book Automation Policies 36
Viewing Incidents and Events 37
Hyperlinking Events 38
ServiceNow Hyperlinking 39
Viewing the Incident Import Table in ServiceNow 39
ServiceNow, ScienceLogic Event, and Incident Priority Matrix 41
Adding Additional Fields to the Transform Map 44
CMDB Sync Integration 50
Installing the ScienceLogic Identification Engine Update Set in ServiceNow 53
Installing the CMDB Plugin in ServiceNow 54
The ServiceNow Identification and Reconciliation Module 55
Creating a ServiceNow Update Set 56
Configuring Service Rules for Device Sync 57
Adding Service Rules to an Update Set 60
Exporting an Update Set 61
CMDB Sync Integration Overview 62
Mapping and Syncing SL1 Organizations with ServiceNow Companies 63
Mapping and Syncing SL1 Devices to ServiceNow 63
Configuring Domain Separation 66
Adding Device Mappings with Postman 67
Persistently Saving Device Mappings with the API 69
Default Device Attribute Mappings 70
Mapping and Syncing Attributes for Devices 72
Adding New Device Attributes to ServiceNow 74
Mapping and Syncing SL1 Network Interfaces to ServiceNow 75
Syncing Device Maintenance Schedules 78
Discovery Sync 81
Configuring ServiceNow Service Requests for Discovery Sync 81
Discovery Sync Workflow 83
Running a Discovery Sync for a Device 83
Running a Discovery Sync for a Virtual Device 88
Scheduling Integration Applications 91
Troubleshooting CMDB Sync 94
Using SL1 to Monitor ServiceNow 97
What Does the ServiceNow Base Pack PowerPack Monitor? 98
Installing the ServiceNow Base Pack PowerPack 98
Creating a SOAP/XML Credential for ServiceNow 99
Creating a Virtual Device for the ServiceNow Base Pack 102
Aligning the ServiceNow Base Pack Dynamic Applications 103
Viewing the ServiceNow Open Incidents Dashboard 105
Integration Service API Endpoint Usage 106
Incident Sync 107
Fields 107
u_imp_silo_incidents 107
incident 107
Transforms 108
ScienceLogic Incident 108
ScienceLogic Event 108
Device Sync, Interface Sync 109
Fields 109
u_imp_silo_device 109
u_silo_relationship 109
cmdb_ci 110
cmdb_ci_network_adapter 110
Transforms 111
Discovery Sync 111
Fields 111
u_silo_request 111
cmdb_group 112
Transforms 112
Company / Manufacturer / Hardware Model Sync 112
Fields 112
core_company 112
u_imp_silo_org_ven_mfg 113
Transforms 113
ScienceLogic Company import 113
Hardware Model Sync 114
Fields 114
cmdb_hardware_product_model 114
u_imp_silo_model 114
Transforms 115
Hardware Model import 115
Chapter 1
1
Introduction to ServiceNow Integration
Overview
This manual describes how to configure the Integration Service platform for ServiceNow integration. The
integration includes the Incident Sync and Configuration Management Database (CMDB) Sync integration
solutions.
This chapter covers the following topics:
Incident Sync Solution Prerequisites 4

CMDB Sync Solution Prerequisites 5
Architecture Overview for ServiceNow Integration 6
Integration Applications Included in the ServiceNow Integration 6
ServiceNow Default Integration Applications 6
Internal Integration Applications 8
Monitoring the Integration Service 9
PowerPacks for Monitoring Elements of the Integration Service 9
Integration Service System Diagnostics 10
Integration Service Endpoints 11
Integration Service Log Files 12

Incident Sync Solution Prerequisites
This section describes the prerequisites that apply when you integrate ServiceNow with SL1 using the Incident Sync
solution.
Version Prerequisites
The ScienceLogic ServiceNow Incident Sync integration solution requires the following versions:
l SL1 version 8.7.0 or later

l An ap2 version of 5.54.9 or later of the new user interface for SL1. For more information, see the
Introduction to the New User Interface manual.
l ServiceNow version London, Kingston, Jakarta, or Istanbul with Web Services enabled.
Installation Prerequisites
To install the ScienceLogic ServiceNow Incident Sync integration solution, you must have administrator access to
both the SL1 Management Platform and ServiceNow. Specifically, you will need:
l ScienceLogic root SSH access

l ScienceLogic administrator access to the Administration Portal
l ServiceNow administrator access
You must also have TCP ports 80, 443, and 7706 open on the Integration Service for communication to SL1 and
the ServiceNow instance. No inbound TCP ports are required to be open.
ScienceLogic highly recommends that you disable all firewall session limiting policies. Firewalls will drop HTTPS
requests, which results in data loss.
Finally, you must perform the following steps:
l Install the ScienceLogic Update Set in ServiceNow. The Integration Service requires version 1.8.0 or later of
the ScienceLogic Update Set. For more information, see Installing the ScienceLogic Update Set in
ServiceNow.
l Install the ServiceNow Base Pack PowerPack in SL1. For more information, see Installing the ServiceNow
Base Pack PowerPack in SL1.
4 Introduction to ServiceNow Integration

CMDB Sync Solution Prerequisites
This section describes the prerequisites that apply when you integrate ServiceNow with SL1 using the CMDB Sync 1
solution.
Version Prerequisites
The ScienceLogic ServiceNow CMDB Sync integration solution requires the following versions:
l SL1 version 8.7.0 or later

l An ap2 version of 5.54.9 or later of the new user interface for SL1. For more information, see the
Introduction to the New User Interface manual.
l ServiceNow version London, Kingston, Jakarta, or Istanbul with Web Services enabled.
Installation Prerequisites
To install the ScienceLogic ServiceNow CMDB Sync integration solution, you must have administrator access to
both the SL1 Management Platform and ServiceNow. Specifically, you will need:
l ScienceLogic root SSH access

l ScienceLogic administrator access to the Administration Portal
l ServiceNow administrator access
You must also have TCP ports 80, 443, and 7706 open on the Integration Service for communication to SL1 and
the ServiceNow instance. TCP port 443 inbound needs to be open for the run book actions on SL1 to trigger
Integration Service applications that perform incident-related tasks.
ScienceLogic highly recommends that you disable all firewall session-limiting policies. Firewalls will drop HTTPS
requests, which results in data loss.
Finally, you must perform the following steps in ServiceNow:
l Install the ScienceLogic Update Set. The Integration Service requires version 1.8.0 or later of the
ScienceLogic Update Set. For more information, see Installing the ScienceLogic Update Set in
ServiceNow.
l Install the ScienceLogic Identification Engine Update Set. For more information, see Installing the
ScienceLogic Identification Engine Update Set.
l Activate the Configuration Management for Scoped Apps (CMDB) plug-in. For more information, see
Installing the CMDB Plugin on ServiceNow.
CAUTION: You might find multiple plug-ins in ServiceNow that relate to "Configuration Management". To
avoid possible conflicts, make sure you activate the correct plug-in: Configuration
Management for Scoped Apps (CMDB).

Architecture Overview for ServiceNow Integration
The following diagram illustrates the architecture of the Integration Service: ServiceNow Integration:
Integration Applications Included in the ServiceNow

Integration
Some of the integration applications on the [Integrations] tab are internal applications that you should not run
directly. Instead, other "parent" integration applications run these internal applications.
TIP: To view the internal integration applications, click the Filter icon ( ) at the top right of the [Integrations]
tab and select Show Hidden Integrations. Internal integration applications are hidden by default.
ServiceNow Default Integration Applications

The following integration applications are included with the ServiceNow integration:
l Cache ServiceNow CI Entries. Reads all existing ServiceNow Configuration Items (CIs) from a remote
ServiceNow system and writes them to a cache.
l Cache ServiceNow CIs and ScienceLogic Device Classes. Reads all existing SL1 device classes and
ServiceNow Configuration Items (CIs) and writes them to a cache.

l Clean Snow Interface Cache. Clears the cache of all ServiceNow interface-related entries of a specified
region. If no region is provided, this application clears the cache for all SL1 entries.
l Create or Update ServiceNow Incident from ScienceLogic Event. Reads SL1 events and creates (if
needed) or updates the corresponding ServiceNow Incident. 1
l Fetch all EM7 Devices. Gets all devices from SL1.
l Generate Required CI Relations for ServiceNow. Uses the desired mappings dictionary and determines
the required relationships for ServiceNow.
l IS Backup. Creates a backup file of the Couchbase database used by the Integration Service and sends the
file to a remote location.
l IS Restore. Restores a Couchbase backup file that was created up with the "IS Backup" integration
application.
l IS System Diagnostics. Displays a report of platform diagnostics for the services used by the Integration
Service.
l Poll Discovery Sessions. Loads and pulls Discovery sessions and processes Active Directory sessions.
l Pre-Discovery Sync. Runs the following integration applications as part of Discovery:
l Sync Collector Groups from SL1 to ServiceNow

l Sync Device Groups from SL1 to ServiceNow
l Sync Credentials from SL1 to ServiceNow
l Sync Device Templates from SL1 to ServiceNow
l Sync Organizations from SL1 to ServiceNow
l Sync Virtual Device Classes from SL1 to ServiceNow
l Sync Collectors from SL1 to ServiceNow
l Process Discovery Session Requests. Pulls Discovery session requests from ServiceNow and creates a
Discovery session in SL1.
l ScienceLogic to ServiceNow Device Sync using GraphQL. Collects all required data from ServiceNow
and SL1 using GraphQL, and then runs multiple CI syncs for each device to be synced.
l ScienceLogic to ServiceNow Interface Sync. Collects interface data from ServiceNow and SL1, and then
runs multiple CI syncs for each interface to be synced.
l Sync Hardware Models from SL1 to ServiceNow. Pulls hardware model values from SL1 and syncs to
ServiceNow.
l Sync Maintenance from ServiceNow to SL1. Performs maintenance of synced devices in ServiceNow and
SL1.
l Sync Manufacturers from SL1 to ServiceNow. Pulls manufacturer values from SL1 and syncs to
ServiceNow.
l Sync Organizations from SL1 to ServiceNow. Pulls organizations from SL1 and syncs to ServiceNow.
l Sync ServiceNow Incident State to ScienceLogic Event. Clears or updates SL1 events when the related
ServiceNow Incident is updated.
l Template App. Application template for creating integration applications.

l Update ServiceNow Incident when ScienceLogic Event is Acknowledged. Updates the synced
ServiceNow incident when the corresponding SL1 event is acknowledged.
l Update ServiceNow Incident when ScienceLogic Event is Cleared. Updates the synced ServiceNow
Incident when the corresponding SL1 event is cleared.
Internal Integration Applications

The following integration applications are "internal" applications that should not be run directly, but are
automatically run by applications from the previous list:
l Bulk Update ScienceLogic Events. Bulk updates SL1 events with a given payload.
l Cache ScienceLogic Devices using GraphQL. Reads all existing SL1 and ServiceNow devices and writes
them to a cache using GraphQL.
l Cache SL1 Interfaces. Reads all existing SL1 and ServiceNow network interfaces and writes them to a
cache.
l Cancel Maintenance. Cancels a scheduled maintenance in SL1.
l Clear ServiceNow Device Cache. Clears the cache of all ServiceNow device-related entries of a specified
SL1 ID. If no SL1 ID is provided, this application clears the cache for all SL1 entries.
l Create Discovery Session in ScienceLogic. Creates and starts a Discovery session in ScienceLogic and
updates the ServiceNow service request.
l Create Maintenance. Creates a maintenance schedule in SL1.
l Create ServiceNow CI. Creates a new ServiceNow CI with a mappings dictionary, but does not attempt to
look up new interfaces.
l Create Virtual Device in ScienceLogic. Creates a virtual device in SL1 and updates the Requested Item
(RITM) value.
l Modify Maintenance. Updates a scheduled maintenance in SL1
l Post Company/Org Updates. Posts company or organization updates to ServiceNow or SL1.
l Post New Company to ServiceNow. Posts new companies to ServiceNow.
l Post New Organization to ScienceLogic. Posts new organizations to SL1.
l Post to u_silo_request table in ServiceNow. Posts discovery-related data to ServiceNow.
l Pull and Post Discovery Logs. Pulls Discovery session logs from SL1 and posts updates to ServiceNow.
l Remove Maintenance. Removes a scheduled maintenance in SL1.
l Schedule Maintenance. Creates a scheduled maintenance in SL1.
NOTE: The ServiceNow integration also includes one default configuration on the [Configurations] tab:
"Test Host Settings", which contains host information for testing.

Monitoring the Integration Service
You can use a number of ScienceLogic PowerPacks to help you monitor the health of your Integration Service 1
system. This section describes those PowerPacks and additional resources and procedures you can use to monitor
the components of the Integration Service.
PowerPacks for Monitoring Elements of the Integration Service

You can download the following PowerPacks from the ScienceLogic Customer Portal to help you monitor your
Integration Service system:
l ScienceLogic: Integration Service PowerPack. This PowerPack monitors the state of tasks running on the
Integration Service. This PowerPack alerts users on SL1 if an application on the Integration Service fails. This
PowerPack lets you monitor the status of your integration applications, and based on the events generated by
this PowerPack, you can diagnose why applications failed on the Integration Service.
l Docker PowerPack: This PowerPack monitors the Docker containers, services, and Swarm that manages
the Integration Service containers. This PowerPack also monitors the Integration Service when it is configured
for High Availability. Use version 103 or later of the Docker PowerPack to monitor Integration Service
services in SL1.
l CouchbasePowerPack: This PowerPack monitors the Couchbase database that the Integration Service uses
for storing the cache and various configuration and application data. This data provides insight into the health
of the databases and the Couchbase servers.
l ServiceNow Base Pack PowerPack: This PowerPack queries ServiceNow using REST to get information
about a ServiceNow instance. This PowerPack contains Run Book Automations for the Incident module
integration and two Dynamic Applications that monitor the Incident and CMDB ServiceNow tables. The
"ServiceNow: Incident Metrics" Dynamic Application retrieves information about incident types, priorities, and
states. The "ServiceNow CMDB Configuration" Dynamic Application gathers data about all ServiceNow
Configuration Items (CIs) in the CMDB that are being synced by the Integration Service, including an overall
count. This CI Count value is used for billing purposes. Additionally, the "ServiceNow Open Incidents"
dashboard displays a view of the information in the ServiceNow Incident table.
For more information about installing and using the ServiceNow Base Pack PowerPack, see Using SL1 to
Monitor ServiceNow.
For more information about installing and using the ScienceLogic: Integration Service PowerPack, see the
Monitoring the Integration Service manual.

Integration Service System Diagnostics
The "IS System Diagnostics" integration application lets you view platform diagnostics for the Integration Service.
You can use the information displayed in these diagnostics to help you troubleshoot issues with the different tools
used by the Integration Service.
Running the "IS System Diagnostics" integration application in the Integration Service user interface generates a
report that you can access on the [Reports] tab:
This diagnostic report displays overall Integration Service settings, such as the Integration Service version, Docker
version, kernel version, hostname, cluster settings, scheduled applications, CPU and memory statistics, installation
date, and cache information.
TIP: If you are using a specific integration application that you want to monitor with the "IS System Diagnostics"
integration application, click the [Configure] button and type the name of that integration application in
the incident_create_app field of the Configuration pane.

Integration Service Endpoints
This section provides additional technical details about monitoring the Integration Service. The following
information is also available in the PowerPacks listed above. 1
Fl ower A PI
The following Flower API endpoints return data about the Flower tasks, queues, and workers. The tasks endpoint
returns data about task status, runtime, exceptions, and application names. You can filter this endpoint to retrieve a
subset of information, and you can combine filters to return a more specific data set.
/flower/api/tasks. Retrieve a list of all tasks.
/flower/api/tasks?app_id={app_id}. Retrieve a list of tasks filtered by app_id.
/flower/api/tasks?app_name={app_name}. Retrieve a list of tasks filtered by app_name.
/flower/api/tasks?started_start=1539808543&started_end=1539808544. Retrieve a list of all tasks

received within a time range.
/flower/api/tasks?state=FAILURE|SUCCESS. Retrieve a list of tasks filtered by state.
/flower/api/workers. Retrieve a list of all queues and workers
To view this information in the Flower user interface navigate to <hostname_of_integration_service_

system>/flower.
For more information, see the Flower API Reference.
NOTE: If you use the ScienceLogic: Integration Service PowerPack to collect this task information, the
PowerPack will create events in SL1 if a Flower task fails.
Couchb a se A PI
The following Couchbase API endpoints return data about the Couchbase service. The pools endpoint represents
the Couchbase cluster. In the case of the Integration Service, each node is a Docker service, and buckets
represent the document-based data containers. These endpoints return configuration and statistical data about
each of their corresponding Couchbase components.
<hostname_of_integration_service_system>:8091/pools/default. Retrieve a list of pools and nodes.
<hostname_of_integration_service_system>:8091/pools/default/buckets. Retrieve a list of buckets.
To view this information in the Couchbase Administrator user interface, navigate to <hostname_of_

integration_service_system>:8091.
For more information, see the Couchbase API Reference.

NOTE: You can also use the Couchbase PowerPack to collect this information.
Docker Sta ti sti cs
You can collect Docker information by using SSH to connect to the Docker socket. You cannot currently retrieve
Docker information by using the API.
To collect Docker statistics:
1. Use SSH to connect to the Integration Service instance.

2. Run the following command:
curl --unix-socket /var/run/docker.sock http://docker<PATH>
where <PATH> is one of the following values:
l /info
l /containers/json
l /images/json
l /swarm
l /nodes
l /tasks
l /services
NOTE: You can also use the Docker PowerPack to collect this information.
Integration Service Log Files

Use the following procedures to help you locate and understand the contents of the various log files related to the
Integration Service.
A ccessi ng Docker L og Fi l es
The Docker log files contain information logged by all containers participating in the Integration Service. The
information below is also available in the PowerPacks listed above.
To access Docker log files:

2. Run the following Docker command:
docker service ls

3. Note the Docker service name, which you will use for the <service_name> value in the next step.
4. Run the following Docker command:
docker service logs -f <service_name> 1

A ccessi ng L oca l Fi l e System L og s
The local file system logs display the same information as the Docker log files. These log files include debug
information for all of the Integration Service integration applications and all of the Celery worker nodes.
To access local file system logs:

2. Navigate to the /var/log/iservices directory to view the log files.
Und ersta nd i ng the Contents of L og Fi l es
The pattern of deciphering log messages applies to both Docker logs and local log files, as these logs display the
same information.
The following is an example of a message in a Docker log or a local file system log:
"2018-11-05 19:02:28,312","FLOW","12","device_sync_sciencelogic_to_servicenow","ipaas_
logger","142","stop Query and Cache ServiceNow CIs|41.4114570618"
You can parse this data in the following manner:
'YYYY-MM-DD' 'HH-MM-SS,ss' 'log-level' 'process_id' 'is_app_name' 'file' 'lineOfCode'

'message'
To extract the runtime for each individual task, use regex to match on a log line. For instance, in the above
example, there is the following sub-string:
"stop Query and Cache ServiceNow CIs|41.4114570618"
Use regex to parse the string above:
"stop …… | …"
where:
l Everything after the | is the time taken for execution.

l The string between "stop" and | represents the step that was executed.
In the example message, the "Query and Cache ServiceNow CIs" step took around 41 seconds to run.

Chapter
2 2
Incident Sync Integration
Overview
This chapter describes the ScienceLogic integration with the ServiceNow Incident Management Module. This
integration automatically logs, de-duplicates, correlates, updates, and appends ServiceNow Incidents, reducing
the amount of time to resolve critical service issues. This integration covers the entire Incident life cycle, providing a
bi-directional integration between SL1 events and ServiceNow Incidents, while providing a granular view into both
the event and the associated Incident.

Installing the ServiceNow Base Pack PowerPack in SL1 17
Event Data Flow: Integration Service to ServiceNow 18
Event Data Flow: SL1 to Integration Service 20
Validating Network Communications 21
Creating a ServiceNow Group 23
Creating an Integration Service Credential 26
Incident Sync Setup 27
Configuring Run Book Automation 30
Aligning Run Book Action Snippet Credentials 31
Viewing Incidents and Events 37
Hyperlinking Events 38
Viewing the Incident Import Table in ServiceNow 39
ServiceNow, ScienceLogic Event, and Incident Priority Matrix 41

Adding Additional Fields to the Transform Map 44
Installing the ScienceLogic Update Set in ServiceNow
NOTE: For information about version and installation prerequisites for the Incident Sync Integration Solution,
see the Introduction chapter.
The ScienceLogic Update Set for ServiceNow is the only component that you must install on the ServiceNow
instance. An update set is an XML file containing a group of customizations that can be moved from one
ServiceNow instance to another.
NOTE: The Integration Service requires version 1.8.0 or later of the ScienceLogic Update Set.
Retrieve the update set from your ScienceLogic representative and download the file. To download the set to your
computer, click the file name for the update set XML file. Please note that there are two update sets to choose from,
depending upon your configuration:
l If you upgraded from SyncServer to the Integration Service, use update set ScienceLogic 3.x to Integration
Service - 1.8.0.xml. If you upgraded from a version of SyncServer before version 3.1.28, you might want to
upgrade your update set to 3.1.28 using ScienceLogic 3.1.28 for SyncServer.xml before using
ScienceLogic 3.x to Integration Service - 1.8.0.xml.
l If you have only used the Integration Service, use update set ScienceLogic ServiceNow Integration -
1.8.0.xml.
NOTE: To ensure that incidents are linked to Configuration Items (CIs), you must run the "ScienceLogic To
ServiceNow Device Sync using GraphQL" integration application on a fresh Integration Service
system at least twice before running Incident Sync.
To install the ScienceLogic Update Set in ServiceNow:
1. Log in to ServiceNow as an administrator, then navigate to System Update Sets > Retrieved Update Sets
on the left menu.
2. Click Import Update Set from XML.
15 Incident Sync Integration

3. Click the [Choose File] button, then navigate to the update set XML file you downloaded. Select the XML file
and click [Upload].
4. After the file is imported, the Retrieved Update Sets page appears. Click the ScienceLogic update set and
then click [Preview Update Set].
5. After the preview set runs, a status page appears. "Success" appears in the Completion code field.
WARNING: If "Success" does not appear in the Completion code field, contact ScienceLogic Support to
assist with reviewing any conflicts that might exist. Do not proceed until all conflicts are resolved
and "Success" appears in the Completion code field.
6. Click Commit Update Set to apply the changes in the update set to your ServiceNow system. A
ScienceLogic option is added to the ServiceNow left menu.

Installing the ServiceNow Base Pack PowerPack in SL1
For the ScienceLogic ServiceNow Incident Sync integration solution, you must install the most recent version of the
ServiceNow Base Pack PowerPack.
NOTE: If you are upgrading from SyncServer, you must disable the old SyncServer Run Book Actions and Run
Book Automation policies before installing the new ServiceNow Base Pack PowerPack.
To install the ServiceNow Base Pack PowerPack:
1. Log in to SL1 as an administrator, then go to the PowerPack Manager page (System > Manage >
PowerPacks).
2. Click the [Actions] button and select Import PowerPack.
3. Click the [Browse] button and navigate to the ServiceNow Base Pack PowerPack file.
4. Select the PowerPack file and click [Import]. The PowerPack Installer modal page displays a list of the
PowerPack contents.
5. Click the [Install] button. After the installation is complete, the ServiceNow Base Pack PowerPack appears
on the PowerPack Manager page.
TIP: By default, installing a new version of a PowerPack overwrites all content in that PowerPack that has
already been installed on the target system. You can use the Enable Selective PowerPack Field
Protection setting in the Behavior Settings page (System > Settings > Behavior) to prevent new
PowerPacks from overwriting local changes for some commonly customized fields. For more information,
see the System Administration manual.
For more information about installing and using the ServiceNow Base Pack PowerPack, see Using SL1 to
Monitor ServiceNow.
For more information about installing and using the ScienceLogic: Integration Service PowerPack, see the
Monitoring the Integration Service manual.

Event Data Flow: Integration Service to ServiceNow
The following chart and steps illustrate the event data flow from the Integration Service to a ServiceNow instance:
1. Workers are subscribed to the Integration Service task queue.

2. When a new event to be synced is placed in the Integration Service task queue, it is assigned and pushed to a
worker.
3. The worker processes and transforms the necessary SL1 event data into a ServiceNow incident and POSTs
the incident to the ServiceNow endpoint.

l If the resulting status code matches the expected status code for the request, the original message is
acknowledged and removed from the queue.
l If the worker crashes while processing the event, the queue senses the unexpected disconnect, and
the same event message is re-delivered to a new worker.
NOTE: The above results are performed through the "late acknowledgment" of tasks. With this setting
enabled, an Integration Service worker will not remove a message from the queue until the message
has been fully processed by the worker. This setting can be enabled or disabled with the environment
variable "task_acks_late".
4. If ServiceNow responds with an unexpected status code when POSTing the incident, the message will be
placed back in the queue with specified re-try parameters.
NOTE: You can configure re-try parameters on a per-task basis. You may want to manually alter your re-try
parameters for tasks depending on the action the task is taking. The configuration of retries includes
the maximum number of times a task is retried after consistently failing, and the delay length between
retries.

Event Data Flow: SL1 to Integration Service
The following chart and steps illustrate the event data flow from SL1 to the Integration Service:
1. Through a Run Book Automation, SL1 identifies an event that should be synced to ServiceNow.
2. A Run Book Action executes a POST action to the Integration Service API to let the Integration Service know
that an integration should be run to sync the event.
l If the Run Book Action is successful and the POST responds with a 200, then the event data is stored in
the Integration Service queue for syncing.
l If the POST does not respond with a 200, then the Run Book Action inserts the missed event into a
table in the SL1 database so that it can be retrieved later.
3. In parallel, a scheduled Integration Service event continuously checks the SL1 database for any missed
events. If any missed events are found, they will be pulled from the database and inserted into the Integration
Service queue.
NOTE: The Integration Service queue is persistently saved to disk, so if the Integration Service stops
unexpectedly, any events that existed in the queue prior to the failure will still exist in the queue after
the Integration Service is running again.

4. Missed are not removed from the SL1 database until after they are inserted into the Integration Service
queue.
Validating Network Communications

All communication between SL1 and ServiceNow is done through TCP port 443. To allow communication
between SL1 and ServiceNow, the SL1 Database Server, Data Collector, or All-In-One Appliance must have
external access to the ServiceNow instance. No inbound TCP ports are required to be open to the SL1 server.
Outbound communication may use NAT or be direct.
NOTE: All firewall session-limiting policies must be disabled. If firewall session-limiting policies are enabled,
HTTPS requests might be dropped by the firewall, resulting in data loss. Check with your security or
firewall administrator to make sure there are no session limiting policies on TCP port 443 for your SL1
servers.
Checking DNS
Because ServiceNow is a cloud-based service, DNS must be configured on all SL1 servers that communicate with
your ServiceNow instance.
NOTE: ServiceNow instances are generally named as: your-instance.service-now.com, where your-
instance is the name of your ServiceNow server. The examples below use mycompany.service-
now.com. Your instance name will be unique to your subscription.
To validate that your SL1 server has proper DNS name resolution configured, test network connectivity and name
resolution using the nmap command, which is available from the command line of any SL1 server:
nmap -sT -p 443 mycompany.service-now.com
If the test was successful, you will see a message similar to the following:
Starting Nmap 5.51 ( http://nmap.org ) at 2013-11-12 20:22 UTC

Nmap scan report for mycompany.service-now.com (199.91.136.100)
Host is up (0.067s latency).
PORT STATE SERVICE
443/tcp open https
If domain name resolution fails, you will see a message similar to:
Failed to resolve given hostname/IP: mycompany.service-now.com.

Checking HTTPS and JSON
You can administer a simple test to determine if the ServiceNow JSON Plug-in web service is configured and
operating using the Basic Authentication method on your ServiceNow instance. To do so, run the following
command from the ScienceLogic Central Database or All-In-One Appliance:
NOTE: In the example below, replace the admin:admin username and password key/value pair with your
ServiceNow administrator username and password and mycompany.service-now.com with your
ServiceNow instance name.
2
curl --location -vu admin:admin -H "Accept: application/json" -H "Content-Type:

application/json"
'https://mycompany.service-now.com/api/now/table/incident'
If not successful, the following message appears:
HTTP/1.1 401 Unauthorized
If successful, a JSON encoded string starting with the "result" variable appears:
{"result":[{"upon_approval":"","location":"1083361cc611227501b682158cabf646",….
HTTP Codes
HTTP codes are necessary for identifying specific problems. The following table lists typical HTTP codes that might
occur when testing the ServiceNow JSON Web Service.
Code Definition
401 Unauthorized. Check that the username and password are correct and properly formatted.
403 Forbidden. ServiceNow understood the request, but either the URL is incorrect, or the user account
does not have permission to see the requested object.
404 The ServiceNow server has not found anything matching the requested URL. Check to make sure there
is data in the target table.
200 Success.
201 Success. Data is posted.
TIP: For more information about the ServiceNow JSON Web Service and the Table API, see
http://wiki.servicenow.com/index.php?title=Table_API. If you continue to have problems, please contact
either ScienceLogic or ServiceNow customer support.

Creating a ServiceNow Group
For best practice and security, create a dedicated ServiceNow account that has restricted access to only the
groups, access control lists (ACLs), and roles needed for ScienceLogic incident management.
To create a ServiceNow Account for ScienceLogic Incident management:
1. In ServiceNow, go to the Groups page (User Administration > Groups).

2. Click [New]. A New record page appears.
3. In the New record page, type the group name and any additional information. Name is the only required
field.
4. Right-click the Group bar and click Save to save the record.
5. At the bottom of the Group form, select the [Roles] tab and click [Edit].

6. Search for ScienceLogic Admin and move it to the right-hand column using the arrow buttons. Click [Save].
When finished, your Group will have an assigned Role:
Creating a ServiceNow User

To create a ServiceNow Account for ScienceLogic Incident management:
1. In ServiceNow, go to the Users page (User Administration > Users).

2. Click [New].

3. In the New record page, complete the following fields:
l User ID. Type a user ID.

l First Name. Type the user's first name.
l Last Name. Type the user's last name.
l Password. Type a password.
l Active. Select this checkbox.
l Web Service Access Only. Select this checkbox.
l Time Zone. Select GMT.
l Date Format. Select System (yyyy-MM-dd).
4. Right-click the header and click Save to save the user.
5. Select the [Groups] tab at the bottom of the record.
6. Find the group you created previously and move the group to the right-hand column using the arrow buttons.
Click [Save].

After the user has been added to the group, you should see their Roles and Groups in their record:
NOTE: See the Create a User page of the ServiceNow Product Documentation for more information on
creating a ServiceNow user account. 2
Creating an Integration Service Credential

To configure SL1 to communicate with ServiceNow, you must first create a SOAP/XML credential. This credential
allows the Run Book Automation scripts and the Dynamic Applications in the ServiceNow Base Pack PowerPack to
connect with your ServiceNow instance. An example SOAP/XML credential that you can edit for your own use is
included in the ServiceNow Base Pack PowerPack.
To create a SOAP/XML credential to access the Integration Service:
1. Go to the Credential Management page (System > Manage > Credentials).

2. Locate the ServiceNow RBA - Example credential, then click its wrench icon ( ). The Edit SOAP/XML
Credential modal page appears.

3. Complete the following fields:
l Profile Name. Type a new name for the ServiceNow credential.

l Content Encoding. Make sure text/xml is selected.
l Method. Make sure POST is selected.
l HTTP Version. Select HTTP/1.1.
l URL. Type the URL for your Integration Service instance.
l HTTP Auth User. Type the username of your Integration Service instance.
l HTTP Auth Password. Type the password of your Integration Service instance.
l Timeout. Type "5".
4. Click [Save As].

5. When the confirmation message appears, click [OK].
Incident Sync Setup

To configure Incident Sync, you will need to create a new configuration file in the Integration Service user interface
and align that configuration file to the relevant integration applications that are triggered by the Run Book Actions in
SL1. The configuration file supplies the login credentials to execute the steps for the integration applications.

For more information about creating a configuration file in the Integration Service, see the "Managing
Configurations" chapter in the Integration Service Platform manual. You can use the "Test Host Settings"
configuration file as a template for your new configuration file.
NOTE: These integration applications should only be triggered by a Run Book Action from SL1. Do not click
the [Run Now] button for these applications in the Integration Service user interface.
1. Log in to the Integration Service user interface with the username isadmin and the password that you set 2
during installation.
2. For the following integration applications, you must "align" the configuration file to run with that application:
l "Create or Update ServiceNow Incident from ScienceLogic Event"

l "Sync ServiceNow Incident State to ScienceLogic Event"
l "Update ServiceNow Incident when ScienceLogic Event is Acknowledged"
l "Update ServiceNow Incident when ScienceLogic Event is Cleared"
3. Open the first integration application and click the [Configure] button. The Configurations pane for that
application appears.

4. From the Configurations drop-down, select the configuration file you created and click [Save] to align that
configuration with the integration application:
NOTE: The values for eventDetails and the other parameters that appear in the Configuration pane are
populated either by the configuration you aligned with the integration application or by the Run Book
Action. Do not modify these values. If you encounter an error, make sure your Run Book Action is
configured properly.
5. Repeat steps 3 to 4 for all of the integration applications listed in step 2.
NOTE: The "Sync ServiceNow Incident State to ScienceLogic Event" application does not have an associated
Run Book Action that triggers Incident Sync. You must schedule this application to run every minute, or
to a time suitable for your requirements. You can use a cron job to trigger this schedule, or you can
use the Integration Service user interface to schedule the application.

Configuring Run Book Automation
You can configure Run Book Automation to ensure that whenever SL1 detects an event, a corresponding incident
is created or updated in ServiceNow.
SL1 features three Run Book Action policies that facilitate this process:
l ServiceNow: Add/Update Incident

l ServiceNow: Event Acknowledged
l ServiceNow: Event Cleared
Each Run Book Action policy calls a single action in SL1. Ensure that the integration application points to the
relevant SL1 system and ServiceNow instance. The action then calls an integration application on the Integration
Service that determines the workflow to execute.

Events in SL1 frequently occur and resolve due to fluctuations in the network and other changing conditions.
However, the Run Book Action policies above use a de-duplication algorithm whereby only a single open
ServiceNow incident exists per device. Therefore, if a device already has an existing ServiceNow incident, the
following updates are made to the ServiceNow incident record:
l The "Work Notes" activity log in the incident record is updated with information about the secondary event(s).
l If a secondary event is of a higher severity than the event that originally created the ServiceNow incident, then
the Impact, Urgency, and Priority fields are updated automatically in the ServiceNow incident record. If the
secondary event is of a lesser severity, those fields are not updated.
l If an event is cleared in SL1 and then later reoccurs before the incident has been "Closed" in ServiceNow,
then the subsequent events appear in the original ServiceNow incident record for that device. If an incident
record has been "Closed," then ServiceNow will create a new incident record when a cleared event reoccurs
in SL1.
l By default, if an event is acknowledged in SL1, the ServiceNow incident record will be updated with the work
notes and the acknowledging user. Clearing a ScienceLogic event will move the ServiceNow incident record
state to "Resolved". If all ScienceLogic events associated with a ServiceNow incident record are clear, the
ServiceNow incident record will, by default, move to a "Resolved" state.
NOTE: You can edit the Run Book Action Snippet code to adjust the behavior for changing states when an
SL1 event is acknowledged or cleared.
Aligning Run Book Action Snippet Credentials

The Run Book Automation policy is initially aligned to an example credential. You will need to align the previously
created credential to the Run Book Action.
Enabling Run Book Action Policies

The ServiceNow Run Book Action policies are disabled on SL1 by default. To enable them, you must enable and
align the ServiceNow credential to each policy.
To enable Run Book Action policies:
1. Log in to your ScienceLogic Administration Portal as an administrator, and then go to the Action Policy
Manager page (Registry > Run Book > Actions).
2. Locate the ServiceNow: Add/Update/Clear Incident policy and click its wrench icon ( ).

3. The Action Policy Editor page appears. Complete the following fields:
l Action State. Select Enabled.

l Snippet Credential. Select the credential that you created in the section Creating an Integration
Service Credential.
l Snippet Code. If you want to customize the Run Book Action script, make changes as necessary. For
more information, see the section Customizing Run Book Action Policies.
4. Click [Save].

Customizing Run Book Action Policies
You can customize several default values that are embedded into the SL1 Run Book Action snippets for
ServiceNow.
To edit Run Book Action snippets:
1. Log in to your SL1 Administration Portal as an administrator and go to the Action Policy Manager page
(Registry > Run Book > Actions).
2. Click the wrench icon ( ) of the Run Book Action you want to edit. The Policy Editor modal page appears:
3. Edit the Snippet Code as necessary, using the information that follows as a guide. When you are finished,
click [Save].
CAUTION: ScienceLogic Run Book Action snippets are written in Python. In the event of a syntax error, the
policies will no longer run. As a result, you must ensure that all edits adhere to Python standards.
TIP: True and False options are case-sensitive and must not contain quotes.

Customizing the "Add/Update/Clear Incident" Run Book Action Script
NOTE: Previous SyncServer users had three separate Run Book Action scripts for add/update, acknowledge,
and clear. These have been rolled into a single Run Book Action in the Integration Service, but there
are still three Run Book policies.
You can customize the following items in the "ServiceNow: Add/Update/Clear Incident" Run Book Action snippet
code: 2
l CORRELATION_TYPE = 5
o This is an integer value and possible values are 1, 2, 3, 4, 5, or 6. Default value is 5.

o All RBA Scripts should use the same value, otherwise correlation will fail.
o 1 = Correlate all duplicate incidents by SL1 ID only.
o 2 = Correlate all duplicate incidents by Event Policy ID only.
o 3 = Correlate all duplicate incidents by device ID only.
o 4 = Correlate all duplicate incidents by Interface ID only. NOTE: This correlation requires that the
ScienceLogic event has an interface aligned. If there is no interface aligned to the event, the returned
Interface ID will be 0.
o 5 = Correlate all duplicate incidents by device ID and Event Policy ID.
o 6 = Correlate all duplicate incidents by device ID, Event Policy ID, and Event Sub Entity ID.
l NEW_SNOW_STATE = 1

o 1 = Incident state is "New".
o 2 = Incident state is "In Progress".
o 3 = Incident state is "On Hold".
o 6 = Incident state is "Resolved".
o 7 = Incident state is "Closed".
o 8 = Incident state is "Canceled".
l ACK_SNOW_STATE =
o This is an integer value and possible values are 1, 2, 3, 6, 7, or 8. There is no default value.

l CLEAR_SNOW_STATE = 6

l You can use the following Passthrough Dictionaries to pass hard-coded mappings through the Integration
Service to ServiceNow.
o NEW_PASSTHROUGH = {}
o ACK_PASSTHROUGH = {}
o CLEAR_PASSTHROUGH = {}
l A hard-coded value for the variable EM7_ID must be set to uniquely identify the ScienceLogic instance. This
can be used for domain separation.
o EM7_ID = "EM71"
l You can set the assignment group that New, Acknowledged, and Cleared incidents are mapped to. To
disable this feature, ensure no values are set. Once an incident is created, the assignment group value will
not be changed by the Run Book Action. To assign an assignment group, set the variable value to the sys_id
of the ServiceNow Assignment Group.
o NEW_ASSIGNMENT_GROUP
o ACK_ASSIGNMENT_GROUP
o CLEAR_ASSIGNMENT_GROUP
Customizing Logging on Run Book Action Script
You can customize the following logging-related items in the ServiceNow Run Book Action snippet code:
l logfile = /data/tmp/ServiceNow_add_update_clear_incident.log
o Location for Logging output.

o Will be created if it does not exist.
o Will be appended with each RBA job.
o Is case-sensitive.

l do_debug_logging = True
o True is on, False is off.

o Is case-sensitive.
o For troubleshooting, these can be enabled or changed.
o Writes logs to /data/tmp/servicenow_rba.log.
Enabling Run Book Automation Policies

2
After you have enabled the ServiceNow Run Book Action policies, you must enable the corresponding ServiceNow
Run Book Automation policies.
To enable the ServiceNow Run Book Automation policies:
1. Log in to your SL1 Administration Portal as an administrator, and then go to the Automation Policy
Manager page (Registry > Run Book > Automation).
2. Locate the ServiceNow: Add/Update Incident policy and click its wrench icon ( ).
3. The Automation Policy Editor page appears. Update the following fields:
l Policy State. Select Enabled.

l Policy Priority. Select High to ensure that this Integration Service automation policy is added to the top
of the queue.

l Available Actions. If it is not already selected, select the corresponding ServiceNow Run Book Action
policy.
TIP: By default, the automation policy will create ServiceNow incidents for all devices. You can limit the
devices affected by making changes to the Organization, Severity, Match Logic, Aligned Devices,
and/or Aligned Events fields.
WARNING: ScienceLogic highly recommends that you do not make changes to the Policy Type, Repeat
Time, or Align With fields or the And event is NOT acknowledged setting.
4. Click [Save].
5. Repeat steps 2-4 for the ServiceNow: Event Acknowledged and ServiceNow: Event Cleared Run Book
Automation policies.
Viewing Incidents and Events

To view SL1-created incidents in ServiceNow, go to the Incidents page (Incident > Open) in the ServiceNow
application. All SL1 incidents use the event message from the SL1 event console as the incident description in
ServiceNow.
For more information about ServiceNow incident management, see

https://wiki.servicenow.com/index.php?title=Incident_Management.

SL1 and ServiceNow use slightly different methods for designating the severity or priority of an event/incident. To
handle the conversion, a transformation script that translates SL1 event severity into the following ServiceNow
Impact, Urgency, and Priority fields automatically deploys with the ScienceLogic Update Set:
SL1 ServiceNow
Event Severity Impact Urgency Priority

2
Critical High High Critical
Major High Medium High
Minor Medium Medium Moderate
Notice Low Medium Low
If a secondary event for the same SL1 device occurs and it has a higher severity level than the existing ServiceNow
incident, the ServiceNow incident automatically updates to indicate the severity change. If a secondary event has a
lower severity level, then the severity is not updated.
When SL1 Run Book Automation creates a ServiceNow incident, the "Working Notes" activity log is updated each
time an action occurs with the incident. The following example illustrates that the initial event that created the
ServiceNow incident was of Major severity. Minutes later, a Critical event occurred and the incident updated
accordingly. Minutes later, the event was acknowledged in SL1 and the incident state was then set to "active,"
letting ServiceNow users know that the problem is being researched.
Hyperlinking Events
Both ServiceNow and SL1 provide mechanisms for hyperlinking to multiple active events and incidents. This
section describes those processes.

ServiceNow Hyperlinking
In ServiceNow, each incident created by SL1 includes a ScienceLogic URL field with a hyperlink back to the SL1
event:
By default, the ScienceLogic URL field does not appear on the incident form. To add the link:
1. In SL1, go to the Behavior Settings page (System > Settings > Behavior).

2. In the Interface URL field, enter the URL of your ScienceLogic system.
The ScienceLogic URL link is dynamic to the actively aligned SL1 event. Because of this, the link might change
multiple times during the life cycle of a ServiceNow incident.
For instance, if the event is cleared or resolved in SL1, the ScienceLogic URL is removed because the event no
longer exists in the SL1 Event Console. If a duplicate or correlated event is later detected and aligned with the
ServiceNow incident, the link will be updated to match the new SL1 event.
Viewing the Incident Import Table in ServiceNow

Each time SL1 creates or changes an incident in ServiceNow, data is inserted into a temporary import table on the
ServiceNow system. This table displays all inbound data from SL1 and is a useful tool to determine what data is
being sent and imported. The incident import table is created automatically when you install the ScienceLogic
Update Set.

To view the data and the status of the import process, in ServiceNow, go to the ScienceLogic Events page
(ScienceLogic > Import Tables > Incident Import):
You can view a complete audit of all import data and transforms by going to the Transform Histories page
(System Import Sets > Advanced > Transform History):

ServiceNow, ScienceLogic Event, and Incident Priority Matrix
By default, when SL1 triggers an event, it is sent to ServiceNow through the Integration Service. The following
mappings are currently in place for SL1 events to Incidents in ServiceNow:
SL1 Event SNOW Priority
Critical P2
Major P3
Minor P4
A transformation script that translates the SL1 event severity into the ServiceNow Impact, Urgency, and Priority
fields automatically deploys with the ScienceLogic Update Set.
By default, the Priority field is read-only and must be set by selecting the Impact and Urgency values.
Priority is calculated according to the following data lookup rules:
Impact Urgency Priority
1 - High 1 - High 1 - Critical
1 - High 2 - Medium 2 - High
1 - High 3 - Low 3 - Moderate
2 - Medium 1 - High 2 - High
2 - Medium 2 - Medium 3 - Moderate
2 - Medium 3 - Low 4 - Low
3 - Low 1 - High 3 - Moderate
3 - Low 2 - Medium 4 - Low
3 - Low 3 - Low 5 - Planning

To edit the transform script:
1. Go to your ServiceNow instance and search for "Transform Map".

2. Under Administration > Transform Maps, select the "ScienceLogic Incident" map.
3. In the Transform Scripts tab, open the OnBefore transform script with the Order of 200.

4. Edit the Impact and Urgency in the following code, as needed:
//Setting impact and urgency off Event Severity on the import table.
switch(source.u_event_severity.toString()){
case '1': //Sciencelogic Event (Critical)
impact = 1;
urgency = 2;
break;
case '2': //Sciencelogic Event (High)
impact = 2;
urgency = 2;
break;
case '3': //Sciencelogic Event (Minor)
impact = 2;
urgency = 3;
break;
case '4': //Sciencelogic Event (Notice)
impact = 3;
urgency = 3;
break;
default:
break;
}
For example, if you want to raise a P1 from a Critical event, you would set it as impact=1 and urgency=1.
Alternatively, using the defaults provided in the SL1 transform script, you can add a business rule which
automatically changes the Priority to a custom preset.

Adding Additional Fields to the Transform Map
If you require additional mandatory fields to be filled out to resolve an incident, you can add those fields to the
transform map. For example, if you require four mandatory fields in the ServiceNow Incident—Assignment
Group, IT Service, Service Component, and Description—to be filled out before that incident can be resolved
in SL1, you would perform the following steps:

To add an assignment group:
1. Navigate to User Administration > Groups.

2. Select the assignment group you want to add. Right-click on the gray task bar at the top and elect Copy sys_
id.
3. Go to the "ServiceNow: Add/Update/Clear Incident" run book action in SL1. Edit the run book action to add
your sys_id:
NEW_ASSIGNMENT_GROUP= ''
ACK_ASSIGNMENT_GROUP= ''
CLEAR_ASSIGNMENT_GROUP= 'ADD SYS_ID HERE'
Add the sys_id to assign the group to Clear, Ack, or trigger a New event which is sent to ServiceNow.
The IT Service, Service Component, and Description fields in our example must be filled in before an Incident
can be closed. To do this, changes must be made in the transform maps that are provided in the form of update
sets from ScienceLogic.
To add the Description field:
1. In your ServiceNow instance, search for "transform map" in the left-hand menu. Click Transform Maps.
2. In the list of transform maps, search for "ScienceLogic" in the field above the Name column.

3. Open the "ScienceLogic Incident" map:
4. The Field Maps table at the bottom of the page allows you to edit or create mappings from the ScienceLogic
Incident Import table to the ServiceNow Incident table. Click on [New] to create a new field mapping.
5. The Source table field should contain the ScienceLogic Incident Import and the Target table should include
the ServiceNow Incident table.
6. To create a new mapping to copy the contents of the Short description field to the Description field, select
Short description from the Source field drop-down menu.
7. In the Target field drop-down menu, select Description.
8. Click Update to save your changes.
The IT Service and Service Component fields in our example are set in the Transform Script in the "ScienceLogic
Event" transform map. To set the fields:
1. Make sure you have the sys_id for the target fields. These can be found in ServiceNow. If a field contains a
magnifying glass, it will require a sys_id. If a field has a drop-down, then type in the field you wish to apply
from the drop-down. In the case of our example, the sys_ids of the two fields are required.
2. In your ServiceNow instance, navigate to the Transform Maps table and select "ScienceLogic Event".

3. In the ScienceLogic Event transform map page, click the Transform Script tab and open the "onAfter" script.

4. Add the following under the "//Update target record when the Event was cleared from Sciencelogic" text:
sl_INT.(target field) = '[sys_id of the source field]'; //(IT service field)
sl_INT.(target field) = '[sys_id of the source field]'; //(Service component)

5. To find the target field, make a temporary mapping to see what the target field is. This mapping can be
deleted once you know the target field.
6. Click [Update] to save your changes. The selected fields will be added into an Incident on closure.

Chapter
3
CMDB Sync Integration
3
Overview
This chapter describes the ScienceLogic integration with the ServiceNow Configuration Management Database
(CMDB). This integration maintains and enhances the ServiceNow CMDB by sharing discovered device
information, importing and exporting data bi-directionally between SL1 and ServiceNow, and by automatically
maintaining ServiceNow Configuration Item (CI) relationships.

Installing the ScienceLogic Identification Engine Update Set in ServiceNow 53
Installing the CMDB Plugin in ServiceNow 54
The ServiceNow Identification and Reconciliation Module 55
Creating a ServiceNow Update Set 56
Configuring Service Rules for Device Sync 57
Adding Service Rules to an Update Set 60
Exporting an Update Set 61
CMDB Sync Integration Overview 62
Mapping and Syncing SL1 Organizations with ServiceNow Companies 63
Mapping and Syncing SL1 Devices to ServiceNow 63
Configuring Domain Separation 66
Adding Device Mappings with Postman 67
Persistently Saving Device Mappings with the API 69
Default Device Attribute Mappings 70

Mapping and Syncing Attributes for Devices 72
Adding New Device Attributes to ServiceNow 74
Mapping and Syncing SL1 Network Interfaces to ServiceNow 75
Syncing Device Maintenance Schedules 78
Discovery Sync 81
Configuring ServiceNow Service Requests for Discovery Sync 81
Discovery Sync Workflow 83
Running a Discovery Sync for a Device 83
Running a Discovery Sync for a Virtual Device 88
Scheduling Integration Applications 91
Troubleshooting CMDB Sync 94
51 CMDB Sync Integration

Installing the ScienceLogic Update Set in ServiceNow
NOTE: For information about version and installation prerequisites for the CMDB Sync Integration Solution,
see the Introduction chapter.
The ScienceLogic Update Set must be installed on the ServiceNow instance. An update set is an XML file
containing a group of customizations that can be moved from one ServiceNow instance to another.
NOTE: The Integration Service requires version 1.8.0 or later of the ScienceLogic Update Set.
Retrieve the update set from your ScienceLogic representative and download the file. Click the file name for the 3
update set XML file to download the set to your computer. Please note that there are two update sets to choose
from, depending upon your configuration:
l If you upgraded from SyncServer to Integration Service, use update set ScienceLogic 3.x to Integration
Service - 1.8.0.xml. If you upgraded from a version of SyncServer before version 3.1.28, you might want to
upgrade your update set to 3.1.28 using ScienceLogic 3.1.28 for SyncServer.xml before using
ScienceLogic 3.x to Integration Service - 1.8.0.xml.
l If you have only used the Integration Service, use update set ScienceLogic ServiceNow Integration -
1.8.0.xml.
To install the ScienceLogic Update Set in ServiceNow:
1. Log in to ServiceNow as an administrator, and then navigate to System Update Sets > Retrieved Update
Sets on the left menu.
2. Click the Import Update Set from XML link.
3. Click [Choose File], and then navigate to the update set XML file you downloaded. Select the XML file and
click [Upload].

4. After the file is imported, the Retrieved Update Sets page appears. Click the ScienceLogic update set and
then click [Preview Update Set].
After the preview set runs, a status page appears. "Success" should appear in the Completion code field.
assist with reviewing any conflicts that might exist. Do not proceed until those conflicts are
resolved and "Success" appears in the Completion code field.
5. Click the Commit Update Set link to apply the changes in the update set to your ServiceNow system. When
you do so, a ScienceLogic option appears on the ServiceNow left menu.
Installing the ScienceLogic Identification Engine Update Set

in ServiceNow
You must install the ScienceLogic Identification Engine Update Set in ServiceNow if you plan to use the
ServiceNow Identification and Reconciliation Module to create and de-duplicate CI records.
To install the ScienceLogic Identification Engine Update Set:
1. Retrieve the update set from your ScienceLogic representative and download the file. Click the XML file name
for the update set to download the set to your computer.
2. Log in to ServiceNow as an administrator, and then navigate to System Update Sets > Retrieved Update
Sets on the left menu.
3. Click the Import Update Set from XML link.

4. Click [Choose File], and then navigate to the update set XML file you downloaded. Select the XML file and
click [Upload].
5. After the file is uploaded, the Retrieved Update Sets page appears. Click the link for the ScienceLogic
update set and then click [Preview Update Set].
6. After the preview set runs, a status page appears. Ensure that "Success" appears in the Completion code
field.
assist with reviewing any conflicts that might exist. Do not proceed until those conflicts are
resolved and "Success" appears in the Completion code field.
Installing the CMDB Plugin in ServiceNow

Installing the ServiceNow Configuration Management for Scoped Apps (CMDB) Plugin is required to manage your
Configuration Items. This involves activating the Configuration Management For Scoped Apps (CMDB) Plugin on
your ServiceNow instance.

To activate the Configuration Management for Scoped Apps (CMDB) plugin:
1. Log in to ServiceNow as an administrator, and then navigate to Plugins (System Definition > Plugins).
2. Search for Configuration Management For Scoped Apps (CMDB) and click on it.
3. Click Activate/Upgrade in the Related Links section.

4. In the Activate Plugin notification, click [Activate].
The ServiceNow Identification and Reconciliation Module

The Integration Service uses the ServiceNow Identification Reconciliation module in ServiceNow to create and de-
duplicate CI records.
The Integration Service builds a JSON-formatted string that is sent to the ServiceNow Identification and
Reconciliation module. The string is encoded to BASE64 before being sent. The following link provides additional
detail about the formatting of the JSON-formatted string: IdentificationEngineScriptableApi.
The JSON-formatted string is sent to a custom field on a custom table in ServiceNow. After the record is inserted,
the custom field that includes the BASE64-encoded JSON string is decoded and run through the
IdentificationEngineScriptable API. Identification (Insert or Update) of Configuration Items (CIs) is handled by the
ServiceNow Identification Reconciliation module.
For more information about the Identification Reconciliation module, see CMDB Identify and Reconcile.
For more information about Identification engine error messages, see Identification engine error messages.

Creating a ServiceNow Update Set
ScienceLogic recommends packaging all customer updates into a standalone ServiceNow update set that you can
export if needed. An update set is an XML file containing a group of customizations that can be moved from one
ServiceNow instance to another. This update set should include any changes or configurations to the service rules
for the ServiceNow Identification and Reconciliation Module.
The service rules are defined on the ServiceNow instance, and include the following:
l Containment rules describe which CIs are contained by a given CI.

l Hosting rules describe the environment on which a CI runs.
Both containment rules and hosting rules help identify dependent CIs correctly during the CI creation process and
service mapping.
3
To create a standalone update set in ServiceNow:
1. Log in to your ServiceNow instance.
2. Enable the Developer Update set picker by clicking the Settings icon ( ) and selecting the Developer tab.
3. Select the Show update set picker in header toggle to enable it, and then close the System Settings
page.
4. In the filter navigator, search for local update sets.
5. Under System Update Sets, select Local Update Sets and click [New]. A new Update Set record appears:

l Name. Specify a name that describes the rules of this update set.
l Application. Set the application scope to Global.
l State. Set to In Progress.
l Complete the remaining fields as needed.
7. Click [Submit] or [Submit and Make Current]. If you selected [Submit and Make Current], go to step 9.
8. If you clicked [Submit], you can select the update set in the picker in the header or navigate to the update set
and select Make This My Current Set in the Related links section.
9. You are ready to make changes in your ServiceNow Instances.
10. When you are done with all updates in the update set, change the update set State field to Complete.
Configuring Service Rules for Device Sync

The ServiceNow Integration on the Integration Service utilizes class hierarchies to build relationships in
ServiceNow. This requires building service rules (containment rules and hosting rules) in ServiceNow to correctly
identify dependent CIs during the business discovery process and service mapping.
ScienceLogic recommends that you include these containment rules and hosting rules in an update set so that
these changes can be easily packaged and deployed across environments. These rules or "mappings" are defined
in the "ScienceLogic to ServiceNow Device Sync using GraphQL" integration application in the Integration Service
user interface. These mappings connect an SL1 device class to a ServiceNow CI class, which determines the
CI class that ServiceNow uses when creating the CI in ServiceNow.
For more information, see CMDB dependent relationship rules and CMDB identification rules at the ServiceNow
website.
For example, if you experience error messages about missing relationships in ServiceNow when you run the
"ScienceLogic To ServiceNow Device Sync using GraphQL" integration application, you might be missing certain
containment rules or mappings that are needed to complete the export process:

To configure ServiceNow CI service rules and mappings:

2. In the filter navigator, type “cmdb_metadata_containment.list” to view the CMDB Metadata Containment
Rules:
3. Click [New]. A new CMDB Metadata Containment Rules record appears:
4. In the New Metadata Containment Rules record, complete the following fields:
l Configuration item class. Specify the child CI class.
l Parent. Specify the parent CI class.
l Relation type. Specify the relationship type. The common relationship types used by the ServiceNow
integration are "contained" or "contained by", depending on your CMDB. Click the magnifying glass
icon to select the correct value.

5. Click [Submit].
6. In the filter navigator, type “metadata hosting” to view the CMDB Metadata Hosting Rules.
7. Click [New]. A new CMDB Metadata Hosting Rules record appears:
8. In the New Metadata Hosting Rules record, complete the following fields:
l Child type. Specify the child CI class.

l Parent type. Specify the parent CI class.
l Relation type. Specify the relationship type. The common relationship types used by the ServiceNow
integration are "Hosts" or "Hosted on", depending on your CMDB. Click the magnifying glass icon to
select the correct value.
9. Click [Submit].
10. Add any relevant containment and hosting rules that are needed to build the CI relationships in ServiceNow.
11. If you are using a version of the Integration Service prior to version 1.7.0, after you have built all of your
containment rules, navigate to System Definition > Scheduled Jobs using the filter navigator. If you are
using version 1.7.0 or later, go to step 15.
12. In the Name column, search for "ScienceLogic". "ScienceLogic Configuration Hierarchy" and "ScienceLogic
Hierarchy Delete" appear.
13. Run the "ScienceLogic Hierarchy Delete" scheduled job first by opening the job and clicking [Execute Now].
14. When the "ScienceLogic Hierarchy Delete" job finishes, run the "ScienceLogic Configuration Hierarchy"
scheduled job by opening the job and clicking [Execute Now].
15. In the Integration Service user interface, go to the [Integrations] tab and manually run the "Cache
ServiceNow CIs and ScienceLogic Device Classes" integration application.
16. Run the "ScienceLogic To ServiceNow Device Sync using GraphQL" integration application and make sure
that no errors exist due to missing CI relationships.

Adding Service Rules to an Update Set
If you submitted your new update set and made it "Current" in Creating a ServiceNow Update Set, skip this step
and go to Exporting an Update Set.
If you did not make your update set current, you will need to identify your current update set and move all of the
service rules you need into your update set. You can find this information in a dropdown located in the ServiceNow
navigation bar:
All of the service rules that you defined are tracked in the update set record under the [Customer Updates] tab.
To add all created service rules to your update set:

2. In the filter navigator, type “Local Update Sets” to view a list of update sets on the ServiceNow instance.
3. Identify your current update set, which should have all of the created service rules tracked.
4. Identify the self-created update set that you want to contain all the service rules. This is the update set that you
want to export.
5. Select the current update set that has all of the already-created service rules.
6. On the [Customer Updates] tab, identify all of the records with a Type of either CMDB Metadata
Containment Rules or CMDB Metadata Hosting Rules:

7. Select each of the relevant service rule records and set the Update set field to match the update set you want
to export. Click the magnifying glass icon to select the correct value.
8. Click [Update].
9. Repeat steps 7-8 until all relevant containment and hosting rules are in the new update set, and then go to
Exporting an Update Set.
Exporting an Update Set

After you have created your update set and defined the service rules, mark your update set as Complete and export
it to an XML file.
To export an update set:

2. In the filter navigator, type “Local Update Sets” to view a list of update sets in ServiceNow:
3. Select your update set from the list.

4. Set the State to Complete and click [Update].

5. From the Update Sets page, select your completed update set from the list.
6. Under the Related Links section, click Export to XML.
7. Save the downloaded XML file.
CMDB Sync Integration Overview

The following topics describe how to sync information between ScienceLogic and ServiceNow.
NOTE: Depending on your configuration, you might not need to run all of the procedures in the following
topics, and you might not need to schedule and run all of the following integration applications.
As a best practice, ScienceLogic recommends that you schedule the following integration applications in the
Integration Service user interface, in the following order:
l "Cache ServiceNow CIs and ScienceLogic Device Classes"

l "ScienceLogic To ServiceNow Device Sync using GraphQL"
l "Pre-Discovery Sync": Running this "parent" integration application will also run the following integration
applications, although the "child" applications might need to be configured independently in the Integration
Service user interface:
l "Sync Collector Groups from SL1 to ServiceNow"

l "Sync Collectors from SL1 to ServiceNow"
l "Sync Credentials from SL1 to ServiceNow"
l "Sync Device Groups from SL1 to ServiceNow"

l "Sync Device Templates from SL1 to ServiceNow"
l "Sync Virtual Device Classes from SL1 to ServiceNow"
l "Sync Organizations from SL1 to ServiceNow"
l "Sync Hardware Models from SL1 to ServiceNow"

l "Sync Manufacturers from SL1 to ServiceNow"
TIP: ScienceLogic recommends that you schedule these integration applications to run at least every 23 hours.
For more information, see Scheduling Integration Applications.
Mapping and Syncing SL1 Organizations with ServiceNow

Companies
To enable the sync of SL1 organizations with ServiceNow companies:
1. In the Integration Service user interface, navigate to the [Integrations] tab.

2. Click the [Run Now] button for the "Sync Organizations from SL1 to ServiceNow" integration application.
The application automatically maps the correct devices to the correct organizations/companies in
ServiceNow.
NOTE: This automated process replaces the manual mapping process from previous releases of the
Integration Service.
Mapping and Syncing SL1 Devices to ServiceNow
NOTE: Before you can start to sync devices, you need to add the VMware update set to ServiceNow and
commit the VMware pre-set update set to ServiceNow.
To map SL1 devices to ServiceNow:
1. In the Integration Service, go to the [Integrations] tab and run the "Cache ServiceNow CIs and
ScienceLogic Device Classes" integration application. This application gets the device classes from
ServiceNow and SL1 caches them.
NOTE: ScienceLogic recommends that you schedule the "Cache ServiceNow CIs and ScienceLogic Device
Classes" integration application to run on a regular basis. However, before you schedule the
application, make sure that you select the correct configuration file to populate the credential details.

2. After the application completes, open the "ScienceLogic To ServiceNow Device Sync using GraphQL"
integration application and click [Configure].
3. Select the necessary configuration file to align with this application from the Configuration drop-down list
and click [Save].
4. Supply the mappings to map the SL1 Device Classes to the ServiceNow CI Classes.
5. To add the mappings using the Integration Service user interface, open the "Cache ScienceLogic Devices
Using GraphQL" application from the list of Hidden applications, click [Configure], and select the necessary
configuration file from the Configuration drop-down list.
NOTE: You can also add the mappings using Postman.
6. Click [Save] and run the "Cache ScienceLogic Devices Using GraphQL" integration application. This step 3
must complete without errors for the mappings to work.

7. Open the "ScienceLogic To ServiceNow Device Sync using GraphQL" integration application and click the
[Configure] button. The Configuration pane appears:
8. Click the Configuration drop-down list and select a configuration to align to this integration application.
9. Select the Domain_Separation option if you want to separate data, processes, and administrative tasks into
logical groupings called domains. By default, this option is not selected. For more information, see
Configuring Domain Separation.
10. Scroll down to the section for the mappings parameter and create a mapping for each of the SL1 device
classes and or asset attributes that have been discovered.
TIP: Use the [Tab] button to move down through the list of options in a Mapping dropdown list, press [Shift]+
[Tab] to move up, and press [Enter] to select a highlighted option.

Configuring Domain Separation
If your ServiceNow configuration uses domain separation to separate data, processes, and administrative tasks into
logical groupings called domains, you must create and use a new configuration file on the [Configurations] tab
of the Integration Service user interface.
WARNING: Follow these steps only if your configuration uses ServiceNow domain separation.
After you create the configuration file, align that new file with the relevant integration applications, including the
"ScienceLogic to ServiceNow Device Sync using GraphQL" application.
NOTE: The "name": "Domain_Credential" values in the following code represent the sys_id of the
domain mapped to the corresponding ServiceNow user that is permitted to insert data for the domain.
3
Every domain-specific sys_id should reference an object containing "user" and "password"
values.
To create a configuration for domain separation:
1. In the Integration Service user interface, navigate to the [Configurations] tab and click the plus icon ( ).
The Create a new configuration pane appears.
2. Complete the first four descriptive fields for the configuration.
3. In the Configuration Data field, add the following JSON code:

{
"configuration_data": [{
"name": "domain_sep_user1",
"value": "usera"
},
{
"name": "domain_sep_user1_pw",
"value": "passworda",
"encrypted": true
},
{
"name": "domain_sep_user2",
"value": "userb"
},
{
"name": "domain_sep_user2_pw",
"value": "password",
"encrypted": true
},
{
"name": "Domain_Credentials",
"value": {
"98c37b193790200044e0bfc8bcbe5dbe": {
"user": "${config.domain_sep_user1}",
"password": "$config.domain_sep_user1_pw}"
},
"b7e831bdc0a80169015ae101f3c4d6cd": {
"user": "${config.domain_sep_user1}",
"password": "$config.domain_sep_user1_pw}"
}
}
}
]
}
4. Click the [Save] button.

5. Make sure to select this configuration and select the Domain_Separation option on the "ScienceLogic to
ServiceNow Device Sync using GraphQL" integration application.
NOTE: For each domain for which you want to write to a specific user, add that user's username and
password, and a reference to it, in the Domain_Credentials section of the relevant integration
application in the Integration Service user interface.
Adding Device Mappings with Postman

You can dynamically set the device mappings on a per-run basis using the API. You can also persistently save
device mappings with the API.
To add device mappings using Postman:
1. In Postman, post the following JSON file to trigger the required integration applications in the Integration
Service user interface to model SL1 devices to ServiceNow:

NOTE: This example only maps VMware device classes to ServiceNow, SL1 devices and a few Cisco
Devices. If the customer environment has other device classes, then you must manually create the
mappings.
{
"name": "device_sync_sciencelogic_to_servicenow",
"params": {
"mappings": {
"cmdb_ci_ip_switch":[
"Cisco Systems | Catalyst 3850-48P",
"Cisco Systems | Nexus 9372PX"
],
"cmdb_ci_linux_server": [
"ScienceLogic, Inc. | EM7 Message Collector",
"ScienceLogic, Inc. | EM7 Customer Portal",
"ScienceLogic, Inc. | EM7 All-In-One",
"ScienceLogic, Inc. | EM7 Integration Server",
3
"ScienceLogic, Inc. | EM7 Admin Portal",
"ScienceLogic, Inc. | EM7 Database",
"ScienceLogic, Inc. | OEM",
"ScienceLogic, Inc. | EM7 Data Collector",
"NET-SNMP | Linux",
"RHEL | Redhat 5.5"
],
"cmdb_ci_esx_resource_pool": ["VMware | Resource Pool"],
"cmdb_ci_esx_server": [
"VMware | ESXi 5.1 w/HR",
"VMware | Host Server",
"VMware | ESX(i) 4.0",
"VMware | ESX(i) w/HR",
"VMware | ESX(i) 4.0 w/HR",
"VMware | ESX(i)",
"VMware | ESX(i) 4.1 w/HR",
"VMware | ESX(i) 4.1",
"VMware | ESXi 5.1",
"VMware | ESXi 5.0"
],
"cmdb_ci_vcenter_datacenter": ["VMware | Datacenter"],
"cmdb_ci_vcenter_datastore": ["VMware | Datastore", "VMware | Datastore
Cluser"],
"cmdb_ci_vcenter_dv_port_group": ["VMware | Distributed Virtual Portgroup"],
"cmdb_ci_vcenter_dvs": ["VMware | Distributed Virtual Switch"],
"cmdb_ci_vcenter_folder": ["VMware | Folder"],
"cmdb_ci_vcenter_network": ["VMware | Network"],
"cmdb_ci_vmware_instance": ["VMware | Virtual Machine"],
"cmdb_ci_vcenter": ["VMware | vCenter", "Virtual Device | Windows Services"],
"cmdb_ci_vcenter_cluster": ["VMware | Cluster"]
},
"configuration": "template_snow_integration" #name your configuration file
}
}

The following image displays an example of using Postman to send the mapping data to Integration Service:
Persistently Saving Device Mappings with the API

You can persistently save device mappings using the API.
1. Use Postman or cURL to do a GET to load the device sync integration application:
GET URL_for_your_Integration_Service _system/api/v1/applications/device_sync_

sciencelogic_to_servicenow
where:
l URL_for_your_Integration_Service _system is the IP address or URL for the Integration Service system.
NOTE: The response should contain the entire JSON output for the integration application.
2. Copy the entire JSON code and save it to a file named: "device_sync_sciencelogic_to_servicenow".

3. Open the new file and locate the object with the "name":"mappings" property in the "app_variables" list.
The "value" property in this object specifies the mappings to use throughout the integrations:
4. Modify the "value" property of the object to use the mappings you want to use.
5. Ensure that the mappings follow the same JSON data structure, otherwise the sync will not work:
{
"cmdb_ci_class": [
"ScienceLogic Dev Class| ScienceLogic subclass",
"Another Silo Dev Class | Another Silo subclass"
]
}
6. After you update the mappings, use the iscli to upload the updated integration application with your new
settings. Type the following command at the command line:
iscli –uaf device_sync_sciencelogic_to_servicenow –H hostname_or_IP_address_of_

integration_service_system -p password
where:
l hostname_or_IP_address_of_integration_service_system is the hostname or IP address of the

Integration Service system.
l password is password you use to log in to the Integration Service system.
Default Device Attribute Mappings

The following table describes the default mappings between SL1 and ServiceNow device attributes:

SL1 attribute ServiceNow attribute
assetTag asset_tag
cat_name category
cpu cpu_count
cpu_make cpu_type
dns_domain dns_domain
function justification
hostname fqdn
memory ram
model model_number
os os
purchase date order_date
serial serial_number
speed cpu_speed
status hardware_substatus
virtual virtual
w_cost cost
w_date_ex warranty_expiration
make manufacturer
a_notes Not synced by default
array_size Not synced by default
disk_count integer Not synced by default
dns_name Not synced by default
fw_ver (str) Not synced by default
hostid Not synced by default
is_snmp Not synced by default
location Not synced by default
owner Not synced by default
purchase order number Not synced by default
rfid Not synced by default

NOTE: The values listed as Not synced by default above are queried from SL1, but those values do not have
default attributes to map to in ServiceNow. As a result, the Integration Service does not sync those
attributes by default. If you want to sync these SL1 attributes, you must specify the ServiceNow
attributes to be synced by using the key/value mappings.
Mapping and Syncing Attributes for Devices

You can sync existing and custom attribute values for devices from ServiceNow to SL1. All custom attributes for
each device are synced automatically.
NOTE: When an attribute value is "0" in SL1, the corresponding field in ServiceNow might display as empty.
3
To map and sync device attributes:
1. In the Integration Service user interface, go to the [Integrations] tab and open the integration application
you are using for device sync. In most cases, this application would be "ScienceLogic To ServiceNow Device
Sync using GraphQL".
2. Click the [Configure] button. The Configuration pane appears.
3. Select the necessary configuration file to align with this application from the Configuration drop-down list.

4. Scroll down to the section for the additional_attributes parameter:
5. To edit an existing attribute, click the attribute name and either select an attribute from the list or type a new
name for the attribute.
TIP: Use the [Tab] button to move down through the list of options in a Mapping dropdown list, press [Shift]+
[Tab] to move up, and press [Enter] to select a highlighted option.
6. To create a custom attribute, click the [Add Mapping] button at the bottom of the section and type a name
for the attribute in the first field, and then select one or more ServiceNow attributes to which the SL1 attribute
should sync in the To ServiceNow Attribute field.
7. To create a custom device class or asset attribute, scroll down to the section for the mappings parameter
and click the [Add] button.
8. Click the down arrow icon to edit a device class or asset attribute in the section for the mappings parameter.
9. Click the [Save] button at the top of the Configuration pane to save your updates.

Adding New Device Attributes to ServiceNow
You can also add one or more new attributes to ServiceNow that you can then sync with SL1.
To add an attribute in ServiceNow:
1. In ServiceNow, search for "Tables" in the filter navigator and select System Definition > Tables.
2. From the Tables page, search for and select the table to which you want to add a field for a new attribute.
3. From the Table page, click the [New] button to add a new field on the table. A new record appears:
4. From the Type drop-down list, select the data type you want to store, such as String. Depending on your
selection, additional required fields display:
NOTE: In the String example, above, Column label contains the text you want to display in ServiceNow, and
Column name is the exact column name used by the Integration Service or the API.
5. Complete the required fields and any other fields as needed, and then click the Submit button. The field is
added to ServiceNow.

Mapping and Syncing SL1 Network Interfaces to ServiceNow
You can map and sync network interfaces in much the same way you sync devices between SL1 and ServiceNow.
To map and sync network interfaces:
1. In the Integration Service user interface, go to the [Integrations] tab and open the "ScienceLogic to
ServiceNow Interface Sync" integration application:

2. Click the [Configure] button to open the Configuration pane:
3. Select the necessary configuration file to align with this application from the Configuration drop-down list.
4. Select the Domain_Separation option if you want to separate data, processes, and administrative tasks into
logical groupings called domains. By default, this option is not selected. For more information, see
Configuring Domain Separation.
5. Select one of the following settings for the adapter_sync parameter:
l off. Disables interface sync.
l all. Syncs every interface, regardless of its state.
l enabled. Syncs only the interfaces that have a state of "admin up". This is the default setting.
6. Click the [Save] button at the top of the Configuration pane to save your updates, and then click the [Run
Now] button to run the integration application.

NOTE: Running the "ScienceLogic to ServiceNow Interface Synch" integration application also runs the
"Cache SL1 Interfaces" integration application.
7. When the application completes, go to ServiceNow and type "cmdb_ci_network_adapter.list". The Network
Adapters page appears, with a list of synced interfaces:
8. Select a network interface from the list and scroll down to the Network Adapters tab to see more
information about the interface, such as the Operational status value, which is synced from SL1.
NOTE: The operational status is different from the SL1 monitored status, but the Integration Service tracks both
values.

Syncing Device Maintenance Schedules
You can perform non-scheduled maintenance of synced devices through change management in ServiceNow.
You can also create a change request to perform scheduled maintenance through a maintenance window in
ServiceNow. Before setting up maintenance sync, you need to map and sync devices between SL1 and Service
Now.
CI Maintenance Sync (non-scheduled) syncs maintenance windows from ServiceNow CHG Tasks to SL1 devices
to place the synced devices into maintenance mode for the scheduled change window.
To set up maintenance sync:
1. In ServiceNow, type "change" in the filter navigator and navigate to Change > Create New.
2. Click [New] to create a new change request of type "Normal". A new CHG record appears:
3
3. In the new CHG record, make a note of the change request number in the Number field. You will use this
later to verify that the maintenance sync was created. In this example, the value is CHG0030004.
4. Update the following fields in the record:
l Configuration Item. Select for the CI you want to configure for maintenance sync.
l Assignment group. Select the group for the CI.

5. Click the [Submit] button. The change request is saved, and you are returned to the Change Requests
page.
6. Select the change request you just created, right-click the State label, and select Show Choice List. The
Choices list displays a list of the configurable choices and values:
NOTE: You need Administrator privileges to access this list.
7. Make a note of the values in the Value and Label fields. These values map to the change_scheduled_
state and change_canceled_state fields in the "Sync Maintenance from ServiceNow to SL1" integration
application.
8. Return to your new change request and scroll down in the change request to the [Affected CIs] tab, where
you can click the [Add] button to add additional synced CIs to the maintenance sync:

9. In the Integration Service user interface, go to the [Integrations] tab and select the "Sync Maintenance from
ServiceNow to SL1" integration application.
10. Click the [Configure] button. The Configuration pane appears:
11. Verify that the value from the change_scheduled_state field matches the value in the Value field from
ServiceNow, and the value from the change_canceled_state field matches value from the Label field from
ServiceNow. These values must match for the maintenance sync to work.
12. Click the [Save] button and then click the [Run Now] button to run the integration application.
13. While the "Sync Maintenance from ServiceNow to SL1" integration application runs, you can monitor the
status of the maintenance process by clicking the branch icon ( ) on the Schedule Maintenance step.
Click the triggered application's run ID in the pop-up window and then click the branch icon on the
Create SL Maintenance or Modify Maintenance steps for more information.
14. After the "Sync Maintenance from ServiceNow to SL1" integration application completes, navigate to the
Schedule Manager (Registry > Schedules > Schedule Manager) in SL1 to view the change requests.

15. Verify that the Schedule Summary field contains the same value from the ServiceNow Number field. In this
example, the value in SL1 matches the value from ServiceNow: CHG0030004.
16. You can also verify that the schedule was created for a device by navigating to the Device Manager
(Registry > Devices), clicking the wrench icon for the device, and clicking the [Schedule] tab.
17. If you want to edit the scheduled time for the maintenance sync, open the change request in ServiceNow,
click the [Schedule] tab, and update the Planned start date and Planned end date fields as needed. The
next time the "Sync Maintenance from ServiceNow to SL1" integration application runs, the schedule is
updated.
18. If you want to cancel the scheduled time for the maintenance sync, open the change request in ServiceNow,
click the Additional actions menu button ( ), and select Cancel Change. The next time the "Sync
Maintenance from ServiceNow to SL1" integration application runs, the application cancels that
maintenance sync.
TIP: As a best practice, schedule the "Sync Maintenance from ServiceNow to SL1" integration application to
run every hour or so, depending on your environment. For more information, see Scheduling
Integration Applications.
Discovery Sync
The Discovery Sync integration lets you use SL1 for discovering and syncing ServiceNow devices. With
Discovery Sync, you start an SL1 discovery session from ServiceNow and then sync the newly discovered SL1
devices or virtual devices and their data with ServiceNow.
Before running a Discovery Sync session, you must complete the following steps first:
1. Perform a company sync by running the "Sync Organizations from SL1 to ServiceNow" integration application
in the Integration Service user interface. For more information, see Mapping and Syncing SL1
Organizations with ServiceNow Companies.
2. In ServiceNow, configure the two different service requests for Discovery Sync. For more information, see
Configuring ServiceNow Service Requests for Discovery Sync.
3. In the Integration Service user interface, run the integration applications listed in Discovery Sync Workflow.
Configuring ServiceNow Service Requests for Discovery Sync

Before you can run a Discovery Sync, you need to configure the catalog and category values in the ServiceNow
service request forms. You also need to activate both types of service requests: "Create Virtual Device" and
"Device Discovery".
NOTE: Because some of the fields in the service request form will only populate if you have completed the
previous fields in the form, you need to complete the fields in the service request form in sequential
order.

To configure the ServiceNow service requests for Discovery Sync:
1. In ServiceNow, search for "Maintain Items" in the filter navigator.

2. Select Service Catalog > Catalog Definitions > Maintain Items. The Catalog Items window appears:
3. Ensure that the Catalog Items list includes a service request for Create Virtual Device and a service
request for Device Discovery.
4. Select the Create Virtual Device service request and ensure that the Catalogs and Category fields are
complete. Add the relevant information if the fields are blank. For example:

NOTE: Do not set the Category to a Change Request.
5. Click the [Update] button to save any updates to the service request.
6. From the Catalog Items window, select the Device Discovery service request and ensure that the
Catalogs and Category fields are complete. Add the relevant information if the fields are blank, and then
click the [Update] button.
7. Click the check boxes for the Create Virtual Device and Device Discovery service requests, and then click
the [Activate] button at the bottom of the Catalog Items window.
NOTE: These two service requests are instance-specific, which means that the service request will appear in
the same location as the catalogs you specified for each request. In the example, above, the Catalog
was set to Service Catalog.
8. Navigate to the relevant catalog for the service requests. For example, if you selected Service Catalog for one
or both requests, then type "Service Catalog" in the filter navigator, or select Self-Service > Service Catalog
to view the new service requests.
9. You can now run the integration applications listed in Discovery Sync Workflow.
Discovery Sync Workflow

To prepare SL1 and ServiceNow for a Discovery Sync, run the following integration applications in the Integration
Service user interface, in the following order:
1. "Pre-Discovery Sync". This application exports information from SL1 to populate the information in the
ServiceNow request form. You must run this application before you can create the discovery sync session.
2. "Process Discovery Session Request". This application sends the request forms to SL1.
3. "Poll Discovery Sessions". This application populates the discovery session logs back to ServiceNow.
4. "ScienceLogic To ServiceNow Device Sync using GraphQL." This application ensures that the devices
discovered by SL1 get synced to ServiceNow.
When the integration applications finish running, the Integration Service sends the status of those applications to
ServiceNow, and you can start the Discovery Sync.
TIP: ScienceLogic recommends that you schedule these integration applications to run at least every 23 hours.
For more information, see Scheduling Integration Applications.
Running a Discovery Sync for a Device

The Discovery Sync process starts an SL1 discovery session from ServiceNow and sync the newly discovered SL1
devices and their data with ServiceNow.

You can run a regular discovery using Discovery Sync, or you can upload a comma-separated value (CSV) file with
the relevant data about the devices you want SL1 to discover.
To run a Discovery Sync for a device:
1. In ServiceNow, navigate to Self-Service > Service Catalog > Services.
2. Click Device Discovery. The Device Discovery page appears:
3. If you are using an attachment for this discovery:
l Select Discovery Session with Attachment from the Discovery Type field.

l Click the attached file link or the Manage Attachments button.

l Attach a CSV file from the relevant location in ServiceNow. Go to step 8 after your file is attached.
NOTE: If you have multiple values in a field in the CSV file, separate the values with a colon (:). IP, Device
Groups, Credentials, and Scan Ports will accept multiple values. For example, for the credential
format, you would use credType:credID.
4. If you are running a regular discovery without an attachment, select Discovery Session from the Discovery
Type field. A number of new fields appear in the Discovery Session pane:
l IP Address/Hostname Discovery List. Provide a list of IP addresses, hostnames, or fully-qualified

domain names for SL1 to scan during discovery:
n One or more single IPv4 addresses separated by commas and a new line. Each IP address
must be in standard IP notation and cannot exceed 15 characters. For example, "10.20.30.1,
10.20.30.2, 10.20."
n One or more ranges of IPv4 addresses with "-" (dash) characters between the beginning of the
range and the end of the range. Separate each range with a comma. For example,
"10.20.30.1 – 10.20.30.254".
n One or more IP address ranges in IPv4 CIDR notation. Separate each item in the list with a
comma. For example, "192.168.168.0/24".
n One or more hostnames (fully-qualified domain names). Separate each item in the list with a
comma.
l Credentials. Select one or more SNMP credentials to allow SL1 to access a device's SNMP data.
l Discover Non-SNMP. Specifies whether or not SL1 should discover devices that don't respond to
SNMP requests.

l Model Devices. Determines whether or not the devices that are discovered with this discovery session
can be managed through SL1.
l DHCP. Specifies whether or not the specified range of IPs and hostnames use DHCP. If you select this
option, SL1 performs a DNS lookup for the device during discovery and each time SL1 retrieves
information from the device.
l Device Model Cache TTL (h). Amount of time, in hours, that SL1 stores information about devices
that are discovered but not modeled, either because the Model Devices option is not enabled or
because SL1 cannot determine whether a duplicate device already exists. The cached data can be
used to manually model the device from the Discovery Session window.
l Collection Server. Select an existing collector to monitor the discovered devices.
l What company is this for?. Specify the company that will use this discovery data. Click the
magnifying glass icon to locate a company.
l Add Devices to Device Groups. Select one or more existing device groups to which you want to add 3
the discovered devices.
l Apply Device Template . Select an existing device template if needed. As SL1 discovers a device in
the IP discovery list, that device is configured with the selected device template.
l Initial Scan Level. For this discovery session only, specifies the data to be gathered during the initial
discovery session.
l Scan Throttle. Specifies the amount of time a discovery process should pause between each
specified IP address (specified in the IP Address/Hostname Discovery List field). Pausing discovery
processes between IP addresses spreads the amount of network traffic generated by discovery over a
longer period of time.
l Scan Default Ports. Select this option to scan the default ports: 21,22,23,25,80. If you de-select this
option, you can specify a different list of ports in the Custom Port Scan field that appears.
l Port Scan All IPs. For the initial discovery session only, specifies whether SL1 should scan all IP
addresses on a device for open ports.
l Port Scan Timeout. For the initial discovery session only, specifies the length of time, in milliseconds,
after which SL1 should stop trying to scan an IP address for open ports and begin scanning the next IP
address (if applicable).
l Interface Inventory Timeout (ms). Specifies the maximum amount of time that the discovery
processes will spend polling a device for the list of interfaces. After the specified time, SL1 will stop
polling the device, will not model the device, and will continue with discovery. The default value is
600,000 ms (10 minutes).
l Maximum Allowed Interfaces. Specifies the maximum number of interfaces per devices. If a device
exceeds this number of interfaces, SL1 stops scanning the device, will not model the device, and will
continue with discovery. The default value is 10,000.
l Bypass Interface Inventory. If you select this option, SL1 will not attempt to discover interfaces for
each device in the discovery session.
6. If you want to run the Discovery Sync immediately, click the [Order Now] button.
7. If you want to create additional Discovery Sync sessions, click the [Add to Cart] button, and you can run all of
the requests in your cart at a later time by clicking the [Proceed to Checkout] button.

NOTE: If you click the link for the discovery item in the cart, you can view the Requested Item (RITM) page,
which contains additional information about the discovery that you might need later.
8. After you submit your request, search for "requests" in the filter navigator and select ScienceLogic Requests.
The ScienceLogic Requests page appears.
9. In the Process column, verify that ServiceNow created a new Discovery_Session_Request record, or
Discovery_Attachement_Session_Request record if you used an attachment with discovery.
10. To view more information about the request, click the name of the request in the Log column. A
ScienceLogic Request page appears.
11. Make a note of the RITM number and the Payload information:
12. In the Integration Service user interface, go to the [Integrations] tab and run the "Process Discovery Session
Requests" integration application.
13. When the application completes, go to the ScienceLogic Requests page in ServiceNow.
14. Refresh the requests table, and in the Process column, verify that ServiceNow created a new virtual_
device_created record.

15. Click the name of the request in the Logs column.
16. Click the RITM record link to go to the Requested Item page.
17. The State field should update to Closed Complete and the request should be assigned to itself.
18. Scroll down to the Activities pane to verify that you have a comment stating the discovery completed.
19. In SL1, navigate to the Discovery Control Panel (Registry > Manage > Discovery) and verify that SL1 created
a new discovery session with that ID.
Running a Discovery Sync for a Virtual Device

To run a Discovery Sync session for a virtual device:
1. In ServiceNow, navigate to Self-Service > Service Catalog > Services.

2. Click Create Virtual Device. The Create Virtual Device page appears:
l Name. Type a name for the virtual device.

l Organization. If needed, specify your organization. In most cases, your organization already appears
in this field.
l Virtual Device Class. Specify the device class of the virtual device. Click the magnifying glass icon to
locate any classes aligned with your organization.
l Collector Group. Specify the SL1 collector group to use for the Discovery Sync. Click the magnifying
glass icon to locate any collector groups aligned with your organization.
4. If you want to run the Discovery Sync immediately, click the [Order Now] button.
5. If you want to create additional Discovery Sync sessions, click the [Add to Cart] button, and you can run all of
the requests in your cart at a later time by clicking the [Proceed to Checkout] button.
NOTE: If you click the link for the discovery item in the cart, you can view the Requested Item (RITM) page
which contains additional information about the discovery that you might need later.

6. After you submit your request, search for "requests" in the filter navigator and select ScienceLogic Requests.
The ScienceLogic Requests page appears.
7. In the Process column, verify that ServiceNow created a new Create_Virtual_Device_Request record.
8. To view more information about the request, click the name of the request in the Log column. A
ScienceLogic Request page appears.
9. Make a note of the RITM number and the Payload information:
10. In the Integration Service user interface, go to the [Integrations] tab and run the "Process Discovery Session
Requests" integration application.
11. When the application completes, go to the ScienceLogic Requests page in ServiceNow .
12. Refresh the requests table, and in the Process column, verify that ServiceNow created a new virtual_
device_created record.
13. Click the name of the request in the Logs column.
14. Click the RITM record link to go to the Requested Item page.

15. The State field should update to Closed Complete and the request should be assigned to itself.
16. Scroll down to the Activities pane to verify that you have a comment stating "Virtual Device <name>
Created with SLID: <new id>":
17. In SL1, navigate to the Device Manager page (Registry > Device Manager) and verify that SL1 created a
new device with that device ID.
Scheduling Integration Applications
Using the Integration Service user interface, you can configure integration applications to run on a schedule
instead of manually running the applications.
As a best practice, you should schedule the following integration applications to run at least every 23 hours:
l "Cache ServiceNow CIs and ScienceLogic Device Classes"

l "ScienceLogic To ServiceNow Device Sync using GraphQL"
You can create one or more schedules for a single integration application in the Integration Service user interface.
When creating the schedule, you can specify the queue and the configuration file for that integration application.

To schedule an integration application:
1. On the [Integrations] tab of the Integration Service user interface, click the [Schedule] button for the
integration application you want to schedule. The initial Schedule window appears, displaying any existing
schedules for that application:
NOTE: If you set up a schedule using a cron expression, the details of that schedule display in a more
readable format in this list. For example, if you set up a cron expression of */4 * * * *, the schedule on
this window includes the cron expression along with an explanation of that expression: "Every 0, 4, 8,
12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, and 56th minute past every hour".

2. Click the + icon to create a schedule. A blank Schedule window appears:
3. In the Schedule window, complete the following fields:
l Schedule Name. Type a name for the schedule.

l Cron expression. Select this option to schedule the integration using a cron expression. If you select
this option, you can create complicated schedules based on minutes, hours, the day of the month, the
month, and the day of the week. As you update the cron expression, theSchedule window displays the
results of the expression in more readable language, such as Expression: "Every 0 and 30th minute
past every hour on the 1 and 31st of every month", based on */30 * * /30 * *.
l Frequency in seconds.Type the number of seconds per interval that you want to run the integration.
l Custom Parameters. Type any JSON parameters you want to use for this schedule, such as
information about a configuration file or mappings.
4. Click [Save Schedule]. The schedule is added to the list of schedules on the initial Schedule window. Also,
on the [Integrations] tab, the word "Scheduled" appears in the Scheduled column for this integration
application, and the [Schedule] button contains a check mark:
NOTE: After you create a schedule, it continues to run until you delete it. Also, you cannot edit an existing
schedule, but you can delete it and create a similar schedule if needed.

To view or delete an existing schedule:
1. On the [Integrations] tab, click the [Schedule] button for the integration application that contains a
schedule you want to delete. The initial Schedule window appears.
2. Click the down arrow icon ( ) to view the details of an existing schedule:
3. To delete the selected schedule, click the [Delete] button. The schedule is removed.
Troubleshooting CMDB Sync
If you can successfully send data to your ServiceNow system, but you encounter issues with creating CIs in the
ServiceNow CMDB, this section provides troubleshooting steps to help you test the payload and identify possible
issues. These steps might be helpful if you have set up datasource precedence rules.
1. In ServiceNow, search for "import" in the filter navigator.

2. Select ScienceLogic > Device > Imports. The Device Import window appears.
3. From the list, select the Device Import log entry you want to view.
4. Copy the data from the Payload field in the log entry and decode the data from its Base64 encoding.
5. In the decoded string of data, remove the square brackets from the first and last line: ("[", "]")

6. Copy this modified JSON payload, and then use the filter navigator to search for "Identification Simulation" or
select Configuration > Identification Simulation.
7. On the Identification Simulation page, click the [Start] button in the Start with Existing Payload section.
The Insert JSON Payload page appears:

8. In the Source field, select ScienceLogic as the data source.
9. In the Please insert payload below field, paste the JSON payload you edited in step 5.
10. Click the [Execute] button and review the payload to identify any potential issues.

Chapter
4
Using SL1 to Monitor ServiceNow
Overview
4
This section describes how to monitor ServiceNow in SL1 using the ServiceNow Base Pack PowerPack.
The following topics describe how to use the ServiceNow Base Pack PowerPack:
What Does the ServiceNow Base Pack PowerPack Monitor? 98

Installing the ServiceNow Base Pack PowerPack 98
Creating a SOAP/XML Credential for ServiceNow 99
Creating a Virtual Device for the ServiceNow Base Pack 102
Aligning the ServiceNow Base Pack Dynamic Applications 103
Viewing the ServiceNow Open Incidents Dashboard 105
NOTE: ScienceLogic provides this documentation for the convenience of ScienceLogic customers. Some of
the configuration information contained herein pertains to third-party vendor software that is subject to
change without notice to ScienceLogic. ScienceLogic makes every attempt to maintain accurate
technical information and cannot be held responsible for defects or changes in third-party vendor
software. There is no written or implied guarantee that information contained herein will work for all
third-party variants. See the End User License Agreement (EULA) for more information.

What Does the ServiceNow Base Pack PowerPack Monitor?
To monitor a ServiceNow instance with SL1, you must install the ServiceNow Base Pack PowerPack. This
PowerPack enables you to model and collect data about ServiceNow Incident and CMDB tables.
The ServiceNow Base Pack PowerPack includes:
l The "ServiceNow: CMDB Configuration" Dynamic Application, which provides data for Integration Service
systems communicating with ServiceNow
l The "ServiceNow: Incident Metrics" Dynamic Application, which collects information about the types,
statuses, and properties of ServiceNow incidents
l A Device Class for ServiceNow instances
l Run Book Policies and a Run Book Action to automate adding, updating, and clearing incidents
l Two sample Credentials: One for connecting to a ServiceNow instance and one for sending event payload
information to the Integration Service, which is required for integration with the ServiceNow Incident
Management Module
l The "ServiceNow Open Incidents" Dashboard, which displays information about ServiceNow incident
statuses and types
l ScienceLogic Libraries that are utilized by this PowerPack:
l content
l content_cache
l silo_core
l silo_core_rest
l silo_credentials
l silo_servicenow
Installing the ServiceNow Base Pack PowerPack

Before completing the steps in this section, you must import and install the latest version of the ServiceNow Base
Pack PowerPack.
NOTE: If you are upgrading from SyncServer, you must disable the old SyncServer Run Book Actions and Run
Book Automation policies before installing the new ServiceNow Base Pack PowerPack.
To install the ServiceNow Base Pack PowerPack:
1. Log in to SL1 as an administrator, then go to the PowerPack Manager page (System > Manage >
PowerPacks).
2. Click the [Actions] button and select Import PowerPack.
3. Click the [Browse] button and navigate to the ServiceNow Base Pack PowerPack file.
98 Using SL1 to Monitor ServiceNow

4. Select the PowerPack file and click [Import]. The PowerPack Installer modal page displays a list of the
PowerPack contents.
5. Click the [Install] button. After the installation is complete, the ServiceNow Base Pack PowerPack appears
on the PowerPack Manager page.
TIP: By default, installing a new version of a PowerPack overwrites all content in that PowerPack that has
already been installed on the target system. You can use the Enable Selective PowerPack Field
Protection setting in the Behavior Settings page (System > Settings > Behavior) to prevent new
PowerPacks from overwriting local changes for some commonly customized fields. For more information,
see the System Administration manual.
Creating a SOAP/XML Credential for ServiceNow

To configure SL1 to monitor a ServiceNow instance, you must first create at least one SOAP/XML credential to
enable the Dynamic Applications in the ServiceNow Base Pack PowerPack to communicate with ServiceNow and
the Integration Service.
The PowerPack includes two sample credentials: 4

l ServiceNow DA - Example. This credential connects the Dynamic Applications in the ServiceNow Base
Pack PowerPack to a ServiceNow instance. This credential lets you monitor the CMDB and Incident tables in
ServiceNow.
l ServiceNow RBA - Example. This credential lets you send event payload data from SL1 to the Integration
Service and then to ServiceNow. Use this credential if you want to integrate with the ServiceNow Incident
Management Module by aligning it with the “ServiceNow: Add/Update/Clear Incident” Run Book Action.

To configure the ServiceNow DA - Example credential:

2. Locate the ServiceNow DA - Example credential and then click its wrench icon ( ). The Edit SOAP/XML
Credential modal page appears:
l Profile Name. Type a name for the ServiceNow Dynamic Applications credential.

l Content Encoding. Select text/xml.
l Method. Select GET.
l URL. Type the URL for your ServiceNow system.
l HTTP Auth User. Type the ServiceNow administrator username.
l HTTP Auth Password. Type the ServiceNow administrator password.
l Timeout (seconds). Type "30".
4. Click the [Save As] button.

To configure the ServiceNow RBA - Example credential:

2. Locate the ServiceNow RBA - Example credential and then click its wrench icon ( ). The Edit SOAP/XML
Credential modal page appears:
l Profile Name. Type a name for the ServiceNow Run Book Action credential.
l Content Encoding. Select text/xml.
l Method. Select POST.
l URL. Type the host name for the Integration Service.
l HTTP Auth User. Type the Integration Service administrator username.
l HTTP Auth Password. Type the Integration Service administrator password.
l Timeout (seconds). Type "5".
4. Click the [Save As] button.

5. Next, align this credential with the “ServiceNow: Add/Update/Clear Incident” Run Book Action by navigating
to the Run Book Actions page (Registry > Run Book > Actions).
6. Click the wrench icon ( ) for the “ServiceNow: Add/Update/Clear Incident” Run Book Action. The Action
Editor modal page appears:

7. In the Snippet Credential drop-down list, select the name of the credential you created in steps 1-4.
8. Click [Save].
Creating a Virtual Device for the ServiceNow Base Pack

To monitor ServiceNow, you must create a virtual device that represents the root device for ServiceNow. You can
use the virtual device to store information gathered by policies or Dynamic Applications.

To create a virtual device that represents your ServiceNow instance:
1. Go to the Device Manager page (Registry > Devices > Device Manager).
2. Click the [Actions] button and select Create Virtual Device from the menu. The Virtual Device modal page
appears:

4
l Device Name. Type a name for the device.
l Organization. Select the organization for this device. The organization you associate with the device
limits the users that will be able to view and edit the device. Typically, only members of the
organization will be able to view and edit the device.
l Device Class. Select ServiceNow | Instance.
l Collector. Select the collector group that will monitor the device.
4. Click the [Add] button to create the virtual device.
Aligning the ServiceNow Base Pack Dynamic Applications

Before you can run the Dynamic Applications in the ServiceNow Base Pack, you must manually align each
Dynamic Application to the virtual device you created in the previous step. When you align the Dynamic
Applications, you should use the ServiceNow credential that you created from the ServiceNow DA - Example
credential.
To align the ServiceNow Base Pack Dynamic Applications with the ServiceNow virtual device:
1. Go to the Device Manager page (Registry > Devices > Device Manager).
2. Click the wrench icon ( ) for the virtual device you created in the previous section. The Device Properties
page appears.
3. Click the [Collections] tab. The Dynamic Application Collections page appears.

4. Click the [Actions] button and select Add Dynamic Application. The Dynamic Application Alignment
modal page appears:
5. In the Dynamic Applications field, select the first of the ServiceNow Dynamic Applications.
6. In the Credentials field, select the credential you created based on the ServiceNow DA - Example
credential.
7. Click the [Save] button.
8. Repeat steps 4-7 for each remaining Dynamic Application.

Viewing the ServiceNow Open Incidents Dashboard
The ServiceNow Open Incidents system dashboard displays the following information:
l Open incidents by state

l Open incidents by priority
l Unassigned incidents
l High priority incidents
l Critical priority incidents
l Assigned incidents
l Active incidents
l Resolved incidents
l Incidents unassigned or assigned by percentage
l Incidents source by percentage
l Total open incidents

Appendix A
A
Integration Service API Endpoint Usage
Overview
This appendix describes the Integration Service's API Endpoint Usage in ServiceNow on an application-by-
application basis.
This appendix includes the following topics:
Incident Sync 107

Fields 107
Transforms 108
Device Sync, Interface Sync 109
Fields 109
Transforms 111
Discovery Sync 111
Fields 111
Transforms 112
Company / Manufacturer / Hardware Model Sync 112
Fields 112
Transforms 113
Hardware Model Sync 114
Fields 114
Transforms 115

Incident Sync
Triggered by SL1 Events, transforms data to post to ServiceNow.
Table Action Transform Map Business Rule
u_imp_silo_incidents Post ScienceLogic incident, Set synchronous import set, Transform

ScienceLogic Event synchronously
incident Get N/A N/A
Fields
u_i m p _si l o_i nci d ents
Event Import Table.
l u_last_detected
l u_sciencelogic_link
l u_incident_state
l u_short_description
l u_sciencelogic_automation_policy
l u_sciencelogic_action_policy
l u_subcategory
l u_event_created
l u_sciencelogic_user_ack
l u_sciencelogic_event_policy
l u_sciencelogic_region
l u_description
l u_sciencelogic_event_id
l u_sciencelogic_event_count
l u_event_severity
l u_company
l u_assignment_group
l u_cmdb_ci
l u_affected_cis
i nci d ent
Full incident record for created incident.
107 Integration Service API Endpoint Usage

Transforms
Sci enceL og i c Inci d ent

A
Source Table: u_imp_silo_incidents
Target Table: incident
Source field Target Field Coalesce Referenced Value Field Name
u_active active TRUE
u_assignment_group assignment_group FALSE
sys_updated_by caller_id FALSE user_name
u_cmdb_ci cmdb_ci FALSE
[Script] company FALSE
u_contact_type contact_type FALSE
u_correlation_id correlation_id TRUE
u_impact impact FALSE
[Script] location FALSE
u_short_description short_description FALSE
u_urgency urgency FALSE
u_work_notes work_notes FALSE
Sci enceL og i c Event
Source Table: u_imp_silo_incidents

Target Table: u_silo_events
Source field Target Field Coalesce
u_sciencelogic_action_policy u_action_policy FALSE
[Script] u_active FALSE
u_sciencelogic_automation_policy u_automation_policy FALSE
u_correlation_id u_correlation FALSE
u_cmdb_ci u_device FALSE
u_sciencelogic_event_count u_event_count FALSE

u_event_created u_event_created FALSE
u_sciencelogic_event_id u_event_id TRUE
u_sciencelogic_link u_event_link FALSE
u_short_description u_event_message FALSE
u_sciencelogic_event_policy u_event_policy FALSE
u_last_detected u_last_detected FALSE
u_company u_organization FALSE
u_sciencelogic_region u_region TRUE
u_event_severity u_severity FALSE
u_task u_silo_task TRUE
Device Sync, Interface Sync

Scheduled in the Integration Service. Syncs Devices and Interfaces from SL1 to ServiceNow.
u_imp_silo_device Post N/A IdentificationEngine, CMDBGroupAPI-

CIListFunction
u_silo_relationship Get N/A N/A
cmdb_ci Get N/A N/A
cmdb_ci_network_adapter Get N/A N/A
Fields
u_i m p _si l o_d evi ce
Device / Interface import table.
l u_payload
u_si l o_rel a ti onshi p
CI relationship mapping.
l u_type
l u_child_type.u_class

l u_parent_type.u_class
l u_parent_type.u_criterion_attributes
u_parent_type.u_independent
l
A
l u_parent_type.u_parent_class
l u_relation_type
l u_is_reverse
cm d b _ci
l discovery_source
l name
l u_sciencelogic_status
l sys_id
l u_sciencelogic_id
l ip_address
l u_sciencelogic_correlation
l operational_status
l subcategory
l sys_class_name
l company
l comments
l category
l u_sciencelogic_url
cm d b _ci _network_a d a p ter
l sys_id
l name
l ip_address
l alias
l netmask
l company
l short_description
l mac_address
l operational_status

l cmdb_ci
l u_sciencelogic_id
l u_sciencelogic_url
l u_silo_monitored
Transforms
Not required.
Discovery Sync
Scheduled in the Integration Service. Integration applications are required to run Discovery Sessions.
l Collector Groups
l Collectors
l Credentials
l Discovery Session Requests
l Device Templates
l Device Groups
l Virtual Device Classes
l Virtual Device Create Requests
u_silo_request Get / Post N/A Catalog Request (updates), CMDB Group - Create,
Collector Group Synchronize, Collector
Synchronize, Configuration Item Group (Create),
Configuration Item Group (Update), Credential
Synchronize, Device Template Synchronize, Virtual
Device Class Synchronize
cmdb_group Get N/A N/A
Fields
u_si l o_req uest
l u_payload
l u_process
l u_active

cm d b _g roup
l sys_id
l sys_domain A
l sys_domain_path
l group_name
l description
l group_type
Transforms
Not required.
Company / Manufacturer / Hardware Model Sync

Scheduled in the Integration Service. Integration applications are required to sync Companies and Manufacturers.
core_company Get N/A N/A
u_imp_silo_org_ven_mfg Post ScienceLogic Set synchronous import set, Transform

Company Import synchronously
Fields
core_com p a ny
Core Company Table
l name
l street
l vendor
l city
l latitude
l manufacturer
l sys_id
l u_sciencelogic_id
l u_silo_monitored

l zip
l longitude
l fax_phone
l phone
l state
u_i m p _si l o_org _ven_m fg
Table used to import Organizations, Vendors, and Manufacturers.
l u_zip
l u_vendor
l u_state
l u_sciencelogic_id
l u_phone
l u_manufacture
l u_longitude
l u_latitude
l u_fax
l u_crm_id
l u_city
l u_address
l u_name
Transforms
Sci enceL og i c Com p a ny i m p ort
Source Table: u_imp_silo_org_ven_mfg
Target Table: core_company.
Source field Target Field Coalesce
u_city city FALSE
u_fax fax_phone FALSE
u_latitude latitude FALSE

u_longitude longitude FALSE
u_manufacture manufacturer FALSE
u_name name FALSE A

u_notes notes FALSE
u_phone phone FALSE
u_state state FALSE
u_address street FALSE
u_crm_id sys_id TRUE
u_sciencelogic_id u_sciencelogic_id FALSE
u_sciencelogic_region u_sciencelogic_region FALSE
[Script] u_silo_monitored FALSE
u_vendor vendor FALSE
u_zip zip FALSE
Hardware Model Sync

Scheduled in the Integration Service. An integration application is required to sync Hardware Models.
cmdb_hardware_product_ Get N/A N/A

model
u_imp_silo_model Post Hardware Model Set synchronous import set, Transform

Import synchronously
Fields
cm d b _ha rd wa re_p rod uct_m od el
Hardware Product Models.
l manufacturer
l name
u_i m p _si l o_m od el
Import table for Hardware Models.

l u_name
l u_manufacturer
l u_model_type
Transforms
Ha rd wa re Mod el i m p ort
Source Table: u_imp_silo_model
Target Table: cmdb_hardware_product_model
Source field Target Field Coalesce Referenced Value Field Name
u_silo_monitored u_silo_monitored FALSE
u_manufacturer manufacturer TRUE name
u_name name TRUE

© 2003 - 2018, ScienceLogic, Inc.
All rights reserved.
LIMITATION OF LIABILITY AND GENERAL DISCLAIMER
ALL INFORMATION AVAILABLE IN THIS GUIDE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED. SCIENCELOGIC™ AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT.
Although ScienceLogic™ has attempted to provide accurate information on this Site, information on this Site
may contain inadvertent technical inaccuracies or typographical errors, and ScienceLogic™ assumes no
responsibility for the accuracy of the information. Information may be changed or updated without notice.
ScienceLogic™ may also make improvements and / or changes in the products or services described in this
Site at any time without notice.
Copyrights and Trademarks

ScienceLogic, the ScienceLogic logo, and EM7 are trademarks of ScienceLogic, Inc. in the United States,
other countries, or both.
Below is a list of trademarks and service marks that should be credited to ScienceLogic, Inc. The ® and ™
symbols reflect the trademark registration status in the U.S. Patent and Trademark Office and may not be
appropriate for materials to be distributed outside the United States.
l ScienceLogic™
l EM7™ and em7™
l Simplify IT™
l Dynamic Application™
l Relational Infrastructure Management™
The absence of a product or service name, slogan or logo from this list does not constitute a waiver of
ScienceLogic’s trademark or other intellectual property rights concerning that name, slogan, or logo.
Please note that laws concerning use of trademarks or product names vary by country. Always consult a
local attorney for additional guidance.
Other
If any provision of this agreement shall be unlawful, void, or for any reason unenforceable, then that
provision shall be deemed severable from this agreement and shall not affect the validity and enforceability
of any remaining provisions. This is the entire agreement between the parties relating to the matters
contained herein.
In the U.S. and other jurisdictions, trademark owners have a duty to police the use of their marks. Therefore,
if you become aware of any improper use of ScienceLogic Trademarks, including infringement or
counterfeiting by third parties, report them to Science Logic’s legal department immediately. Report as much
detail as possible about the misuse, including the name of the party, contact information, and copies or
photographs of the potential misuse to: legal@sciencelogic.com
800-SCI-LOGIC (1-800-724-5644)
International: +1-703-354-1010

Sciencelogic Integration Service Servicenow 1-8-0

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sciencelogic Integration Service Servicenow 1-8-0

Hochgeladen von

Copyright:

Verfügbare Formate

Integration Service: ServiceNow

This chapter covers the following topics:

Incident Sync Solution Prerequisites 4

Introduction to ServiceNow Integration 3

l SL1 version 8.7.0 or later

l ScienceLogic root SSH access

Finally, you must perform the following steps:

4 Introduction to ServiceNow Integration

l SL1 version 8.7.0 or later

l ScienceLogic root SSH access

Finally, you must perform the following steps in ServiceNow:

Introduction to ServiceNow Integration 5

Integration Applications Included in the ServiceNow

ServiceNow Default Integration Applications

6 Introduction to ServiceNow Integration

l Sync Collector Groups from SL1 to ServiceNow

Introduction to ServiceNow Integration 7

Internal Integration Applications

8 Introduction to ServiceNow Integration

PowerPacks for Monitoring Elements of the Integration Service

Introduction to ServiceNow Integration 9

10 Introduction to ServiceNow Integration

/flower/api/tasks. Retrieve a list of all tasks.

/flower/api/tasks?app_id={app_id}. Retrieve a list of tasks filtered by app_id.

/flower/api/tasks?app_name={app_name}. Retrieve a list of tasks filtered by app_name.

/flower/api/tasks?started_start=1539808543&started_end=1539808544. Retrieve a list of all tasks

/flower/api/tasks?state=FAILURE|SUCCESS. Retrieve a list of tasks filtered by state.

/flower/api/workers. Retrieve a list of all queues and workers

To view this information in the Flower user interface navigate to <hostname_of_integration_service_

For more information, see the Flower API Reference.

<hostname_of_integration_service_system>:8091/pools/default. Retrieve a list of pools and nodes.

<hostname_of_integration_service_system>:8091/pools/default/buckets. Retrieve a list of buckets.

To view this information in the Couchbase Administrator user interface, navigate to <hostname_of_

For more information, see the Couchbase API Reference.

Introduction to ServiceNow Integration 11

Docker Sta ti sti cs

To collect Docker statistics:

1. Use SSH to connect to the Integration Service instance.

curl --unix-socket /var/run/docker.sock http://docker<PATH>

where <PATH> is one of the following values:

Integration Service Log Files

To access Docker log files:

1. Use SSH to connect to the Integration Service instance.

12 Introduction to ServiceNow Integration

docker service logs -f <service_name> 1

To access local file system logs:

1. Use SSH to connect to the Integration Service instance.

Und ersta nd i ng the Contents of L og Fi l es

You can parse this data in the following manner:

'YYYY-MM-DD' 'HH-MM-SS,ss' 'log-level' 'process_id' 'is_app_name' 'file' 'lineOfCode'

"stop Query and Cache ServiceNow CIs|41.4114570618"

Use regex to parse the string above:

l Everything after the | is the time taken for execution.

Introduction to ServiceNow Integration 13

Incident Sync Integration

This chapter covers the following topics:

Installing the ScienceLogic Update Set in ServiceNow 15

Incident Sync Integration 14

Installing the ScienceLogic Update Set in ServiceNow

To install the ScienceLogic Update Set in ServiceNow:

15 Incident Sync Integration

Incident Sync Integration 16

To install the ServiceNow Base Pack PowerPack:

17 Incident Sync Integration