×

IDMWORKS Blog

SailPoint IIQ and ServiceNow custom integration using ServiceNow REST APIs (ServiceNow Table API) – PART 1


SailPoint IIQ provides many out-of-the-box (OOTB) options to integrate with ServiceNow. Though OOTB integrations are great for most of the common use cases, it lacks the flexibility and provides less control over the entire process. Many times we come across a requirement where we need total control, and that’s where this custom integration can be very useful.

The Problem

SailPoint IIQ provides multiple ways to integrate with ServiceNow (SN) e.g. direct connector, through SIM integration module, and using SN service catalogs. Details on OOTB integrations can be found here here.

My requirement was to create ServiceNow incident and Service Catalog requests using a custom workflow with the expectation of getting information using custom forms in IIQ and then adding the gathered fields in SN incident/service request for audit information. Additionally, there needed to be a way to close the incidents created earlier. The fields in custom forms were not related to any application and had to be entered manually.

The Solution

This wasn’t the typical de-provisioning to the disconnected application. Though this requirement could have been fulfilled using some workarounds to the OOTB integration, the solution would not look clean, as this would involve creating a fake disconnected application.

In order to address the requirement, I decided to go with SN REST table APIs. SN exposes the table APIs to integrate using JSON over HTTP/S. You can find more details on table APIs here. (This is a series of two blogs and this blog only covers the Incident Management. In the second blog, we will cover the Service Catalog management.)

ServiceNow REST API can be called using the table API endpoints/URIs. URI has table names which represent the resource name.

As our goal was to create incidents, the respective SN table is incident. The complete URI for incident management should look like the table below.

Refer below table for SN URIs, operations, and HTTP Verbs.

No. Operation URI HTTP Verb
1 Create new Incident in ServiceNow https://xxx.service-now.com/api/now/v1/table/incident POST
2 Get the existing incident from ServiceNow https://xxx.service-now.com/api/now/v1/table/incident/sys_id

Note: sys_id is internal system identifier of the incident object created earlier. Incident Number won’t work.

Examples:
Sys_id: 1a451fad4ff3130081630fbf9310c7b0
Incident Number: INC0010119

GET
3 Update the incident created earlier https://xxx.service-now.com/api/now/v1/table/incident/sys_id

Note: sys_id is internal system identifier of the incident object created earlier. Incident Number won’t work.

Examples:
Sys_id: 1a451fad4ff3130081630fbf9310c7b0
Incident Number: INC0010119

PUT

ServiceNow exposes multiple ways to authenticate. For this blog, we will use “basic authentication”. You can find more about basic authentication here.

The Prerequisite

Following variable values must be gathered before you start the implementation.

No. Variable E.g. Value Comments
1 EndpointURL https://xxx.service-now.com/api/now/v1/table Common portion of the SN URI. The suffix can be added to base URI to generate table specific URI.
2 Username admin Username is used in basic authentication. This user must have the appropriate rights to manage incidents in SN.
3 Password P#ss&rd134 Password is used in basic authentication.
4 CallerID 1a451fad4ff3130081630fbf933454 Sys_id of the caller. This is the sys_id of the SN user who will be set as a requester of an incident.

This example expects the custom IIQ object which holds the ServiceNow connection details.

The Implementation

The details of the custom workflow are left to the implementer.  My workflow looks something like this:

 

The “Create ServiceNow ticket” step is responsible for creating the ServiceNow incident.

The following ServiceNow target variables are being passed to the workflow using the workflow variable.

The following script is responsible for creating the Incident in SN. Code comments should help in understanding the overall flow of the request.

ServiceNow incident should be visible once workflow completes its execution.

Highlighted fields in the above screenshot are set using the REST API.

Closing The Incident

If you want to close the incident created earlier, follow the code below:

This should close the incident by setting its close_code, close_notes and state.

Setting Additional Fields In SN:

If you want to set different or additional fields than shown in the above example, please go through the ServiceNow Table API documentation to get the details on all the available fields. I have included the list of available fields for Incident table below.

 

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *