ServiceNow SOAP interface via MuleESB proxy

In this blog post I will briefly entertain the idea of using MuleESB as a web service proxy between an unknown system and ServiceNow. Limiting the scope to scenario where System X is the party initiating the web service calls. If you need it to work the other way, just reverse the examples. You will have to setup inbound https endpoint which requires a bit more work. Like generating needed certificates and keys.

When would this be useful you ask?

Every now and then I come across systems (still live systems) which have code base originating from around the time I was born (the 80s). The systems do not necessarily have all of the "fancy" functionality I take for granted. Like ability to use HTTPS. It is not like Cloud used to mean something other than clouds in the sky back then, but now you have your ServiceNow instance running in the Cloud and unsecured HTTP is out of the question (just ask your local Chief Security Officer)

Other basic scenario for this is that after a lot of work, and diplomacy, you have setup VPN access to that 3rd party's system which is so deep in the 3rd party's network, it took months to get all the clearances and to set up the connection. Starting the show again to open the 3rd party's system to your ServiceNow cloud instance is out of the question (just ask you local Service Manager).

Additionally, you might have setup IP Address Access Control in your ServiceNow instance to allow traffic only from your company's network. Or your security policy does not allow providing user credentials to external parties (that pesky CSO again).

To the point

The easiest way (using MuleESB) to handle the issues below

• System X sends unencrypted HTTP and ServiceNow expects HTTPS
• You have to route traffic via your network
• You cannot provide user credentials to external parties

is to use the MuleESB's configuration pattern named web service proxy pattern. The example below does not do any transformation to web service calls, just acts as a proxy in between System X and ServiceNow's Incident web service. It does however allow the System X to

• call ServiceNow's web service using HTTP
• to make the call without knowing username and password
• to make the call via your network (provided that MuleESB is in your network)

The following snippet is the MuleESB configuration needed to perform the magic (I have omitted the namespace definitions).

<pattern:web-service-proxy name="sncIncidentProxy"
          inboundAddress="http://localhost:8090/incident.do"
          outboundEndpoint-ref="snc-incident" />

<https:connector name="HTTP_HTTPS_connector" validateConnections="true" sendBufferSize="0" receiveBufferSize="0" receiveBacklog="0" clientSoTimeout="10000" serverSoTimeout="10000" socketSoLinger="0" doc:name="HTTP\HTTPS"/>

<https:endpoint exchange-pattern="request-response" name="snc-incident"  connector-ref="HTTP_HTTPS_connector" doc:name="HTTP" host="yourSncHost" password="userspassword" path="incident.do?SOAP" port="443" user="user_name" disableTransportTransformer="true" mimeType="text/xml" contentType="text/xml" tracking:enable-default-events="true"/>

The <pattern:web-service-proxy> defines the inboundAddress which is the address to which the System X connects to, and outboundEndpoint-ref refers to the <https:endpoint> which is configured to connect to your ServiceNow instance. The pattern handles the incoming requests from System X and forwards them to ServiceNow using the referenced endpoint, then passes the response back to System X.

The <https:connector> defines the connector information required by the <https:endpoint> to function. In this example we are using the default values from the Mule Studio 3.4.

The <https:endpoint> defines the required configuration for connecting to your ServiceNow instance. E.g. address, username and password. Is also refers to the connector which defines some of the connection information (e.g. timeout).

After starting the mule application, I can make web service calls to ServiceNow using unencrypted HTTP calls without username and password information via my local MuleESB proxy. See the example picture below which is taken from SOAP UI.

Conclusions

MuleESB can be used as a proxy between ServiceNow and other systems, and configuring the Mule Application for the task is not rocket science.

Can you do the same by using other tools? Certainly, but how many of those tools are as versatile as MuleESB and cost as little (nothing unless you buy the supported Enterprise version)? MuleESB is a lot more than mere proxy even though it can be used as one.