This article is a supplement to the ServiceNow documentation. For full documentation please refer ServiceNow official website
Checkout our NEW Video Channel you can like and subscribe too!

Introduction

A web service is a collection of protocols (SOAP/HTTP) used for exchanging data between software applications written in different programming languages and running on different platforms through internet.

basicIntegration13112019 (1).png

Types of WebServices?

Webservices are generally SOAP based or Rest based.

Consuming/Exposing WebService

The client side who calls the web service is termed as consuming the WebService The server side who offers the methods in the WebService is termed as exposing the WebService

basicIntegration13112019 (2).png

Components for SOAP based WebService

SOAP (Simple Object Access Protocol)

SOAP is protocol like HTTP that can be used to communicate between two application like Java and dot net.Every SOAP have a request message and a response message.Each SOAP message is send as SOAP envelop as shown in the diagram below

integearrion13112019.png basicIntegration13112019 (3).png

WSDL (Web Services Description Language)   WSDL is the contract that tells the client who is consuming the webservice the available method expose by the server who is exposing the webservice. WSDL url ends with WSDL at the last, example as below. It is a xml document, it can be opened in the browser also

http://www.webservicex.net/GenericUNSPSC.asmx?WSDL

basicIntegration13112019 (4).png basicIntegration13112019 (5).png basicIntegration13112019 (7).png

UDDI (Universal Description, Discovery and Integration)

This is an optional component, this is like a telephone directory were we can lookup for all the available wsdl exposed by a organization.

Types of WebServices in Snow

There are mainly 2 types of web services in SNOW: Inbound and Outbound

Inbound:

When ServiceNow tables are queried or some data is inserted to ServiceNow tables from an external app.

For example, we create an application that can create an incident record in service now.

Every table in service now have a WSDL exposing the methods that can be triggered from outside.To check any table WSDL, just suffix? WSDL at end of the table

integration12313112019.png

basicIntegration13112019 (8).png

Outbound:

Outbound WebServices is used when snow communicates with an external app to collect some information.

For example, we want get all CI information from HP uCMDB using WebServices exposed by uCMDB.

basicIntegration13112019 (9).png

Call an outbound WebServices programmatically

We have to use inbuilt ServiceNow API to call a WebServices. Most of them are auto generate. We have to use them and do minor changes based on our needs.

To know the script, open any SOAP message and follow the below steps

basicIntegration13112019 (17).png

Click on any webservices from the list

basicIntegration13112019 (18).png

Click on the Name Scroll down and click on any of the available method basicIntegration13112019 (19).png

In the new window scroll down and click preview script usage

basicIntegration13112019 (20).png

This will give the script that can be used to programmatically call the webservice function basicIntegration13112019 (21).png

We can just copy paste this script and run it as background script we did for Glide record earlier

basicIntegration13112019 (22).png

Integration ServiceNow with HpuCMDB

In this use case we are going follow below strategy

  1. Create a SOAP Message using HP ucmdb WSDL (we will use sample wsdl here for example)
  2. Verify the connection by testing one of the function of the WSDL
  3. Create a CI table where we are going to import all CIs from HP uCMDB
  4. Create a datasource with a import set table (staging table) and transform map.
  5. The Transform Map we are going to match the HP CMDB fields to SNOW CMDB fields
  6. We are going call the WebService and populate the staging table via Glide script.
  7. The Transform Map will auto trigger and insert record into the CI table
  8. Finally we will schedule the script at a required interval so that we can keep SNOW CMDB up to date.

Step 1: Goto SOAP Messages and Create a new message basicIntegration13112019 (23).png

Step 2: Then click on “Generate Sample SOAP messages” .If successful It will list down all the available function in the webservices basicIntegration13112019 (24).png basicIntegration13112019 (25).png

Our WSDL import is done now

In case of authentication of the WSDL, we have the pass the username and password under basic authentication

basicIntegration13112019 (26).png basicIntegration13112019 (27).png basicIntegration13112019 (28).png

Step 3: We need to verify one of the WSDL methods Click any one of the function and the next window opens basicIntegration13112019 (29).png

Step 4:Then scroll down and click on test basicIntegration13112019 (30).png

In the response we can see the o/p message from the external server

basicIntegration13112019 (31).png

Step 5: Create a destination table where we want to finally import the data The table will have only 2 fields ci name and ci location basicIntegration13112019 (32).png

Step 6: Now lets create the transform map and staging table using a datasource basicIntegration13112019 (33).png

Step 7: Create a new datasource basicIntegration13112019 (34).png

The import set table is now set.

Step 8: Now before executing the script, we have load a dummy excel for the first time and create a transformation map.

Otherwise if we directly try to insert to the staging table using the script it will give exception basicIntegration13112019 (35).png

And the transform map looks like below when auto matching is clicked

basicIntegration13112019 (36).png basicIntegration13112019 (37).png basicIntegration13112019 (38).png

Step 9: We are now going to call the webservice and populate the staging table using script basicIntegration13112019 (39).png

Step 10 Finally we can put the script in a schedule job so that can keep on pulling data from uCMDB. basicIntegration13112019 (40).png

Step 11 Then create a new job with the below script basicIntegration13112019 (41).png

Step 12 To test it, click on Configure Job Definition basicIntegration13112019 (42).png

Step13 Here we scroll donw and click execute now basicIntegration13112019 (43).png

SOAP AND REST

SOAP SOAP is a protocol which was designed before REST and came into the picture. The main idea behind designing SOAP was to ensure that programs built on different platforms and programming languages could exchange data in an easy manner.

REST This was designed specifically for working with components such as media components, files, or even objects on a particular hardware device. Any web service that is defined on the principles of REST can be called a RestFul web service. A Restful service would use the normal HTTP verbs of GET, POST, PUT and DELETE for working with the required components.

soapvsrest14112019.PNG

SOAP VS REST

difference soapand rest14112019.PNG

Which is more secure SOAP or REST?

SOAP has provided an added extensions for transnational messaging addressing specific security concerns. SOAP has came long back and has been successfully accepted and used in large enterprises. XML-Encryption, SAML token, XML-Signature to name a few screwed tightly the security story over data being received by and sent from a SOAP service.

On the other hand, REST does not implement as such specific security patterns. REST keep its focus on how to deliver and consume data, not how to build in safety while you exchange data. In REST patterns, it is imperative to give attention to amount of security in code, deployment and transmission, instead presuming as something that comes out-of-box.

If you are about to implement API within your project, use comparison points between REST and SOAP as a guide:

  1. When standardization and security are your major goals, SOAP is considered as a stronger option to use as Web Services. Both API formats support Secure Sockets Layer that protect data when it get transferred. However, SOAP additionally offer WS-Security that’s an added perk to enterprise.
  2. REST is an API standard that is compatible with various data outputs types such as JSON, CSV and XML, while SOAP can only handle XML. JSON format is easier to parse than XML, using REST for data transfer in JSON help save lots of bucks in computer infrastructure costs.
  3. REST is more advanced, so when another endpoint requests an already completed query, the API development can use the data from the previous request. On the other hand, SOAP implementations have to process the query every time.

SOAP is the best choice in projects developed and containing crucial private information such as finance, banking, and alike. However, you don’t need to use SOAP while developing mobile app that sends the day’s forecast as you don’t need extra security in that.

Though it sounds like SOAP has total advantage over REST, but a good REST implementation benefit much to an enterprise instead of using a poorly-designed SOAP API. SOAP has built-in error handing for communication errors via tha WS-ReliableMessaging specification. On the other side, REST has to resend the transfer whenever it encounters an error.

    Content