BPM - How to handle Exceptions / Retry Mechanisms

[andreas_scherf]

Hi all!

I was experimenting with the BPM Exception Handling mechanisms and the retry feature for Business Processes in Status "ERROR" via "SWF_XI_SWPR".

I have the following BP model:

S - R1 - T1 - B1A - SS1 - B1E - T2 - B2A - SS2 - B2E - E

where:

S = Start

R1 = Receive Step (Asynchronous)

T1 = Transform Step 1

B1A = Block 1 Begin (Exception "EXC1" assigned)

SS1 = Send Step 1 (synchronous, System-Exc.= "EXC1")

B1E = Block 1 End

T2 = Transform Step 2

B2A = Block 2 Begin (Exception "EXC2" assigned)

SS2 = Send Step 2 (synchronous, System-Exc.= "EXC2"))

B2E = Block 2 End

E = End

What I want to do is <b>to raise an Alert</b> if EXC1 or EXC2 occurs <b>but I want to be able to retry the BPM "just at the point" ( = Block 1 or 2) where the failure happened.</b>So If Block1 was processed successfully and EXC2 occured retrying the BP should NOT process Block 1 again but should only process Block 2 exactly in the state as before EXC2 occured.

So I tried to add some exception branches to Blocks 1 and 2 and in this adding a control step CS1 which raises an alert. Well now I get the Alerting and the mail - but since the block has status finished the BP-Instance is not marked as "errorenous" - hence can't be retried ...

Next I tried to add some control step CS2 which cancels the process after the CS1. But now the problem is that the BP-Instance is marked as "logically deleted" instead of "error" - hence no retry of the BP-Instance is possible at the desired block.

Next I tried to change CS2 such that it "raises an (unhandled) exception". So I added a second exception to the Blocks 1 and 2 (EXC3 and EXC4) and tried to pick them in the CS2. But I cant write there an explicit exception name and the drop down list including all "available" exceptions is empty?? ...

So currently I have no idea how to implement a active notification via Alerting AND the possibility for retrying a BPM just where it failed!

Many, many thanks in advance for each statement of yours on this issue!

Best regards,

Andy

[Former Member · Accepted solution]

Hi Andreas,

You can try something like this after you raise an alert in the exception branch duplicate the step which has failed in the exception branch after control step so that it stops with the same error..

Now you can correct and restart the BPM using SWF_XI_SWPR and finish the current block.

Something like this..

B1A = Block 1 Begin (Exception "EXC1" assigned)

SS1 = Send Step 1 (synchronous, System-Exc.= "EXC1")

Exception Branch for "EXC1"

CS1 - Control Step

SS1 - Send Step

Exception Branch END

B1E = Block 1 End

Also check this thread

hope this helps...

Regards

Anand

Message was edited by: Anand Torgal

[andreas_scherf · Accepted solution]

Thanks for your input Anand!

However - with your solution, I guess the retry + alerting would work only <b>the first time</b> of the error? The second time alerting is not active anymore.

Also if the error occurs the first time and the exception is thrown (hence alerting is triggered) BUT then the error does not occure in the repeating block (wihtin the exception branch - e.g. temporary network problems, ...) one would get an error-notification saying "something is wrong" but in fact the problem has already been solved by the "built-in" retry mechanism.

The link you provided was also interesting since it seems <b>I am not the only one facing this kind of problem</b>. Joachim Orb was providing "some solution" by <b>looping over the critical parts</b> of the BP - but this is something that looks like a workaround for my concrete problem as well ...

Any additional ideas?

Thanks, Andi

[Former Member]

Hello Andreas,

Thanks for your valuable input! I'll hand over your ideas to the BPM development team.

Best regards

Joachim

[andreas_scherf]

Hi Joachim!

Please keep me (and the forum) informed! I think this is really some "loophole" in XI functionality which can make (project) live quite complicated

Many thanks,

Andi

[andreas_scherf]

Hi Joachim!

Any news on that issue - we would (and I assume

a lot of other XI users as well) need this functionality

very urgently ...

Thanks for your update!

Andi

[Former Member]

Hello Andreas,

Currently error handling has to be done by means of ccBPM modeling techniques. One of these techniques could be using a loop as explained in a previous posting.

Do you have any concrete requirements concerning error handling / alerting? How do you expect the system to react concerning this issue?

Best regards

Joachim

[Former Member]

Hi Andreas,

>>However - with your solution, I guess the retry + alerting would work only the first time of the error? The second time alerting is not active anymore.

Yes, alerting would work only the first time of the error. To give an example , if a mapping step fails in BPM then there is no point in retrying the message until it is corrected manually. Just an alert and restart mechanism would be sufficient for such scenario. Otherwise we will be holding/using the system resources unnecessarily till the problem is corrected.

As joachim mentioned if you have any concrete alert/retry requirements then you can use ccBPM modeling techniques to handle the erros.

Regards

Anand

[andreas_scherf]

Hi Joachim!

In fact I have tried to get behind this BPM error handling stuff the last two days now - currently it seems that the standard-behaviour of XI is that when using "SWF_XI_SWPR" to retry a BP-Instance with status "ERROR" <b>it repeats exactly the step which caused the exception</b>. This is at first sight no bad behaviour except for the requirement that one would also like to have active notification via alerting mechanisms. To achieve that, one could add an exception branch to a block (where the critical steps reside) and add a control step there which creates the alert. But this has the consequence that the failed step now has status "finished" and hence can't be reprocessed.

If one uses two blocks (one outer block and one inner block with the critical step) one could assign a Exception "EXC1" to the outer block and "EXC2" to the inner block. Then assigning EXC2 to a system exception - within the exception branch of the inner block create alert AND raise exception EXC1 (of the outer block). Now both blocks 1 and 2 are at status error BUT if one tries to reprocess the BP-Instance, the current XI behaviour <b>repeats the Control Step that raises exception EXC1 (since this was the "step" which caused the last unhandled exception). The critical steps in the inner block are NOT reprocessed.</b>

So for me it should behave the following way: <b>If one uses an control step that explicitly raises an exception the whole block to which this exception is assigned to should be reprocessed and NOT only this control step.</b>

Otherwise "handling of exceptions" via exception branch to have alerting does not allow for reprocessing BP-Instances via standard XI measures anymore!

Of course you could do "looping" but in fact this is only adequate for errors that are caused by "temporary problems" (networking, ...) - you have to restrict the loop to some maximum iterations to avoid endless loops - after the loop has finished you are NO longer able to reprocess the BP-Instance again!

What's your opinion about this?

Thanks, Andy