Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

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,810 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.