Web service call - getting soap fault "Premature end of

Eclipse (and Sonic Workbench) comes with a TCP/IP monitor.  You would have it proxy the external service and call it locally.   That is, configure localhost:8080 to go to your external webservice and then simply use your ESB service to go to the local URL.

Hi William,

Thanks for the reply.

I captured the soap request through TCPMon. It has got a header "Transfer-Encoding" with the value "chunked". Looks like this is what is causing problem.Is there any way we can instruct sonic to send the soap request at one go?

Regards,

Subhendu

You said you were not using the ESBWS file, so Sonic is not managing the SOAP request.   Maybe I misunderstood your original post, but it looked like you were saying that Sonic's web stack is not being used and that you wrote a custom service for the web request.

smahanta wrote:
[we use a] simple java service type to invoke a web service call. We are not using webservice invocation service type (*.esbws)

Hi William,

You understood me correctly.Sonic's web-stack is not being used.

Are you suggesting that if we use sonic's web stack, the web service call will be sucessful?

Most peculiar thing is this was working correctly couple of months back. Only thing that has changed is that we have deployed it to a different machine & now it is deployed through SDM(Sonic Deployment Manager).

Regards,

Subhendu 

smahanta wrote:
...Are you suggesting that if we use sonic's web stack, the web service call will be sucessful?
[snip]

I think it should work.  I don't recall any issues with Web Services that use chunked encoding (but this is normally specified by the client, not the server).    My point was more this:

  "If you are writing the web client yourself, then no Sonic setting would impact the behavior of your code."

smahanta wrote:
[snip]
Most peculiar thing is this was working correctly couple of months back. Only thing that has changed is that we have deployed it to a different machine & now it is deployed through SDM(Sonic Deployment Manager).

SDM is just a deployment mechanism.  As long as the environment is the same, it should not matter how it was deployed.  So, this is unlikely to be an SDM issue but I would check:

• Compare the working version (deployed) to the SDM version (deployed) and see if the same Jar files are in the classpath and that they are used.  That is, is your SDM model matching the non-SDM deployment.
• Try redeploying manually to the container without using SDM --- Do the same techniques that worked on the old working system work on the new system?
• Are there any other changes?
  • Does the old service still work? (i.e. has the Web Service changed)
  • Are you using the same Sonic version? (i.e. were you relying on classes in the ESB .car files that have changed without your notice)
• Is the host network configured similarly on the working container, and the new one?  It might be a networking issue.
• This does sound like a configuration issue (given that it works from another container, and not on a new one).   If you can't fix it, I'd look at using an ESBWS call, but that would be a rewrite, and first try to figure out where your custom code is making assumptions that aren't stable.
  

Hi William,

Thanks for the help.

I added following lines in the stub to turn off transfer-encoding chunked:

         Hashtable httpHeaders = new Hashtable();       
        httpHeaders.put(HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED, false);
        _call.setProperty(HTTPConstants.REQUEST_HEADERS, httpHeaders);

And it is working for the particular web service which was not working.

So your suggestion "has the Web Service changed?" may be true.

Regards,

Subhendu