I have been working on segmenting our internal and external SOAP/REST traffic using two servers . The internal server will handle all internal-originating calls (Impresario Client, customizations that access REST/SOAP, etc). The external server will handle all web-originating calls (and live in a DMZ). I have completed with the setup; however, ran into a snag.
In t_defaults there is an entry for REST_SERVICE_URI, which is used by the SOAP API when SOAP needs to access REST (when this occurs exactly, I am not sure). My issue is that I really need two REST_SERVICE_URI entries, one to be used by internal REST and one by external.
Via support, Tessitura told me that "a second instance of the SOAP API is not necessary to run the Tessitura application" and what I am trying to do "falls outside the scope of support" and so must seek assistance here.........
Yet I'm positive others are running w/ segmented traffic similar to this. So, anyone know of a way around the t_defaults entry? Could multiple entries be used? Any help is appreciated.
It may be worth checking if the SOAP API contacts the REST API directly - a network tool like wireshark could let you see if there is traffic direct between the two, or a simple netstat would show if there is a connection made.
I know the calls for pricing, which require the REST API, access the REST API via the DB (using CLR which there was a hotfix for earlier)
If there is direct contact, the there is always the not nice hack of changing the hosts file on those external machines to force the url for the SOAP API to be the specific ip address on the REST and vice versa - although hopefully someone else will come up with something more elegant.
Mark
Yeah, I'd be interested in getting Tessitura's official word on how exactly SOAP interacts w/ REST (specifically in relation to that t_defaults entry), so if anyone from the network is reading this...inquiring minds and all that... :)
To me it seems like you should be able to "pair" REST and SOAP, for the sake of scalability alone. If only a single REST server can be referenced from multiple SOAP servers, that's a decent limitation/bottleneck (depending how this all works of course).
Hi Jason,
After speaking with the development group on this, the answer is that the SOAP API pulls the REST service URL from T_DEFAULTS and just as you are suggesting, this implies that there can currently only be one REST service regardless of how many SOAP APIs you may have. This is an oversight, and one that will be remedied in a future patch. I don't have more information about the nature of the fix, but you will see it in release notes for a future version of Tessitura.
As for the nature of the communication between the SOAP API and REST service, at this time the SOAP API only calls the REST services as part of the checkout process in order to trigger any interceptors you might have running. Let me know if that wasn't what you were after.
Thanks for calling this out, Jason.
This is exactly the info I was after. Thank you for the response and I am glad to see it will be making its way into a future patch!
Since 95% of our SOAP calls are from external website traffic, I'm pretty comfortable with a single REST service servicing both internal and external SOAP services for now.
Only other thing I'm interested in is whether sharing REST like this could cause any problems for either of the SOAP instance? (Assume we have plenty of server resources.)
Thanks!
The infrastructure you are suggesting is not unheard of; there are other organizations that have multiple SOAP APIs and thus must also be stuck with only one REST service, which I have never heard of as an issue in terms of performance, likely because of the limited interaction between them. If you find this not to be the case in your testing, we definitely want to hear about it!
Thanks again.