Can't you add on the main scope all the catch branches you need, and in every scope of your bpel process you decide which fault you want to throw?
like that you can throw the fault from every location in your process, catch them on main-level and execute the logic over there
if you also have several faults defined in your wsdl, you could reply back on every fault in every catch
or did i misunderstood your question/problem ?
Thanks for your suggestion, Eric, but my problem isn't with creating the catch branches themselves, it's with creating custom faults in async BPELs. I can return custom faults via fault callback ports, but what Id like to achieve (if possible) is to handle some business faults in catch barnches.
I hope I've made my requirements clear. If not, please let me know if I need to elaborate.
not sure if this is of any help :
but what type of fault do you want to return? a fault which isnt defined in your wsdl ?
Thanks for the bolg, but it speaks of fault policies in a synchronous BPELs, whereas my requirement is handling of business faults in async BPELs.
Additionally, Jdev isn't allowing me to create a soap fault in my WSDL for async BPELs. I get this message if I try:
oracle.bali.xml.model.XmlInvalidOnCommitException: SEVERE: Element wsdl:fault not expected [ node = wsdl:fault ]
hm you're right
and this :
when you define several operations in the callback port ?
in your proces logic you could either define 1 catch per callback operation, or 1 catch all and in their use some sort of switch to decide at which callback operation you do the reply (callbackFault1, callbackFault2, etc)
or is this still not tackling your problem ?
Apologies if this come across as my being dense, but how do I associate a catch branch with a callback operation when I can't define a
wsdl:faultelement inside it? I think I'm making a muddle of explaining my requirement to you, so I'll try again:
I have an asynchronous BPEL process that needs to handle some business faults within itself(not return to the caller), and I'd prefer to do this via a catch branch, similar to the approach followed for synchronous BPEL processes, where we can define the business faults as
wsdl:faultelements inside the synchronous operation within the WSDL and associate the each of these faults with a catch branch. Since in an asynchronous BPEL process, we can't define a
wsdl:faultelement due to the fact that the input and output are in separate
wsdl:portTypeelements and are treated as one-way operations.
you say "not return to the caller", what's the use in thise case to define those faults in your wsdl interface?
if you only want to handle the fault locally in your bpel, you can just throw a fault, catch this fault (so you can throw several faults, and catch several faults), execute the logic over there, and then i guess you don't want to inform the "invoker" of your service about what happened.
if you do want to inform him, you just define several callbackports for every business fault, or 1 business fault which defines all your "functional faults", but either way, you "inform" your invoker a error occured by responding him back on the callback port
so either callback on "callbackSucceeded" or "callbackErrror", in this case the invoker will have to be able to receive both callbacks
maybe these links help a bit :
in the last article the writer defines "ClientCallbackFault" in the wsdl, you can do too for every fault you want to reply back
the invoker of your service need to be able to recevie on the ClientCallbackFault port