I've followed these procedures:
Now, as the web service client needs to call the data service more than once inside the same transaction, that is, I need to propagate the transactional context, I changed the proxy service to have SB Transport (instead of http).
The diagram would be:
ws client <--> [ (PS1, sb transport) -- (BS1, dsp transport)] -- [ODSI] -- [Data Sources]
Is this use case supported?
I tried to consume the data service (through PS1) using the mediator API (exported from ODSI) and got the following error, after changing the transport type of PS1 (from http to sb).
Caused by: java.net.MalformedURLException: unknown protocol: sb
... 39 more
I looked for a way to try to set the client transport type in the ODSI API with no success.
Thank you in advance,
1) You're using the ODSI ws client to call an sb protocol proxy service. That doesn't work. The ODSI ws client only knows how to call ODSI webservices (or webservices that look like ODSI web services).
2) You would make your life a lot easier if you simple combined whatever you need done in your multiple calls to ODSI into a single data service. But you don't need to.
3) In your picture, it's not clear if the multiple calls to ODSI are done within the same proxy-service call, or if multiple client calls are required. If they are in the same proxy-service call, then all you need is your proxy-service to manage the transaction (an OSB person should be able to tell you how to get that - perhaps it is the default). If your proxy-service is managing the transaction, then it doesn't matter how that proxy-service is being called. But if it requires multiple client calls, then the client has to manage the transaction.
For testing the case of a transaction across multiple ODSI calls within an OSB pipeline, we used a JMS proxy-service. There may be other types of proxy-services that are transactional - check the OSB doc.