Extend Invoke-Catch test cases
vanto opened this issue · 10 comments
The current Invoke-Catch testcase seems to a corner case.
- the soap fault sent by
TestPartnerServiceMockis throwing abetsy:CustomFaultbut this fault is not declared in the partner WSDL. - the soap fault sent does not follow the style recommended by WS-I BP 1.1, which prefers so set the faultcode to
soap:Serverand add a details element which contains additional information.
I believe the most standard test case would be a declared fault and a details element. But it would also be interesting to see how engines behave for all permutations of the options above.
Actually, a valid question is also whether the spec requires engines to catch an undeclared fault within an invoke activity. There are some implementation specific counterarguments, like for instance accepting checked exceptions is fine and processed without manual intervention whereas an unchecked exception could suspend the process, giving admins the chance to trigger a retry.
The BPEL spec is unfortunately not very precise.
In the case of a request-response invocation, the operation might return a WSDL fault message.
My interpretation is that the operation might return a fault message, and this fault message is a WSDL fault message, which would imply that it is declared.
Same holds true for Invoke-Sync-Fault. It is also testing a rather uncommon, if not invalid scenario.
We also had a discussion about this topic on the bpel-g mailing list, see: http://code.google.com/p/bpel-g/issues/detail?id=71
As you said, the specification unfortunately is not so clear on this issue. For this reason, we decided to keep the test cases you mentioned and also added a test case that catches a fault declared in the WSDL, Invoke-Catch-ExplicitFault.
Still, I should take a look at the WS-I compliance of the undeclared fault. Thanks for bringing this up!
I have some interesting observations: The non-declared fault we were catching in Invoke-Catch and Invoke-Sync-Catch so far had a wrong faultCode, but it was identical to the name of the fault defined in the WSDL. For that reason, it seems that some engines were able to catch it. Once you change the faultCode to something that is not found in the WSDL, no engine catches it. So, the tests succeeded out of pure coincidence.
I'll change the Invoke-Catch and Invoke-Sync-Catch test cases to catch the declard fault and replace Invoke-Catch-ExplicitFault with something like Invoke-Catch-UndeclaredFault to also capture this. Since not so many engines support a catch nested in an invoke anyway, I probably should also add a faultHandler test case to check this.
Yet Another Observation: Once you add something in the details element of the fault and try to catch that in BPEL, some engines succeed. So we can replicate the situation with the custom non-declared fault in a WS-I compliant manner.
The changes are implemented as of commit dd1cfe8
To be sure, I'll trigger a full test run overnight and see if everything is fine.
The nightly build looks fine, so I'll close this issue.
Thanks! Interesting observations indeed :) Actually I find it interesting that there are so many ways to do the SOAP Fault handling wrong, which is somewhat paradox ;)
The same problem holds true for the CatchAll testcase. Although a catchAll shall catch all faults, at least ODE distinguishes between faults and failures. The latter comprise network problems as well as undeclared faults. Such cases force ODE into activity recovery, which is a feature to give admins the possibility to retry such failed activities. I understand that Betsy should not care about such implementation specific features, but for the sake of completeness it should also provide a CatchAll for both, declared and undeclared faults.