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 dev1.service-now.com and dev2.service-now.com 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');
 r.setStringParameterNoEscape('short_desc', current.short_description); //get from dev1

 var response = r.execute();
 var responseBody = response.getBody();
 var json = responseBody;
 var obj = JSON.parse(json); //define JSON parsing for the response JSON file to decode
 var foundsysID = obj.result.sys_id; //decoded dev2 newly created incident sys_id
 current.correlation_id = foundsysID; //copied the sys_id of dev2 incident to correlation id
 current.update(); //update the current incient in dev1

 gs.log("The generated sysid from Dev2 instance is :  "+foundsysID); //log sys_id       
 var httpStatus = response.getStatusCode();
}
catch(ex) {
 var message = ex.message;
}
})(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.

Regards, Akash

Labels:

• Integrations
• Personal Developer Instance
• Scripting and Coding