It is possible to integrate with ServiceNow as a ticketing system, including support for form templates.

This will allow you to not only approve/decline remediation plans and tasks such as agent deployment but with using form templates, it can be ensured that the change can be sent to the correct parties with all required information.

Please Note: a user that has REST capabilities, and is allowed to Open, Read and Change (Write) to tickets is required for ITSM integration.

High-Level Overview

There are 3 ways for integrating JetPatch with ServiceNow:

1. Out-of-the-box - JetPatch Integration capabilities out-of-the-box without special customization and modification.
2. Dedicated ServiceNow interface - Create a custom Interface in ServiceNow to handle JetPatch requests.
3. Custom Integration - contact your Account Manager for more information.

Service Now Components:

• Dedicated System Application
• Dedicated System Web Service
  • Upload Table - Same fields as Change Request table (transform table)
• Change Request table

Architectures

Out of the box (default ServiceNow configuration):

Dedicated ServiceNow interface (custom interface):

*Check Change details - There are other ways of getting the status of the Change details. For more information check "Polling Approval Flow" in ITSM High-Level Overview

Default Change Request Information

The following fields will be reflected in Change Request in ServiceNow:

Additional information

Out-of-the-box Configuration

Note1 - The following steps are relevant only for Out-of-the-box integration

Note2: A ServiceNow user that has REST capabilities, and is allowed to Open, Read and Change (Write) to tickets is required for ITSM integration.

Step 1: JetPatch Integration App in ServiceNow

In order to open automatic tickets for in ServiceNow we need to create a dedicated Integration app in ServiceNow backend

STEP 1.1: Creating System Application

1. In serviceNow server, Go to Home → Create and Deploy → System Application → Create Application → Start from scratch (create button on the right):
   1. Name = JetPatch integration
   2. Scope = the default that provided after filling the Name filed
2. Click on Create button (you don't need to enter to Edit App after that)

If The creation does not succeed because of "could not be registered in the AppRepo for this reason: Scope is not available" - change the application name and try again (link)

STEP 1.2: Creating System Web Service

1. In the left search box (top of the menu) search for "Web".
2. Under "System Web Services" → "Inbound", click on Create New:
   1. Application = if it's different from "JetPatch integration", click on the wheel in the top right of the page (right to Logout) → Application → choose Intigua Integration
   2. Label = Jetpatch Integration
   3. Copy fields from target table = mark as V
   4. Target table = search for "change Request [change_request]"
3. Click on Create button
4. In order to work with our app, we need to create a "Transform Map" between our table to the Change Request table. Click on the "Auto Map Matching Fields" at the bottom of the page, after "Related Links"
5. Click on the "Update" button

STEP 1.3: Validate Intigua Server Configuration

1. In ServiceNow backend, search again for System Web Service.
2. You should find "JetPatchIntegration" in the System Web Services section, click on it (if you don't see it - refresh the page)
3. The Name should be "x_inti4_jetpatch_i_jetpatch_integration". Copy it and save this for later.

Step 2: Setup ServiceNow configuration in JetPatch

Configuration fields

Add the following configurations in the intigua.properties file, located on the JetPatch Application Server.

Please change the values based on your environment (via the Intigua application ServiceNow WSDL file).

Enable ServiceNow Integration

For Patch Operations:

# Whether or not to enable the Remediation Plan integration
serviceNow.remediationPlanEnabled=true

(OPTIONAL) For Agents and Connector Operations

• Note: most users only want integration for patch operations, so please skip this optional step unless you really want integration for agent management or for connector deployment
• Deploy/Remove/Start/Stop a managed agent
• Install/Remove Connector

# Whether or not the enable the integration for connector/agent deployment/removal
serviceNow.enabled=true

ServiceNow URL and Credentials

# The URL to service now
serviceNow.hostUrl=https://example.service-now.com
# Intigua's integration user
serviceNow.userName=<SNOW_USERNAME>
# Intigua's integration user password
serviceNow.password=<SNOW_PASSWORD>

Please Note: a the ServiceNow.user must have REST capabilities, and is allowed to Open, Read and Change (Write) to tickets is required for ITSM integration.

ServiceNow tables mapping

# The table of creating and polling items
serviceNow.table=change_request
# Name of the table to upload into (which is normally part of the Intigua Integration application)
serviceNow.uploadTable=<NEW_APPLCIATION_NAME_CREATED_IN_STEP_1.3.3_ABOVE>

ServiceNow fields mapping

For the Upload table (the new application table):

# The correlation ID field as appear in the upload table
serviceNow.correlationId.field.upload=correlation_id
# The field where Intigua should write a short description
serviceNow.shortDescription.field=short_description
# The field where Intigua should write a detailed description
serviceNow.description.field=description
# The assignee field in ServiceNow:
serviceNow.assignee.field=assigned_to
# The field for Risk:
serviceNow.risk.field=risk

Notes:

• In most cases, creating a new application map to the "Change Request" table will result in a "u_" prefix to the fields (this is why the values above are starting with "u_").
• The fields above may be changed. Please check the "Checking ServiceNow Properties Names for JetPatch Configuration" in the Notes below.

For the Change Request table:

# The field to poll for the request status
serviceNow.approval.field=approval
# The correlation ID field as appear in the Change Request table
serviceNow.correlationId.field=correlation_id

Note - The fields above may be changed. Please check the "Checking ServiceNow Properties Names for JetPatch Configuration" in the Notes below.

Expected values for Risk

# Comma delimited values is expected in serviceNow.approval.field in case of risk:
serviceNow.risk.veryHigh.values=1
serviceNow.risk.high.values=2
serviceNow.risk.moderate.values=3
serviceNow.risk.low.values=4
serviceNow.risk.none.values=5

Expected values for Change Status

# Comma delimited values is expected in serviceNow.approval.field in case of a rejection
serviceNow.approval.reject.values=rejected
# Comma delimited values is expected in serviceNow.approval.field in case of an approval
serviceNow.approval.approved.values=approved
# Comma delimited values is expected in serviceNow.approval.field when the request is pending
serviceNow.approval.pending.values=requested,not yet requested,not requested

General Integration Configuration

# The interval between pooling the "Service Now" service in seconds
serviceNow.polling.interval.minutes=1
# Timeout
serviceNow.approval.timeout.hours=168

Predefined "Assigned To" user (can be empty):

# The assignee username in ServiceNow:
serviceNow.assigneeUserName=<ASSINED_TO_USER_NAME>

Example of what it would look like in ServiceNow

Additional Configuration (optional):

Closing ticket via "upload table" and not using the regular table

WARNING - If closing ticket via "upload table" is set to true, this configuration needs ServiceNow interface change

# Use PUT call to upload table for ticket closing
serviceNow.ticket.close.via-upload=false

• For more configurations follow ITSM Integration Setup.  

Changing protocols configuration

Timeout changes:

# Protocols timeout in milliseconds (default 10 seconds)
serviceNow.connection.timeout.ms=10000
serviceNow.socket.timeout.ms=10000

connection re-use:

serviceNow.connection.no-reuse=false

True - JetPatch will not reuse a connection (related to the 'keep-alive' http property).
False (default) - JetPatch will check if the current connection can be kept.

Step 3: Validate integration between JetPatch and ServiceNow

1. Try to deploy/remove an agent on a machine or activate a new Remediation Plan.
   1. If you are trying to do agents activities - You will see new activity in Pending.
   2. If you are trying to do patching activities - You will see that the Remediation Plan in the "Pending" column.
2. Go to ServiceNow server and search for "Change".
3. Under "Change" section go to "Open". Make sure you are sorting the table based on the creation date ("Created")
4. You need to see new request which "Approval" is Requested.
5. Approve the Change Request
6. Go back to the Intigua console and check that the operation continue and is being executed.

Optional Step#1 - (Template Name / ID, date, CI matching)

2. The start_date and end_date properties will be populated with values:
a) start_date : the earliest of all relevant MW start date
b) end_date : the latest of all relevant MW end date.

New properties with default values:

#field name to set a RP start date (smallest of start time from all MW)
itsm.start-date.field=start_date
#field name to set a RP end date (biggest of end time from all MW)
itsm.end-date.field=end_date

3. Affected CI (computer) list will be populated with relevant computers from RP. The match between JetPatch and ServiceNow entries is done by name and/or IP so the names in JetPatch should match the CI names in ServiceNow. Only the matched CI will be populated.

New properties with default values:

# if the Affected CI list has to be populated
itsm.ci-list.enabled=true
# number of itmes in chunk to fetch while loading CI items fromt he cmdb_ci table.
serviceNow.cmdb_ci.sysparm_limit=1000
# JetPatch to ServiceNow CI match; whether to use name for matching
serviceNow.ci.compare-name=true
# JetPatch to ServiceNow CI match; whether to use IP for matching
serviceNow.ci.compare-ip=false
# Able to replace the table to be queried for Configuration Item (computer) match 
serviceNow.ci.table=cmdb_ci_server
# Able to add a limit query according to ServiceNow Table API rules 
serviceNow.cmdb_ci.sysparm_query = null #example: sys_class_name=cmdb_ci_server^ORsys_class_name=cmdb_ci_linux_server
# Defines whether the cmdb_ci property will hold the full name or just the hostname part. By default only the host part will be sent. Setting the value to true defines sending a full name.
itsm.cmdb_ci.use-full-name=false
# For the case when ServiceNow can hold both full names and hostnames  and the definition of itsm.cmdb_ci.use-full-name  does not help, the ServiceNow matching by hostname was introduced. For this a new configuration property was added
serviceNow.cmdb-ci.match-with-query=false

serviceNow.ticket.close.on-state=0,Review,Closed

itsm.ticket.pg.close.retry=false

serviceNow.risk.value=

Notes

Change Field Length

In some cases, you need to change the max length for the "Short description" and "Description" fields:

1. In the search panel, search for the JetPatch dedicated System Web Services ("Intigua Integration") and click on it.

2. In the "Web Service Fields" find the problematic field (you can go to the next page in the top right corner of the table) and click the "!" icon and Open Record:

3. Change the value in the "Lenght" field. 

Recommended values:

• Short description = 100
• Description = 4000

Canceling a Remediation Plan

When a user cancels a Remediation Plan in JetPatch, JetPatch will try to close the ticket and won't cancel it.

Service Now needs to have the ability to move a ticket from any state to a close state (transition).

To do it

1. Go to System Defenition -> Script Includes from the left menu.
2. Search for "ChangeRequestStateModel_ normal" in the "Name" column and click on it.
3. In the "Script" section, we need to allow the transition from each state to "closed":
   
   1. Before doing any changes backup the existing script by copy the script content to a file and save it.
   2. In each state, need to add the "Close" transition 
      

      closed: {
                  moving: function() {
                      return this.toClosed_moving();
                  },
      
                  canMove: function() {
                      return this.toClosed_canMove();
                  }
              }

      Example of the changes in the "draft" state:
      
   3. Save the script

Checking ServiceNow Properties Names for JetPatch Configuration

The properties in JetPatch configuration (intigua.properties) should match the values created in Service Now new "System Web Service" integration (intigua integration).

There are two ways to get the desired value -

1. Check the WSDL of the "Intigua Integration":
   1. In the left menu, search for "System Web Service" and click on the JetPatch integration ("Intigua Integration).
   2. Click on the "WDSL" link and view the fields and view the fields name.
2. Check the field name in the "System Web Service":
   1. In the left menu, search for "System Web Service" and click on the JetPatch integration ("Intigua Integration).
   2. In the table at the bottom ("Web Service Fields") check the "Name" of the fields.

Technical API calls

Create a new change request:

Notes:

1. In order to use the "configuration_items" information - the ServiceNow interface should be customized to support it
2. The "remediation_plan_description", "configuration_items" and "requested_by" are optional configuration. More information can be found in ITSM Integration Setup

Checking change request details:

• Before creating the change request - check if the change request exists by correlation id.
• After creating the change request - to check if it was approved.
• Before closing the change request - getting the sysid of the ticket.

Note - JetPatch is checking the value for the "approval" key when it needs to be approved.

Close change request using the main Servicenow table (default):
Note - Default closure flow (serviceNow.ticket.close.via-upload is false)

Close change request using upload table:
Note - serviceNow.ticket.close.via-upload need to be set to true

Approving ticket using an external system:
Note - "ticketId" or "correlationId" - Either one is mandatory.

Reopen rejected ticket:

Reopen the same Change ticket (default)