SOAP integration - best (or common) practices

[Jamsta1912]

Hello all,

I'm working on a bi-directional integration with a supplier's system, using SOAP web services. The integration is for incident managment (so, transactional exchanges only - no bulk CMDB data transfers or similar).

I'm after some general pointers for best practices. I appreciate that some of these points/question may already have been answered adequately elsewhere in the community.

I'm using basic authentication on messages inbound to our system, and I have ACLs set up so that the user representing the third party system can only do what it needs to be able to do. So far so good. However, is this usually considered enough? I'm concious that this doesn't restrict 'where' the messages are coming from. Is there a way to do this by IP Address range for instance, for the specific user only? I've used IP Access Controls before, but these are not user specific.

I'm concious from reading around, that a lot of integrators use an additional gateway or integration layer, one step removed from the target systems at each end. Is this considered better than just using web service import sets at each end? For a ServiceNow to ServiceNow integration, is anything other than directly system to system unnecessary?

What is the best practice regarding synchronous / asynchoronus messages? My set up so far is synchronus. Is it an advantage to use asynchronus messages, and if so, how does the ECC queue then fit in, and is the ECC queue not relevant for synchronus messages.

Any pointers, greatly appreciated.

Jamie.

[venkatiyer1]

Hi Jamie,

Will try to answer some parts of your question.

One way to make it IP specific is to use a midserver and apply IP address capabilities in it. So that way we can ensure it is IP address specific and make a rest call using that server. Whenever you use a MidServer it will update the ECC queue. You can surely ECC queue and run a business rule to update or insert the record asynchoronusly as well. In my opinion, I would do asynchoronusly unless there is a real requirement for data as in the rest call is a part of workflow.

[Jamsta1912]

Hi Venkat,

Thank you for your reply. Does this apply to SOAP as well as REST?

If I understand correctly, I will need a MIDserver in order to do this asynchronousply (as well as to add IP controls). Is that right?

Jamie

[Atul Kumar2]

Hi Jamie,

Yes it does apply to the SOAP as well as Rest.a

Here is one point i would like to make.

Inbound Direct web services are the synchronous however if you create inbound web service import set then you have the option to set the import set as asynchronous.

Mid server is used when external user is behind the firewall, so for the best data security we use.

Here is the flow related to mid server.

External user > Mid Server > Firewall > Service NOW instance.

External user will have to open their firewall to make a request to the snow instance. its story of web service related to mid server.

I dont think you need to use mid server for that because of additional support overhead, you can create asynchronous web service import set and define the ip access control and it will suffice your requirement.

Hope this helps.

Regards,

Atul Kumar

[Jamsta1912]

Hi Atul,

Thank you for your advice.

The user (third party system) is behind a firewall and they have opened up their firewall in order to make a request to our ServiceNow instance.

I'm still a little confused though... would the Mid Server be behind their firewall, ie on the third party's own network? But, if a Mid Server is not needed in our case, as you suggest, I won't worry too much about this.

I will be using an asynchronous web service import set, but how do I define an IP access control that relates just to this one user?

Jamie.