VPN for REST Integration?

andysummers · ‎05-14-2016

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.

Robert Beeman · ‎05-16-2016

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

martygrinstead · ‎05-14-2016

Hi Andy,

The MID server is expected to be running behind your firewall, so your setup is correct.

A VPN is a single point of failure, so the MID server is the better option.

When making requests through the MID server, your request is actually placed in the ECC queue, and then picked up (pulled) by the MID server. A RESTProbe will be executed on the MID server to make your REST call, and when the response is received by the MID server, it will create a new ECC queue record with that response.

The instance never "pushes" data to the MID server, which is why things work when the MID server is behind your firewall. The MID server will always make a connection into your instance and check the ECC queue for messages waiting to be processed.

You will be able to see exactly how long this takes in your environment. The round-trip time should be fairly quick.

Here's a link to the Fuji page for REST through a MID server: Outbound REST Web Service - ServiceNow Wiki

Good luck!

Marty

andysummers · ‎05-16-2016

Hi Marty,

Thanks for the information here. I was under the impression that the MID server needed to be in the DMZ but your explanation seems to clear that up.

I'm still not sure however if the MID server would be acceptable to the business when it works the way you describe, for the scenario I have. You say it's fairly quick but we're replacing a system where the lookup for customer data in our back office databases currently takes around 2 seconds and it is felt that much more than this will cause the SN users raising the tickets to report the application as unresponsive.

I understand what you're saying about the VPN being a single point of failure but I feel like its the only option unless the round trip to get customer data back to the ticket is extremely quick.

I think I read the default poll time for the MID server is 15 seconds and can be changed - would setting this to 1 second be advisable or practical ? This would be the only way I could see the real time lookup of customer data being acceptable to the business. Either that or a Firewall ACL rule with a direct connection from SN to our WebService provider internally.

Robert Beeman · ‎05-15-2016

We use our MID server (behind firewall) for several internal REST and SOAP integrations. We also leverage it to interact with Active Directory. We've used this configuration for almost three years now, and it has been very successful.

andysummers · ‎05-16-2016

Hi Robert - thanks for the reply.

Do your REST and SOAP integrations run synchronously? The scenario I have would require something like an onChange event on a customer number field to rall a synchronous REST query which returns some customer data from our back office system that is relevant to the rest of the ticket data being entered. Like Invoice numbers for instance- I would need to know them before the rest of the ticket could be saved and submitted.

This is what concerns me most about the MID server, if I use that (and I agree it seems like the best method), the user will either have to wait a long time for data to come back OR the request runs asynchronously and doesn't return anything while the user is working on the ticket. A lot of times, the REST call will be returning a List of Values that need to be populated on a particular field on the ticket BEFORE it's submitted.