Issue associated to the forum thread: BC-SOAP does not forward the error message
I have an external webservice with methods defined as InOnly. If I invoke a method with correct arguments in the SOAP Enveloppe, it returns only (which is correct) : {{HTTP/1.1 202 Accepted Server: Apache-Coyote/1.1 Content-Length: 0 Date: Mon, 06 Aug 2012 08:09:29 GMT Connection: close }}
It works also fine thru bc-soap provider and consumer on Petal 4.
{{HTTP/1.1 202 Accepted Content-Type: text/xml; charset=utf-8 Connection: close Server: Jetty(6.1.9) }}
BUT, if the SOAP enveloppe is missing something, Petals also returns an "{{http 202 : accepted" HTTP/1.1 202 Accepted Content-Type: text/xml; charset=utf-8 Connection: close Server: Jetty(6.1.9) }}
whereas the real webservice gave the following ( correct ) error
{{soapenv:Sender Validation error cvc-complex-type.2.4.a: Invalid content was found starting with element 'ns:contextId'. One of '{"http://server.domain/endpoint/1.1":procedure}' is expected.}}
According to http://www.w3.org/2002/ws/addr/testsuite/exchanges/#SOAP12-HTTP-In-Only-Fault, it should return the http-status AND the fault
I cannot change the wsdl to mark the method InOut as the webservice I invoke is defined by our customer without return message.
It would be really nice to have the choice of validating (or not) the SOAP data with the WSDL at the consumer side of Petals.
But in JBI, InOnly only returns an ACK to acknowledge that the message was received. The translation between web services and JBI (Petals) is handled by the SOAP component. And obviously, this part is not correctly handled right now for your use case (I am surprised too).
Vincent Zurczak asked me to report this bug on JIRA
Bug
New
Blocker
IMO:
I think that the InOnly pattern of the JBI world is designed for non blocking calls. The consumer sends its request to its provider. The provider acknowledges the received message and process it (if an error occurs, the provider MUST provides a retry system). The consumer can continue its execution during the process of the request on the provider side.
- Only a ACK (Done or Error) can be returned with the InOnly pattern in JBI. No fault is supported by the InOnly pattern.
- So if you have a service provider that does not return customized fault (fault defined in the WSDL), you can use the InOnly pattern, the error should be transformed in a generic fault on the consumer side,
- If you have a service provider that returns customized fault, you MUST use the pattern RobustInOnly
- RobustInOnly is the good choice to map to the one-way pattern of WS
I think that the InOnly pattern of the JBI world is designed for non blocking calls. The consumer sends its request to its provider. The provider acknowledges the received message and process it (if an error occurs, the provider MUST provides a retry system). The consumer can continue its execution during the process of the request on the provider side.