ServiceNow to ServiceNow Integration - Step
by Step Guide
ServiceNow Instance to Instance Integration -
Step by Step Guide
ServiceNow provides various Inbound and Outbound web services:
Inbound web services allow you to access and modify ServiceNow data using a
client application.
Direct Web Services: query tables and records directly using SOAP, REST,
or other web service formats.
Import Set: access the import set tables and import data through a web
service interface.
Scripted Web Services: define custom web service endpoints using
JavaScript.
Outbound web services allow you to send SOAP and REST messages to external
web service providers.
Outbound REST
Outbound SOAP
Welcome to this page on ServiceNow to ServiceNow Integration - A step by
step guide. This integration follows the ServiceNow integration with any 3rd
party tool as a reference to put the requirements together.
1. Design the Flow:
The design assumes instance 1 and instance 2 as [Link] and
[Link] respectively. The process involves one way
communication from dev1 to dev2, which performs operation on Create and
Update.
Flow 1: Start > Create Incident in dev1 > Copy details to dev2 > Create Incident
in dev2 > End
Flow 2: Start > Update Incident in dev1 > Copy details to dev2 with reference
to already existing record > Update Incident in dev2 > End
Note: Both instances are in parallel connection before we begin this integration,
meaning there is no cloud based, location based connection within any routing
mechanism.
2. Configure the Endpoint URL and Authentication:
This will be done in the ‘System Web Services > Outbound > REST Message or
SOAP Message’ of ServiceNow dev1 instance. The Endpoint URL depends on
REST or SOAP method of Integration to decide the flow. Authentication will be
included within REST Message or in HTTP Method. Details shown in Step 5.
HTTP Methods allowed for operations are POST (for creating a record in dev2),
PUT (update), GET (retrieve/read) and DELETE (delete). We consider POST and
PUT methods in this project.
3. Explore the communication channel:
The communication channel we chose is one way from dev1 instance to dev2
instance to either create or update incident records. This process demands an
Outbound Web Service to be enabled at source instance i.e., dev1 instance.
There is no need for an inbound message at dev2 as ServiceNow handles the
complexity here.
4. MID Server Usage:
As this is a demo project, we have not configured any MID Server but involving
MID will guarantee a secure connection for live environments. If we do include
this, then the attachment is made within REST/SOAP Message form as a
reference field linked to MID Server.
5. REST Message (or) SOAP Message:
We gonna be using RESTful services in our project, the process for this will be
shown in the screenshots below.
I. Create a new REST Message and add the details as shown. Replace ‘dev2’
text in the Endpoint URL with your instance name. Create a new ‘Basic auth
profile’ which holds the credentials of dev2 instance, as a pre-step for this
profile, create a new user profile in dev2 instance for handling REST based
incidents from dev1 exclusively.
II. Dev2 Instance User Profile must have ‘web_service_admin’ and ‘’rest_service’
roles as part of REST integration access. Make sure you access the
application/table (in our case it is Incident Management/incident of dev2
instance) which has ACLs that allows for create and write operations. As ACLs
take more precedence than integration role, you must add necessary roles for
accessing incident table here (our case we don't need any external role to
create or write to incident table)
III. HTTP Method - POST:
(PUT is not shown here, you can configure the same way with little differences
which if required we can do in the comments)
Note the Content displayed in the POST operation - {"short_description":"$
{short_desc}"}. We are just passing one parameter for this demo.
Click on Preview Script Usage in the related link under the same form as shown:
This displays the easy script that we need to insert in our next step - Business
Rule
Before moving on to Business Rule, we have to create the short description field
in the variable substitution under POST HTTP Method for REST Message, just
follow as shown below. You can give a default value to verify and click on Test
link below which creates a record in Dev2 instance with default value on short
description that you chose. In the next step we make this default value to
dynamic short description from dev1 instance.
6. Script Include Usage: (Instead we use a Business Rule)
There are no conditional or filtering operations we need as part of instance to
instance integration. ServiceNow back end table schema and API similarities
here removes away the complexities. However, we do need to verify things when
we integrate with any 3rd party tool/platform.
Business Rule Usage:
Write a Business Rule as shown below on incident table, click on Advanced if
you don't find every field as shown.
Go to Advanced tab and copy the script that you generated from above Step 6.
We do need to edit the script here.
(function executeRule(current, previous /*null when async*/) {
try {
var r = new sn_ws.RESTMessageV2('Create in dev2 instance', 'post');
[Link]('short_desc', current.short_description); //get from
dev1
var response = [Link]();
var responseBody = [Link]();
var json = responseBody;
var obj = [Link](json); //define JSON parsing for the response JSON file to
decode
var foundsysID = [Link].sys_id; //decoded dev2 newly created incident sys_id
current.correlation_id = foundsysID; //copied the sys_id of dev2 incident to
correlation id
[Link](); //update the current incient in dev1
[Link]("The generated sysid from Dev2 instance is : "+foundsysID); //log sys_id
var httpStatus = [Link]();
}
catch(ex) {
var message = [Link];
}
})(current, previous);
7. Deciding on the Message structure:
The message structure, we mean the data syntax to be used while transferring
data from dev1 to dev2. As said our both instances have similar system
configuration or properties and hence the standard methods of message
structure can be undertaken. For REST the format would be JSON (JavaScript
Object Notation) and for SOAP it is XML(Extensible Markup Language). In our
case this would be JSON Structure and the default REST Message's HTTP
Header would be 'application/json'.
8. Define Parameters, attributes or fields:
There is a need for a unique field that will be used at dev1 instance to make sure
the field exists in dev2. What we mean here is, say Correlation ID is a field in
dev1 and this holds the value of SYS_ID from dev2 for every newly created
incident in dev2. Also, if we were to update any record we use this Correlation ID
from dev1 and search in dev2 instance, if found then that particular record will
be updated.
Dev1 instance Incident form fields - notify Correlation ID field, populating this
field is done dynamically from a Business Rule.
Result Screenshots:
Dev1 instance is in Madrid release and Dev2 in Kingston. Note the incident
numbers for each instance is different. Also, as a hint client instances are all
connected to one source, hence we do not need integration in case if there is a
requirement to copy records, instead we can request for a System Clone in that
case.
Dev1 Incident Details:
Dev2 Incident Details:
Further steps are not required as part of our project definition. If someone is
interested, I can help on how to proceed on next steps. Thank you for reading
out.
Comment:-
I noticed you used the standard table API for your integration, would it not be
better practice to use an API against an Import Set instead of hitting the target
table directly when creating/updating in ServiceNow via a web service? Or even
better if working with a 3rd Party system, create a nice Scripted REST web
service as this allows you to build in some nice validation and error handling and
still allows you to hooks into an Import Set for a super robust integration
solution?
