I am using webMethods 6.5 version and SOAP Msg/Literal web serivces. webMethods is the web service provider. Though the web service invocation from external system and further processing is going well, Integration Server is generating the following one or both error messages intermittantly:

1. SOAPException: [ISS.0088.9134] Exception occurred while processing the body of the message : {0}
2. SOAPException: [ISS.0088.9119] SOAP Processor did NOT return a valid SOAP Response

Sometimes I get only error 1 also, but almost fo the same the code. I following the following steps for asynchronous web service call.

pub.soap.utils:getBody
pub.xml.xmlNodeToDocument
pub.publish.publish (publishing the doc to the Broker)
pub.soap.utils:createSoapData

I used pub.soap.utils.addBodyEntry service also, I think it is mainaly required for synchronous web service calls but may not be for asynchronous, but the same error(s) are coming up (even though I am able to get them, process them to target system format etc.) in server log.

The external system is expecting HTTP 200 status code and if it doesn’t get and for any exception it tries to resend the data. So duplicates are coming now due to these errors.
Could anybody please tell me how to fix this issue? I spent a lot of time searching for fixes and in wmusers but didn’t get the right working solution.
I think if I can send explicit status code also that is better but I am not sure how to send it other than through soapResponseNode.
Please help me in this regard. Please let me know if you need any further information.
Thanks.

Any help on this, please?

By specification, a soap fault will not return an HTTP 200 OK response, but a HTTP 500 Internal Server error instead.

If you implement a try-catch sequence in your Flow service exposed as a web service you can trap any exception, communicate the error condition in your response message (assuming there is a structure for doing so) and the Flow can end successfully avoiding the soap fault and HTTP 500 error.

This is appropriate for some types of functional errors (requested ID does not exist, etc.), but usually you will want to throw an exception that will result in a soap fault for infrastructure errors such as can’t connect to database.

The consumer should not blindly retry a request when receiving a soap fault. That could result in a flurry of requests similar to a denial of service attack.

HTH,

Mark

Thank you very much, Mark. Sorry for the delay in acknowleding.
My issue got resolved now. I found that the namespaces used in given WSDL and in the code (xmlNodeToDocument) were different. Apparently somebody changed in our team after giving the WSDLs.