I have created a one way operation in Websphere Process Server and expose the operation as a webservice export binding from there. I use the generated WSDL to call the Process from websphere message broker using SOAP Nodes(SOAPRequest).
But due to some unknown reason, I get back a Response from the one way operation because of which I get back the following error:
A SOAP Request node received a response message body when one was not expected as a OneWay Messsage Exchange Pattern (MEP) was being used. The HTTP Request was made to the destination ''http://<ip>:9080/PEDModuleWeb/sca/RetrieveSecNumberExport1''. The HTTP Status-Line returned was: ''HTTP/1.1 500 Internal Server Error''.
It is an error for a remote web server to return a payload when the selected operation is a One-Way MEP.
Attaching the WSDL file as reference
Any suggestions please.
Thanks and Regards,
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
2 replies Latest Post - 2012-12-12T22:58:02Z by email@example.com
Pinned topic One way operation sending back Response causing error in SOAP Nodes
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-12-12T22:58:02Z at 2012-12-12T22:58:02Z by firstname.lastname@example.org
SystemAdmin 110000D4XK4179 PostsACCEPTED ANSWER
Re: One way operation sending back Response causing error in SOAP Nodes2012-12-09T14:51:01Z in response to SystemAdmindid you find any solution .. I'm facing the exact same issue,
but I believe its not related to the backend server.. as I have tested it with mock service, the thing is that the request node fails to send the request to the backend
email@example.com 120000CJSH515 PostsACCEPTED ANSWER
Re: One way operation sending back Response causing error in SOAP Nodes2012-12-12T22:58:02Z in response to SystemAdminThe error is very clear - the SOAPRequest node got an unexpected reply. I would guess that the solution involves trapping the exception in the message flow and writing some error handling / recovery logic.