Catching and rethrowing a SOAP Fault from an OSB 11g Proxy service

Question

Hello,
We have a chain of proxy services (that last one of which calls a business service) in our 11.1.1.6 OSB project.  At one of the lower levels, we successfully throw a fault like this:
<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Fault xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:faultcode>SOAP-ENV:Client</soap:faultcode>
    <soap:faultstring>Non-Existent User</soap:faultstring>
    <soap:faultActor>Client who consumed this Web Service operation</soap:faultActor>
    <soap:detail>
      <sc:UserNonExistentFault xmlns:sc="http://xmlns.sc.com/Services/V1">
        <sc:CustomerNumber>12345</sc:CustomerNumber>
      </sc:UserNonExistentFault>
    </soap:detail>
  </soap:Fault>
</soapenv:Body>
In the proxy service which calls this proxy service, I tried to catch this fault in an Error Handler so that I could confirm that it's available for me to re-throw back up the chain.  Curiously, the proxy service which calls that proxy service cannot see that fault.  But rather it sees what appears to be an OSB-overridden fault:
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
  <con:errorCode>BEA-380000</con:errorCode>
  <con:reason>com.bea.wli.sb.pipeline.PipelineException</con:reason>
  <con:details>
    <err:ErrorResponseDetail xmlns:err="http://www.bea.com/wli/sb/errors">
      <err:response-metadata xsi:type="sb:SBResponseMetaDataXML" xmlns:sb="http://www.bea.com/wli/sb/transports/sb" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <tran:headers xsi:type="sb:SBResponseHeadersXML" xmlns:tran="http://www.bea.com/wli/sb/transports"/>
        <tran:response-code xmlns:tran="http://www.bea.com/wli/sb/transports">1</tran:response-code>
        <tran:encoding xmlns:tran="http://www.bea.com/wli/sb/transports">utf-8</tran:encoding>
      </err:response-metadata>
    </err:ErrorResponseDetail>
  </con:details>
  <con:location>
    <con:node>PipelinePairNode</con:node>
    <con:pipeline>PipelinePairNode_request</con:pipeline>
    <con:stage>GetCustomerByNumber</con:stage>
    <con:path>request-pipeline</con:path>
  </con:location>
</con:fault>
I have tried printing out the values of $body, $fault, $outbound and $inbound from the calling proxy service's Error Handler just to see if our <sc:UserNonExistentFault> is nested anywhere therein.  Unfortunately, it is nowhere to be found.
How can we force OSB to NOT override our faults with OSB-framework faults and, instead, just throw our custom fault all the way up the chain and back to the consumer?
Thank you,
Michael

Answer 1

I think I figured this out.
In proxyService-2, build the <soap:Fault> and assign it to the body, then Reply with Failure (as you mentioned above).
When proxyService-1 receives this, it will still be in the $body variable.  But the $fault variable is now populated with a BEA-38000 error.  It seems that as long as the $fault variable has data in it, then the OSB system will throw that instead of my fault (ignoring the <soap:Fault> I put into the body).
So what I did was to Delete the $fault variable in the error handler of proxyService-1, then Reply with Failure (again).
It would seem as if the inner workings of OSB has some logic like:
if $fault is not null, throw the BEA-####### fault.  Otherwise, return the contents of the $body.
By removing the fault, I effectively got to that "else/otherwise" condition.
Of course, the Reply with Failure is still needed to ensure that an HTTP 500 error is passed with the fault (per the SOAP specification).
Cheers!
Michael