OSB Dynamic service call or dynamic route and transactions

Question

Hello,
I've got the following problem in my OSB architecture for asynchronous incomming services.
OSB version is 10.3.1
ConnectionFactory is XA
Problem domain:
Dynamic service call or dynamic route within transaction boundary
Elements within transaction:
1.     JMS Queue ->
2.     Upper Proxy Service (De-queue) ->
3.     Lower Proxy Service (Canonical Service) ->
4.     Business Service (Data Service) ->
5.     Database Adapter->
6.     Database
Dynamic element
Upper Proxy Service (De-Queue) must be able to determine which Lower Proxy Service (Canonical Service) has to be called on the basis of the message taken from the JMS Queue without losing the transaction (this doesn’t work yet).
Already tried possible solutions:
•     Make a service call dynamic by setting the $inbound name attribute. This results in a this property is read-only error.
•     Use a Dynamic route instead of a service-call. This results in a loss of transaction. The message is deleted from the Queue without taking failure or success into account.
•     Use a Dynamic route with a quality of service set to exactly once in the header. This seems to be ignored, results in a loss of transaction.
•     Use a Dynamic route with an explicit reply with failure for errors. Results in a loss of transaction.
•     Use a Dynamic Publish. This doesn’t fit the required flow because it has no response.
I hope someone can shed some light on this because I'm at a total loss. I found some references in the forum to what seems to be the same problem but without definite answers. A work-around is also a viable answer.
Regards,
Bas Mul

Answer 1

Hi,
I'll try to clarify.
Upper proxy dequeues a message.
Depending on a value of a specific tag within the message a canonical proxy service (out of 5 at the moment but this numer could increase) has to be called (and be dynamic transform transformed to the format of the specific canonical).
The canonical service must then pass the message to a database adaper's business service which is responsible for the database insert/update/read.
If something in the chain from dequeue to database action goes wrong the message may not dissapear from the queue.
Somehow a dynamic route in the message flow between dequeue proxy and canonical proxy breaks the transaction.
Bas