Hello everybody, this is my first post, thank you for having me.
In the web.config file for the SOAP API there is an entry where details of the REST Transaction service are entered.
That's the bit where you put in the TRANSACTION_SERVICE_URI, SERVICE_USER_NAME, SERVICE_USER_GROUP, SERVICE_MACHINE_LOCATION and ENCRYPTED_SERVICE_PASSWORD
The SOAP API deployment guide tells us ...
Normal 0 false false false EN-GB X-NONE X-NONE The REST API makes calls to the Transaction service in the REST API.
...
Could anyone fill me in on what it actually uses the Transaction Service for ?
What would be really handy would be a list of SOAP API calls which use REST and what they use it for.
Any guidance gratefully received
Aryaguna
Hi Aryaguna,
At the moment the transaction services are used for the interceptor layer. You can configure pluggin code to be executed when an order is save or when a contribution is save. You can also trigger the interceptor layer by making a get call to the service .
Jon
Thanks Jon
Does that mean that the configuration in web.config (for the transaction service settings) is effectively optional? - providing we do NOT use any interceptors of course. Our website (3rd party code) uses PHP to make the SOAP calls and I very much doubt it uses interceptors.
Could you point me to any interceptor layer 101 material - just to see what we're missing out on!
Many thanks
The transaction services need to be setup , because Tessitura makes a call out to to them. You do not have to have the interecptor layer turned on for that service. I would look at the rest api document for help with interceptors. That is where I started. If you need any help or run into any issues let me know.
On another note I was thinking of posting to the network maybe a training video on them. Thoughts?
Hi Jon
Sorry, I just want to get this clear in my head, which takes a bit of banging sometimes. When you say 'The transaction services need to be setup , because Tessitura makes a call out to to them. ' do you mean the Tessitura clients or the SOAP API?
We have a test V11 system with a fully configured and working REST API and the Tessitura clients are happily working with it.
We have a test PHP code 3rd-partywebsite that makes calls to our inhouse test v11 SOAP API which does NOT have the settings for the REST transaction service correctly configured within the SOAP web.config as yet (it's just left with the defaults).However, the test website seem to work OK without it !Would you expect that ? Do we strictly need that SOAP web.config configuration for the REST TransactionService or can we safely do without it. If not, what would the REST TransactionService be used for within SOAP if we're not using interception? Are there some SOAP calls or something else that you would expect to misbehave without it?
Thanks
Chris
Unknown said: The transaction services need to be setup , because Tessitura makes a call out to to them. You do not have to have the interecptor layer turned on for that service. I would look at the rest api document for help with interceptors. That is where I started. If you need any help or run into any issues let me know. On another note I was thinking of posting to the network maybe a training video on them. Thoughts?
To try to clarify the need to configure the settings for the REST TransactionService in the V11 Web API web.config file...
As Jon correctly stated, the SOAP API does make a call to the REST TransactionService during the Checkout family of calls solely for the purpose of allowing an interceptor to be fired that could invoke some custom logic.
It was our intention, and is our recommendation, that the Transaction Service values be correctly set up in the API's web.config file so that things would work as expected if/when custom code might be deployed. That said, we also wanted to avoid the SOAP API to be unnecessarily dependent on the REST API (at least at this point), so the call to the TransactionService is wrapped in a try/catch so that a failure won't stop the checkout itself. Because of that even if you don't set up correct values the SOAP API should continue to work as expected.
Hi Ron
That was exactly the information I was asking for and also the answer that I wanted to hear. Thanks a million.
We have very tight network routing between our soap api server and other machines and that's one less route to have to think of, phew!
If you look in your crystal ball, any idea of when or which version you think it will be when the whole of the web's needs would be achievable with REST only ?
Thanks again