VPN for REST Integration?

Go to solution
andysummers
Tera Expert

‎05-14-2016 02:44 AM

Hello,

I'm new to development with ServiceNow and my company is placing a big expectation on me to deliver integration with some of our back office systems inside the company network ahead of a go-live with ServiceNow in a few short months. I understand about Outbound Webservices from SN and plan to use REST calls to get data from a web service that is behind our company firewall. We have a Mid Server but that too is behind the firewall I believe; our security team felt it was better to have it there.

The question I have is around using a VPN for the connection to our internal web service(s). I'm reading a lot of guides and articles that say there are better and easier ways to get SN talking to our internal systems and that VPN is not generally encouraged any more- is this true?  

I know I could use a Mid Server to act as a proxy for the web service but I would assume that it would need to be out in the DMZ for SN to be able to connect to it. If you go down that route, would a client script calling the webservice via a Mid Server be synchronous and wait for a reply?

The web service will take a parameter such as a customer number, and return a record from our Oracle instance with customer name, address, number etc. so it needs to be a real time lookup.

I'm concerned that if the VPN tunnel goes down, there will be a big problem for people raising tickets as the system will not work.

Is there a best practise for this kind of request? Really appreciate any thoughts on this topic.

0 Helpfuls
  • 5,154 Views
1 ACCEPTED SOLUTION

Go to solution
Robert Beeman
Kilo Sage
In response to andysummers

‎05-16-2016 08:24 AM

Hello Andy,



All REST messages sent through the MID server are async (Scripting Outbound REST - ServiceNow Wiki). In addition to that, your onChange client script would need to GlideAjax back to the SN instance to access the RESTMessageV2 API server-side before it even places your REST message on the ECC queue. There would be significant delays (I would imagine 45-60 seconds).



It might be better to use a regularly scheduled job to import this data into a local SN table so that it is quickly accessible from a user facing form. We do this with our cost centers and shipping addresses. We have a SOAP integration with SAP that imports this data (through MID server) on a regular basis. This data doesn't change too frequently for us though, so the delay between jobs is acceptable.


View solution in original post

6 REPLIES 6

Go to solution
Robert Beeman
Kilo Sage
In response to andysummers

‎05-16-2016 08:24 AM

Hello Andy,



All REST messages sent through the MID server are async (Scripting Outbound REST - ServiceNow Wiki). In addition to that, your onChange client script would need to GlideAjax back to the SN instance to access the RESTMessageV2 API server-side before it even places your REST message on the ECC queue. There would be significant delays (I would imagine 45-60 seconds).



It might be better to use a regularly scheduled job to import this data into a local SN table so that it is quickly accessible from a user facing form. We do this with our cost centers and shipping addresses. We have a SOAP integration with SAP that imports this data (through MID server) on a regular basis. This data doesn't change too frequently for us though, so the delay between jobs is acceptable.