There are two different SOAPClients in the codebase :
the WISE SOAPClient : http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/ESB_Programmers_Guide/chap-SOA_ESB_Programmers_Guide-Out-of-the-box_Actions.html#sect-webservicessoap-soapclient
the SoapUI SOAPClient : http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/ESB_Programmers_Guide/chap-SOA_ESB_Programmers_Guide-Out-of-the-box_Actions.html#sect-webservicessoap-soapclient-1
It is clear you had problems with one of them - it looks like from your message you were using the soapUI one. If neither work for you, I'd suggest taking a look at the SOAPProxy and seeing if that could satisfy your requirements.
nicolas duminil wrote:
I need to use SOAPClient. And the question was why is its the soapAction mandatory, while the specs say it's optional, and how to invoke a web service defining soapAction="", which is a value not acceptable by JBoss ESB ?
It seems like it is mandatory because it is deriving the operation from the SOAPAction. Obviously that could be done differently (specifying the operation, etc), but that's how it behaves now. If you'd like to see that changed, please file a JIRA.
There are ways to work around this - do a smooks transformation on the request, use the WISE SOAPClient, use the SOAPProxy, etc. If you absolutely need to use the soapUI SOAPClient - and I'm not sure why that would be an absolute requirement - you could add a smooks transformation.
Thanks for the explanations. No, it's not that I want this changed, it's just that I don't understand why an element which is optional in WS-I becomes mandatory in JBoss. The reason I need to use the soapUI SOAPClient is that the project has to choose the soapUI tool as the test tool for every thing which is done here. And one of the reason they have chosen to try to use JBoss ESB is that it uses internally almost the same tool, the soapUI SOAPClient. So it is not my choice and I'm not doing what I want. We are alreay proxying external web services (SAP deployed) and consume them via the soapUI. It works ok with soapUI but not with soapUI SOAPClient as it requires a property which doesn't exist for the target services: the soapAction. So, we are stuck. Our test tool works and proves that every thing is okay but our JBoss ESB, based on the same tool, doesn't. And if we explain to the SAP guys that they need to manage themself such that to give us a valid soapAction, they are laughing and shows us that soapUI is perfectly able to consume their services without any soapAction.
So, what are the options ? I didn't get the idea of transforming the request. To transform it from what into what ? Should we provide a fake soapAction in the jboss-esb.xml file, just in order that the ESB be happy, and transform the SOAP request such that to remove from it the fake soapAction ? If that is the idea, then I don't think we could seriously consider it. Another option,as you seem to say, would be to use the wise client which doesn't require to provide a soapAction property. Is that correct ?
The parameter is the "operation name" of the binding that you want to be used. You can see that soapUI client will create templates for all operations and only one of them you can use at any time, right? SOAPClient mimics that behaviour here. Just that the name of the parameter is called SOAPAction.
Thanks. I know what this parameter is but, in my case it doesn't make sense as a SOAP message to invoke a web service operation looks like that:
So, it's very clear what the operation name is without the need of a soapActiob property. Hence, the WSDL i have to use, which comes from SAP and were a contract-first approach is not possible, doesn't specify the soapAction property. Or, if you prefer, it says soapAction=""; If I'm using the same value on my soapClient definition, ie soapAction="", I have the mentioned exception. If I'm using a fake value, it doesn't work neither because it's a fake value, not corresponding to any operation. If I'm specifying the operation name, like for example GetLastTradePrice, it doesn't correspond to the soapAction defined by the WSDL, which is soapAction="". So, given that I cannot do any modification to the WSDL, this means I cannot call this service using soapUI SOAPClient. Is that correct ?
I want to use the action org.jboss.soa.esb.actions.soap.SOAPClient.
I use the following properties:
It works fine when I invoke a web service that have only one binding, but when there are multiple bindings, it does not invoke the right operation.
For example the wsdl i want to invoke have 2 bindings:
- soapAction: http://xxxxx/CreateUser
- operation: process
- soapAction: http://xxxxx/CreateSubscription
- operation: process
I want to invoke the CreateUser, passing the soapAction="http://xxxxx/CreateUser", but ESB always invoke the create subscription...How that work? It is a bug? There is some magic parameter to specify?
Method overloading is not allowed as per WS-I Basic Profile. The underlying JBossWS stack confirms to this requirement.
Thanks for the response, but it was obviously that there are 2 port type, each port type have its binding with its operation.
The wsdl is 100%valid with altova xml spy, and each operation work as expected with soapui.
So again, how to call the right operation with this JbossESB using the action org.jboss.soa.esb.actions.soap.SOAPClient?