Please define mechanisms to allow graceful handling of a partner link exception. This will likely require: - An interceptor that will examine the unexpected failure and provide an appropriate (expected) type to Riftsaw. - A fault handler capable of receiving information associated with a defined element type (rather than a message fault) when a partner link has trouble. It is thought that the WSDL will need to reference the element's schema, rather than declare it as a fault. The BPEL can then expect an anticipated type, which can be interrogated for use in branching logic, etc.
An example of the mechanism used to support this requirement is described in the associated riftsaw jira (https://issues.jboss.org/browse/RIFTSAW-518). The first part of the solution is the ability for riftsaw to handle undeclared faults as defined by element variables. The second part is to demonstrate how interceptors (auditor) in switchyard can be used to convert technical faults into meaningful business messages that can be used by the BPEL process definition to branch.
It seems that a fault variable must have defined faultMessageType to work - but it should be optional (see bug 964987) Because of bug 965037, I cannot verify that the interceptor can convert the technical fault.
Moving back to ON_QA since bug 965037 was closed as not a bug. Ivo, could we have this retested?
There is a problem when the error message is updated in ExchangeInterceptor called BPELErrorHandler. When I send the request SOAP message, I get exception at https://github.com/riftsaw/riftsaw/blob/master/engine/src/main/java/org/riftsaw/engine/internal/MessageExchangeContextImpl.java#L131 that the localName of faultMessage is null and QName local part cannot be null. IllegalArgumentException: local part cannot be "null" when creating a QName at javax.xml.namespace.QName.<init>(QName.java:244) [rt.jar:1.7.0_51] at javax.xml.namespace.QName.<init>(QName.java:188) [rt.jar:1.7.0_51] at org.riftsaw.engine.internal.MessageExchangeContextImpl.invokePartnerUnreliable(MessageExchangeContextImpl.java:131) [engine-3.0.0.Final-redhat-8.jar:3.0.0.Final-redhat-8]
Created attachment 856564 [details] Reproducer for "null" local part in QName (FSW 6.0.0.CR3) The reproduce steps are following: 1) Unzip the reproducer to bpel-service quickstarts in FSW 6.0.0.CR3. 2) Build the reproducer without running tests. 3) Manually deploy the jar file. 4) Send the following SOAP message. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:loan="http://example.com/loan-approval/loanService/"> <soapenv:Header/> <soapenv:Body> <loan:request> <loan:firstName>FirstName</loan:firstName> <loan:name>Name</loan:name> <loan:amount>1000</loan:amount> </loan:request> </soapenv:Body> </soapenv:Envelope> 5) See the exception in the server log.
Created attachment 868598 [details] Updated exchange interceptor I've updated the exchange interceptor to return a SOAP message. The problem was that the BPEL engine needs a fault type, to be able to route it to a fault handler. Once this was fixed, I found that SwitchYard by default sets the transaction to rollback - I think this is when an unchecked exception occurs. This was resulting in an internal Scope DAO being created without its auto-generated id, which resulted in an "java.lang.IllegalArgumentException: id to load is required for loading" exception being reported. To fix this, I changed the ROLLBACK_ON_FAULT property on the exchange, from within the exchange interceptor, and this allowed the BPEL process to continue and handle the fault itself.
Assigning to Ivo to confirm that the example works with the updated exchange interceptor, and to close the issue.
I've verified this bug against FSW 6.0.0.GA, using the reproducer with the updated exchange handler, and it works. The reproducer is a modified version of the loan_approval example, where instead of two BPEL processes being included in the same jar, the called BPEL process is removed and therefore not available to the consuming BPEL process - hence resulting in a 404 when called. The handler exception is intercepted by the exchange handler and converted into a SOAP fault.
This fix was actually included in FSW 6.0.0 so should be verifiable