Dynamic SOAP Endpoints in ServiceNow

General Add comments
by:

images

One of the challenges when creating a SOAP interface is to make sure that each ServiceNow environment communicates with the correct environment on “the other side”. This article provides a fairly simple but effective way to make sure that after committing an update set that contains an update on an outbound SOAP Message or a Clone the outbound messages will still go to the correct instance.
In this example I will use properties to store the external endpoints, but you could also consider a table to store that data.

Step 1: create a bunch of properties for your interface; one for each instance. Example:

Property Value
mysoap.myinterface.mydevinstance https://testendpoint.externalparty.com/
mysoap.myinterface.myaccinstance https://testendpoint.externalparty.com/
mysoap.myinterface.myprdinstance https://endpoint.externalparty.com/


where mydevinstance / myaccinstance and myprdinstance should be the exact names of your instances (this is to make it easier to call the property at step 2). Populate each of these properties with the end Point of your interface for that specific instance. This does mean that the end points of all instances will be stored in all instances.

endpoint

Step 2: Next find the code that will send your SOAP message. This will typically look like:
var soapMessage= new SOAPMessage(‘SOAP Message’, ‘mysoapfunction’);
soapMessage.setParameter(‘parm1’, ‘value of parm1’); // etc.

and add one line of code:
var soapMessage = new SOAPMessage(‘SOAP Message’, ‘mysoapfunction’);
soapMessage.setSoapEndPoint(gs.getProperty(‘mysoap.myinterface.’ + gs.getProperty(‘instance_name’)));
soapMessage.setParameter(‘parm1’, ‘value of parm1’); // etc.

This way the system will automatically find and use the correct end point. End Points set in this manner will overrule the end point that is set in the SOAP function. To avoid confusion I typically set those endpoints to “from_property”.

step 3 (optional): for Dynamic Security:
If needed, you can also dynamically set the User and Password for Basic Authentication using the following code:
soapMessage.setBasicAuth(username, password);
or even WS Security:
soapMessage.setWSSecurityInfo(keyId, keyAlias, keyPwd, certId);

Since you’re in the process of storing passwords, you could also consider to do it for the inbound interfaces, so you make sure that the inbound passwords are also stored, so the inbound traffic will not be affected by a clone or update set either.

Obviously you need to be a bit careful when storing a password for a production interface in a development instance.

I hope this blog article is helpful. If you have questions, please let me know!

Good luck!
Kind regards,
Martijn Odijk (.img[at].img)

Leave a Reply