Forum Stats

  • 3,758,243 Users
  • 2,251,358 Discussions


Manual recovery in case of Custom Fault

DasN Member Posts: 24

hi all,

My scenario here is I am querying a database table to get a specific column value.If the column value is NULL i have to retry after some time.After all the retrials(in my case 3 at an interval of 2 min) if the column value is still null my BPEL instance should go to recovery from where it can be retried whenever required.

My approach:

1.Select Query on database

2.Check the column value in IF block in BPEL

3.If column value is returned NULL ,WAIT activity waits for  2 minute then Replays the scope again and the process repeats 3 times

4.After 3 retrial I am throwing a Custom fault(declared in my BPEL WSDL) using THROW activity

5.My fault policy is set to catch this custom fault and should send the instance to recovery.


This is not the actual code.Just created to explain the approach.

My fault policy snippet below.This has been manually modified as custom fault was not directly available to select.Fault policy is attached at composite level and working fine when tried with binding/remote fault.


But Problem is my fault policy is not getting fired when the Custom fault is thrown.Is this the right approach?Is the fault policy should get fired in this kind of approach?

Or any better to handle this?

Thanks in advance!!!!



Martien van den Akker


  • Martien van den Akker
    Martien van den Akker Member Posts: 2,776 Bronze Crown
    edited Sep 14, 2018 9:47AM

    Hi DasN,

    It would not work this way. The fault policy is meant to catch and handle infrastructural exceptions (service invocations etc.) before the fault reaches the process engine. So if an exception is handled in the infrastructure, by the fault framework, for the BPEL process it is as if the exception never happend. Only with a rethrow action it will pop-up in the BPEL layer and can be catched and handled.

    If you do a throw of an exception in BPEL it is raised in the BPEL layer it occurs on top of the infrastructure layer. And it might propagate up until it is handled or reaches the BPEL Engine unhandled. But it won't fall  down into the policy framework. In other words: you can't catch BPEL faults in the fault policy layer.

    That said, what might work is if you abstract the scope into a separate synchronous BPEL process based on a separate wsdl, where you add a soapfault. You might need to put it into a separate composite. In the 'child' BPEL process then you can raise the SoapFault. The 'Parent' bpel would invoke it through a service reference.  Then the soapfault can be catched in the fault policy framework when you bind it to the service reference.

    I haven't tried it myself, but that could work (no guarentees here).


  • DasN
    DasN Member Posts: 24
    edited Sep 25, 2018 4:50PM

    You are bang on Martein. So I just made it simple.My aim was to send the instance to recovery.So I added a post assertion check on the Invoke activity and throw a fault from Invoke itself and then used a WAIT and REPLAY activity within the catch block .So fault policy is not in use.

    Martien van den Akker
This discussion has been closed.