Configuring ServiceNow Base Pack Monitoring

This section describes how to configure ServiceNow for monitoring by SL1 using the "ServiceNow Base Pack" PowerPack.

Use the following menu options to navigate the SL1 user interface:

To view a pop-out list of menu options, click the menu icon ().
To view a page containing all of the menu options, click the Advanced menu icon ().

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 PowerFlow.

The PowerPack includes two sample credentials:

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.
ServiceNow RBA - Example. This credential lets you send event payload data from SL1 to PowerFlow and then to ServiceNow. Use this credential to integrate with the Incident, Events, or Cases SyncPacks by aligning this credential with the relevant "ServiceNow: Add/Update/Clear (Incident, Event, or Case)" run book action.

To configure the ServiceNow DA - Example credential:

In SL1, go to the Credential Management page (System > Manage > Credentials).
Locate the ServiceNow DA - Example credential and then click its wrench icon (). The Edit SOAP/XML Credential page appears.
Complete the following fields:

Profile Name. Type a name for the ServiceNow Dynamic Applications credential.
Content Encoding. Select text/xml.
Method. Select GET.
HTTP Version. Select HTTP/1.1.
URL. Type the URL for your ServiceNow system.
HTTP Auth User. Use the same username used in PowerFlow for connecting to ServiceNow. This is the same user used in the ServiceNow Guided Setup workflow or detailed in the specific PowerFlow application configuration.
HTTP Auth Password. Use the same password used in PowerFlow for connecting to ServiceNow.
Timeout (seconds). Type "30".

Click the Save As button.

To configure the ServiceNow RBA - Example credential to use with the "ServiceNow: Add/Update/Clear (Incident, Event, or Case)" run book action:

Go to the Credential Management page (System > Manage > Credentials).
Locate the ServiceNow RBA - Example credential and then click its wrench icon (). The Edit SOAP/XML Credential page appears.
Complete the following fields:

Profile Name. Type a name for the ServiceNow run book action credential.
Content Encoding. Select text/xml.
Method. Select POST.
HTTP Version. Select HTTP/1.1.
URL. Type the host name for PowerFlow.
HTTP Auth User. Use the same username used in PowerFlow for connecting to ServiceNow. This is the same user used in the ServiceNow Guided Setup workflow or detailed in the specific PowerFlow application configuration.
HTTP Auth Password. Use the same password used in PowerFlow for connecting to ServiceNow.
Timeout (seconds). Type "5".

Click Save As.
When the confirmation message appears, click OK.
On the Credential Management page (System > Manage > Credentials), make a note of the value in the ID column for the credential you just created:

You will use this value with the sl1_credential_id parameter when you enable and customize the snippet code of the "ServiceNow: Add/Update/Clear (Incident, Event, or Case)" run book action policy.

The following image shows the Action Editor page for the "ServiceNow: Add/Update/Clear Incident" run book action policy:

Enabling the Run Book Automation Policies

Versions 104 and later of the "ServiceNow Base Pack" PowerPack separated these run book action policies by Cases, Events, and Incident, such as "ServiceNow: [Incidents] - Add/Update".

Before you can run the "ServiceNow: Add/Update/Clear" run book action, you must enable the incident specific run book automation policies in SL1:

ServiceNow: [Incident] - Add/Update
ServiceNow: [Incident] - Event Acknowledged
ServiceNow: [Incident] - Event Cleared

Version 106 and later of the "ServiceNow Base Pack" PowerPack aligned all default Incident Automation policies with the new "ServiceNow: Send to PowerFlow" action type. If you have upgraded to the "ServiceNow Base Pack" PowerPack version 106 or later, but not the "ServiceNow Incident" SyncPack version 4.0.0 or later, you will need to update those default automation policies to align with the older action type. If you made copies of the automation policies, you will not need to update them.

To enable the three ServiceNow run book automation policies:

In SL1, go to the Automation Policy Manager page (Registry > Run Book > Automation).

Locate the "ServiceNow: [Incident] - Add/Update" automation policy and click its wrench icon (). The Automation Policy Editor page appears.

Update the following fields:

Policy State. Select Enabled.
Policy Priority. Select High to ensure that this PowerFlow automation policy is added to the top of the queue.
Available Actions. If it is not already selected, select the corresponding ServiceNow run book action policy. Filter the Available Actions section by typing "ServiceNow" in the search field.

By default, the "ServiceNow: [Incidents] Add/Update" 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.

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.

Click Save.
Repeat steps 2-4 for the "ServiceNow: [Incident] - Event Acknowledged" and "ServiceNow: [Incident] - Event Cleared" run book automation policies.

Enabling and Customizing the Run Book Action Policy

The "ServiceNow: Add/Update/Clear Incident" run book action policy contains snippet code that you can customize to use with the "ServiceNow Incident" SyncPack.

You can edit these values in the Input Parameters pane of the Actions page for this policy.

Make sure you are using the most recent version of the run book action policy. If there are two policies with the same name, always use the policy with the higher number in the ID column of the Actions page.

To enable and customize the Incident run book action policy:

In SL1, go to the Actions page (Registry > Run Book > Actions).
Locate the "ServiceNow: Add/Update/Clear Incident" policy and click its wrench icon (). The Action Policy Editor page appears:

For the Action State filed select Enabled.
For the sl1_credential_id field in the Input Parameters pane, specify the credential ID form the ID column on the Credential Management page (System > Manage > Credentials). For example: "sl1_credential_id": "107"
Edit the snippet code as necessary, using the information in the Customizing the Snippet Code in the Input Parameters Pane section, below.
When you are finished, click Save.

Customizing the Snippet Code in the Input Parameters Pane

SL1 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. True and False options are case-sensitive and must not contain quotes.

You can customize the following values in the "ServiceNow: Add/Update/Clear Event" run book action snippet code:

sl1_credential_id. Specifies the ID of the credential object. You can find this value in the ID column of the Credentials page (System > Manage > Credentials of SL1. For example: "sl1_credential_id": "101"
debug. A true/false value that determines if the action is logged in SL1 and if the application is run in Debug Mode on PowerFlow. Troubleshooting logs are written to /data/tmp/servicenow_rba.log.
configuration. Specifies the ID of the configuration object used on PowerFlow. The configuration ID is all lower-case, with spaces in the configuration object "friendly" name replaced by underscores. For example: "configuration": "docs_configs".

NOTE: To find the configuration ID with the PowerFlow API, make a GET request on this endpoint: https://<PowerFlow_service_hostname>/api/v1/configurations.

queue. Specifies the worker queue on which the application runs. Leave this as default.
discard_if_no_ci. Deprecated. Previous versions let you specify whether PowerFlow should create cases, events, or incidents in ServiceNow for devices that do not have a matching CI record.
cmdb_integration. Specifies which CMDB SyncPack you are using to ensure that PowerFlow sends the correct identifiers to ServiceNow.
- If you are using the "ServiceNow CMDB" SyncPack version 3.5.0 or later, use "SGC" to allow CIs to attach to incidents. For example: "cmdb_integration":"SGC"
- If you are using versions of the "ServiceNow CMDB" SyncPack before version 3.5.0, use "CMDB".
- If you are using the "ServiceNow Service Graph Connector" SyncPack, use "SGC".
integration. Specifies the SyncPack you are using for this run book action. For example: "integration": "events".
events_mid_server. Set this field to true if you are using a ServiceNow MID Server with the Event Sync, or set it to false if you are not using a MID Server.
message_key_template. This field lets you customize the message key used by PowerFlow to correlate SL1 events with ServiceNow alerts. This field is used with the Event Sync.

By default the value is "{{'{}'.format(event.event_id)}}", which creates a ServiceNow alert for each SL1 event; this is the existing MID Server flow behavior.
A suggested alternative value is "{{'{}+EVENT+{}'.format(event.node_id,event.event_policy_id)}}", which groups the events by parent entity, such as device or interface, and event policy ID. The SL1 region used in the aligned configuration object in PowerFlow will be prepended to this value to ensure it is unique across stacks.

If you are using the MID Server and you use the message_key_template field to configure a message key with a one-to-many correlation between a single ServiceNow alert and multiple SL1 events, you should schedule the "Sync Alert Details from ServiceNow to SL1 Events" PowerFlow application to run, with the events_mid_server parameter selected on the Configuration pane for the "Sync Alert Details" application. These settings ensure that the ext_ticket_ref is populated when the ServiceNow alert re-opens. If you are using a message key with a one-to-one relationship between alerts and events, you do not need to schedule the "Sync Alert Details from ServiceNow to SL1 Events" application.

Customizing Logging in the Run Book Action

You can customize the following logging-related items in the "ServiceNow: Add/Update/Clear Event" run book action snippet code:

logfile = /data/tmp/ServiceNow_add_update_clear_incident.log

Location for logging output.
Will be created if it does not exist.
Will be appended with each Run Book job.
Is case-sensitive.

do_debug_logging = True

True is on, False is off.
Is case-sensitive.
For troubleshooting, these can be enabled or changed.
Writes logs to /data/tmp/servicenow_rba.log.

Sending Custom Data to ServiceNow Using the Passthrough Option

You can use the "ServiceNow: [(Cases/Events/Incidents)] Add/Update" run book automation and the "ServiceNow: Add/Update/Clear (Case/Event/Incident)" run book action to "pass through" custom data about SL1 cases, events, or incidents to ServiceNow (depending on the SyncPack you are using with PowerFlow).

For example, you might want to use the passthrough functionality to overwrite the impact and urgency of a ServiceNow incident, which is the only way to change the priority of the incident.

To pass custom data to ServiceNow:

Create a new run book action that pulls the relevant data and adds it to a dictionary called EM7_RESULT.
Add the new run book action to the "ServiceNow: [(Cases, Events, or Incident)] Add/Update " run book automation Policy, ahead of the "ServiceNow: Add/Update/Clear (Case/Event/Incident)" run book action so that the new action runs first, and then is consumed by the ServiceNow action.

Passing Custom Data to ServiceNow

The following procedure describes how to configure the passthrough functionality, using the "ServiceNow: [Incident] Add/Update" run book automation and the "ServiceNow: Add/Update/Clear Incident" run book action as examples.

To pass custom data to ServiceNow:

In SL1, go to the Actions page (Registry > Run Book > Actions) and click Create to create a new run book action policy.
Complete the following fields:

Action Name. Type a unique name for the action.
Action State. Select Enabled.
Action Type. Select Run a Snippet.
Execution Environment. Select ServiceNow Base Pack.
Complete the other fields as needed, or leave them at their default settings.

In the Snippet Code pane, add the snippet code you want to include for the EM7_RESULT dictionary. For example, the following snippet code lets you override the ServiceNow Incident work notes with a hardcoded note:

EM7_RESULT = {"work_notes": "This is a new note"}

Additional notes about the structure of the EM7_RESULT dictionary:

EM7_RESULT = is required for the dictionary, and the formatting of the keys should match the example above.
All keys defined in the EM7_RESULT dictionary need to map to field IDs on the ScienceLogic Events table in ServiceNow.
You can hard-code the values in the EM7_RESULT dictionary, or you can use variables and functions, like the "Snippet Code Example", below.
As a best practice, avoid sending null passthrough values to ServiceNow. If you must send 'null' or 'NULL' values to ServiceNow, pass through that value as an empty string, such as "location":"". Also, only pass through values that you need. For example, instead of sending {"location": "", "work_notes": "stuff"}, simply send {"work_notes": "stuff"}.
A long snippet might delay the ticket being created

Click Save.
Go to the Automation Policy Manager page (Registry > Run Book > Automation) and open the "ServiceNow: Add/Update Incident" run book automation Policy.

In the Available Actions section, add the new run book action before the "ServiceNow: Create, Update, Clear Incident" run book action:

The output of this new run book action will be consumed by the "ServiceNow: Create, Update, Clear Incident" run book action, ensuring that the EM7_RESULT dictionary is passed through to ServiceNow. The "ServiceNow: Create, Update, Clear Incident" run book action automatically populates the passthrough values with any values from EM7_LAST_RESULT. The passthrough overwrites any other previously defined fields, such as assignment group.

You can add additional run book actions to the run book automation Policy for any additional workflows that you might want to run. The Automation Policy execute these Actions in a sequential, top-down order. However, the "ServiceNow: Create, Update, Clear Incident" run book action only consumes the EM7_RESULT dictionary from the run book action directly above it.

Passthrough Example

For the Dictionary Entry of the ServiceNow field on the import table, you can reference the XML of the record. You will need to copy the <sys_name> value so you can use that as the key for the passthrough.

In this example, you want to bring in an additional field called sl1 category.

Create the new sl1 category field on the import table in ServiceNow. You can right-click on the header of the form to view the XML:
Look for the <sys_name> value.
Copy that value directly out and use that in your EM7_RESULT for the passthrough value (in the Snippet Code pane):

EM7_RESULT = {'sl1 Category': 'test'}

Snippet Code Example

The following snippet code example shows how to pull additional information and make it available for passthrough. All of the additional information that is going to be sent is contained in a dictionary variable called EM7_RESULT. You can pass through multiple items through in a single run book action by adding additional keys to the EM7_RESULT dictionary.

This example lets you assign assignment groups to an Incident based on certain criteria, such as event policy IDs:

from future.utils import iteritems

def invert_mappings(mappings):
    """
    Invert received one-to-many mappings and converts it into a one-to-one
    mapping.

    Args:
        mappings (dict): Dictionary of mapped values

    Returns:
        dict: inverted dictionary.

    """
    inverted_mappings = dict()
    for key, values in iteritems(mappings):
        for sub_value in values:
            invert_mappings[sub_value] = key
    return inverted_mappings


# Example of assignment group to list of event policy ids mapping.
assignment_groups_to_event_policies = {
    "sys_id_1": [1, 2, 3, 4, 5],
    "sys_id_2": [6, 7, 8, 9, 10],
}
# which sys_id to use if the current event_policy_id isn't mapped
default_sys_id = "sys_id_3"

# invert the mappings
event_policy_to_assignment_group = invert_mappings(assignment_groups_to_event_policies)

# Send assignment group sys_id to IS RBA
EM7_RESULT = {
    "assignment_group": event_policy_to_assignment_group.get(
        EM7_VALUES["%3"], default_sys_id
    )
}

Configuring the "ServiceNow: Click to Create" Automation Policy

The "ServiceNow: [(Cases/Events/Incident)] - Click to Create" automation policy lets you manually create a case, event, or incident in ServiceNow by clicking the Actions button () in SL1 for an event and selecting "Create External Ticket" (or by clicking the life-preserver icon () for an event in the classic user interface).

This run book action policy is available in the "ServiceNow Base Pack" PowerPack.

To configure the "ServiceNow: Click to Create" run book action policy:

In SL1, go to the Behavior Settings page (System > Settings > Behavior) and set the Event Console Ticket Life Ring Button Behavior option to Create/View External Ticket.
Click Save to save your changes. You might need to log out of SL1 and log back into SL1 for the changes to update.
Go to the Automation page (Registry > Run Book > Automation).
Locate the "ServiceNow: (Cases/Events/Incident) - Click to Create" policy and click its wrench icon (). The Automation Policy Editor page appears:
Update the following fields:

Policy State. Select Enabled.
In the Criteria Logic section, select and external ticket IS requested in the fifth drop-down. Leave the other values in this section at their default settings.
Repeat Time. Specify the frequency at which SL1 should execute the automation policy while the conditions are still met. The choices range from "every 30 seconds until satisfied" to "every 2 hours until satisfied", or "only once". By default, the policy only runs once.
Available Actions. If it is not already selected, select ServiceNow: Send to PowerFlow: ServiceNow: Add/Update/Clear Incident and add it to the Aligned Actions field.

Click Save. The "Click to Create" feature is now available on the Events and Event Investigator pages.

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:

Go to the Device Manager page (Devices > Device Manager or Devices > Classic Devices, or Registry > Devices > Device Manager in the classic SL1 user interface for the classic user interface).
Click the Actions button and select Create Virtual Device from the menu. The Virtual Device modal page appears.
Complete the following fields:

Device Name. Type a name for the device.
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.
Device Class. Select ServiceNow | Instance.
Collector. Select the collector group that will monitor the device.

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:

Go to the Device Manager page (Devices > Device Manager or Devices > Classic Devices, or Registry > Devices > Device Manager in the classic SL1 user interface for the classic user interface).
Click the wrench icon () for the virtual device you created in the previous section. The Device Properties page appears.
Click the Collections tab. The Dynamic Application Collections page appears.
Click the Actions button and select Add Dynamic Application. The Dynamic Application Alignment modal page appears.
In the Dynamic Applications field, select the first of the three ServiceNow Dynamic Applications.
In the Credentials field, select the credential you created based on the ServiceNow DA - Example credential.
Click the Save button.
Repeat steps 4-7 for each remaining Dynamic Application.