Rest Intigration

Hello,

A brief introduction to ServiceNow integration via REST APIs is in

here. You can kick start to explore REST methods within ServiceNow.

UNDERSTANDING SERVICENOW INTEGRATION AND CAPABILITIES

ServiceNow provides a variety of methods to integrate, most notably Web

Services, JDBC, LDAP, Excel, CSV, and Email. Here we focus on the web
services integrations via REST, SOAP and more, which you can find here
- Supported integration interfaces.

With emerging families that ServiceNow provides biannually (current version

- London), there is a lot coming up with best practices and faster
integrations. Out there in the London release there are several integrations
that offer promising automation opportunities with minimal
configurations, IntegrationHub is one of them.

For any integration, we consider input and output with a medium as

authorization. Summarizing the integration capabilities, here is a list of ways
we can proceed with:

API Explorer | Scripted REST APIs | Using MID Server and Scripts
| Import/Exports using Transform Maps | Orchestration | IntegrationHub
etc..

Off which, the most common used path is for SOAP/REST APIs which involves
a request and response. ServiceNow uses JSON as a medium of data
transfer from instance to 3rd party resource. Here we shall proceed with
REST API exploration and move on to further articles for integration
techniques.

EXPLORING AND CONFIGURING SCRIPTED REST API (TESTING WITHIN

SAME INSTANCE)

a. Go to System Web Services > Scripted REST APIs > Create New > Submit.

Remember your Base API path, which helps you later to provide the end point
details at 3rd party (Note: IncidentRx in the screenshot, Rx = receive)
b. Now, create a new resource - use HTTP Method as GET as shown below:
Here, in the above Relative path, you can use unique field from incident, let's
say the sys_id to call a particular incident. To do this, use {custom_sysid}
as a value in the relative path and in the script just modify to include this
value while doing glide record - at line 1 include var incid
= request.pathParams.custom_sysid; and remove the respective line after
while loop and there you go for a specific retrieval (Note: you may use if loop
instead, while loop is used for generalization)

3. Copy this code in the script:

(function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) {

//var incid = request.pathParams.sys_id; //we cannot use this line

anymore for random sysids
var inc= new GlideRecord('incident');
inc.query();
while (inc.next())
{
var incid = inc.getUniqueValue();
inc.get(incid);
var incResponse = {
number: inc.getValue("number"),
priority: inc.getDisplayValue('priority'),
sysID: inc.getDisplayValue('sys_id'),
//etc., you can add other variables similar way
};
return incResponse;
}
}) (request,response);

4. This script shows the output - the first incident number, as we used a

while loop here and the REST API brings single record - if we call this via
Explore REST API page as seen below:
In the Explorer, the Namespace indicates system scope, which is unique for
each instance given by ServiceNow. The API Name is the Scripted Rest you
just created and API Version, which is optional for you to select based on V1,
V2 etc., but in the later stages this becomes very critical to choose a
version. And finally, the GET HTTP method is displayed below these
information.

The content shows beside is the GET URL along with the Resource path that
gets auto generated while creating the resource in step above. Once, we get
on with the testing here, we may use the Query parameters for integrating
with 3rd party tools. You can see the request and response formats are
defaulted to JSON format, though you can change based on your 3rd party
tool, this is recommended from ServiceNow.

Authorization normally require when we access information from other

system, but for now we are just testing the REST API call from the same
instance, so this is set to 'Send as me', makes sense.

Finally, you may click on SEND and see the response below on-demand.
Note: If you encounter any error, you may verify the API Path, script and
variable names from incident table.

5. Response is shown below:

The response code here is 200 OK meaning successful. Other cases are
provided here: rest-http-response-codes

Once, this testing is done, which means you are ready with basic skill to
integrate with other systems.

We may proceed further with next steps in the Level 2 article. Thank you for
reading out, please leave out your comments and I can improvise the article
for better understanding.