Integration Techniques in Service Now
This is going to be a technical discussion, and a long post. In this post we will look at the different integration techniques and would help you finally pick the best one based on its Pros and Cons.
This post will be divided into two sections. The first section is about Initial Setup, and the second section is about the Freeflow of updates between Service Now and any other tool Service Now is integrating with.
Initial Setup:
Initial setup is a phase where there is no data in Service Now, and you need to get in entire dump of data from the other tool.
Free flow of Updates:
Here you are more concerned about how to get the data that is Updated/inserted in the other tool, into Service Now in real time. For example, you need to quickly get the Incident created/updated in NetCool into Service Now.
Different ways we can do it:
JDBC/FTP(s)/HTTP(s)
JDBC offers a very robust way to connect directly to a Database like SQL/ Oracle using drivers and pull the information into Service Now. You can even give in your SQL query in the Service Now which will be executed and the data be fetched.
Pros:
It’s a kick ass way of getting the updates between two Databases at a time. The fastest when it comes to setting up an Initial dump of Data. You will be directly talking to the Database, with no middle man. I would go for it without thinking twice. It’s fast and secure.
Cons:
It really is very lethargic when it comes to free flow of updates. Say something got changed in the other tool, JDBC cannot tell you until the schedule that picks the data runs in Service Now. So it’s NOT recommended for free flow of updates.
I wouldn't talk much about the good ol’ FTP(s) and HTTPS(s). Both are excellent ways of getting the information into Service Now. They operate the same way as JDBC but may be slow when compared to JDBC because we are taking the entire shebang at the Application Layer ( over HTTP and FTP ). Other than that, I don’t see any other reason on why I don’t use FTP, HTTP. It like JDBC suffers from the same disadvantage when it comes to free flow of updates. Get more from Servicenow Admin training
Web services:
Web services come in twos. SOAP and REST.
Both SOAP and REST are very good when you are using them for Freeflow of updates. There are many designs when it comes to SOAP and REST. Let’s look at them one by one.
SOAP:
You are presented with three design options here :
a) Using Direct Web services.
b) Using Scripted Web services.
c) Using an Inbound table. Learn more from Servicenow Developer Training
a) Using Direct Web services:
The advantage the Direct Web services offer you is the speed. When you use a Direct Web service, you directly insert into a table, and you get the response. There are many disadvantages though, some of them are
1. You cannot customize the output in case of an error.
2. You are directly exposing your Production tables.
3. You cannot log the request you received from the external tool.
4. You cannot talk to more than one table at a time.
I wouldn't take this approach, unless I have no option. For more info Servicenow Training
b) Using Scripted Web services
The advantages of Scripted Web services:
1. You can talk to more than one table at a time.
2. You can log the request you received.
3. You can customize the output, and this will require some customization on your part.
4. You can hide the Production table, by creating a Staging table in the middle, and once the data is in Staging table, write the logic on the Staging table. Don’t get confused that Staging table here is the Import set table. No, it is not. We will discuss the Import set tables in the next bullet.
The main disadvantage of Scripted Web service is the speed. Apart from that, All is well here. Oh, you can get only one SOAP endpoint per one Scripted Webservice, which sucks. Where as using Direct Webservices/Import set table, you get whole lot of SOAP endpoints to Update/insert/delete/get etc.,
c) Using an Import Set table:
If you ask me this is the best way when you go the SOAP way. Instead of exposing a Production table, you expose an Intermediate Import set table, that takes the input and gives the output. You have all the flexibilty to customize the output, and it’s fast as well because you are using the OOB setup to write Transform Maps to move the code into Production tables. To get more info Servicenow Online Training
REST:
My personal favorite, as REST is one the most flexible specifications that is there out there when it works with JSON.