Petals BC SOAP

This issue must be divided in two parts. The first part is a new feature, the second is a bug. Please create a new issue for the second part.

For the first part, a solution could be to use an XSL provided by the SU. This XSL will generate the header from the message content. Header generated from an XSL and the static header must be exclusives.

I created "PETALSBCSOAP-31" for the second part of this issue.

For the first part, I wanted to make clear that we don't have such a use case for now, but I think it could happen later (or in another context), that's why I reported it. So it up to you to provide the solution you think to be the best for your product. I agree: an XSL applied on th emessage could be a good solution: flexible enough and efficient. However I don't really agree with the idea of having this XSL and the static headers in the jbi.xml beside. I think all could be assumed by the XSL and the solution would be clearer (only 1 place to set up headers). But again, this is only my point of view.

New updates: with now have a use case where we need to set up dynamically the SOAP header.

However we realized that the solution consisting in using an XSLT to generate the SOAP headers is not sufficient. Indeed when the flow arrives on the SOAP provide (where the XSLT would be executed) the message has changed and we don't have anymore the needed content to create the headers.

We need global solution to manage headers at any time of the flow. We think that the proper way would be to be able to set up at any point of the flow the "javax.jbi.messaging.protocol.headers". Then the question is : on what BC/SE would it be possible to set up these jbi properties: maybe a specific SE for editing jbi properties?

Then the SOAP provide instead of injecting static headers would only generates the SOAP header with the content in the jbi properties. Then the question is: how to render XML structure in the jbi property?

This solution would solve the 2 parts of this issue, the first as evoked above, and the second because if there was already headers in the incoming request, there would be set in the jbi property by the SOAP consume and then treated as any other header information.