HTTP Headers in SOAP calls


Is there a way to control the complete path that WM posts to when consuming a webservice? I have tried both the soapClient and soapHttp, but I cannot find anyway to control the http headers.

This is a dump of the http headers that I captured calling the webservice
in webMethods:

User-Agent: Mozilla/4.0 [en] (WinNT; I)
Accept: image/gif, /
Content-Type: text/xml; charset=“utf-8”
SOAPAction: “”
Content-Length: 963

Here is a dump of the http headers using a different soap client that is able to successfully call the webservice.

POST /webapp/wcs/stores/servlet/BalanceInquiry HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: IBM WebServices/1.0
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: “[URL]Bing
Content-Length: 772

What leads you to the conclusion that the contents of the http header variables is a problem? You can populate SOAPAction in the pub.client:soapHTTP if you are calling an ancient service provider that still requires that header.

Can you use a tool such as SoapUI to confirm your theory that the issue might be with the http headers? I personally doubt that is the case unless SOAPAction is required.


I have been going back and forth with the service publisher. Below is their query to IBM Commerce support. Their position is that they cannot allow access on ther root node. Because they can access the service with an IBM client I cannot just say that the wsdl is screwed up or that they need to set up a virtual directory. They just keep telling me that i need to specify they full path in the HTTP Post header…

Service Providers response:
If we send the request to our server using the IBM test client it works fine we can send it to directly to the application servers http port or through the web web browser. We have an external client who is sending the request via either method and all we get is a commerce command not found error in the system out log. Both the client and ourselves are using the attached wsdl file. When he sends it to the http server in the access log all I see is a POST / and no other url parameters so I believe it is something on his end but this is our first time using services within commerce so I am not sure what is and isn’t accepted as far as User-Agents. If you look below you will see that is where the major difference is.

BTW I have been using soapUI v.2.0.2 along with webMethods. webMethods just returns a useless error message. soapUI returns an Html page with equally useless information, but at least you can see something: Generic Application Error Test JSP (Item) blah, blah, blah…

CMN3101E The system is unavailable due to "CMN1654E". There is a problem with the input "{0}".

I would assume that you may not be using the correct service endpoint or that, if SOAPAction" is required, that you are not sending the correct value.



Thanks for all you responses. It turned out to be one of those situations where the client gets to debug the publishers code. Bottom line is there were multiple problems with the wsdl, once those were corrected the endpoints resolved as expected. No need for the soapAction header either.