cancel
Showing results for 
Search instead for 
Did you mean: 

Signaling Error state to Java receive task

bkwf2
Champ in-the-making
Champ in-the-making
Hello,

We are tying to use Activiti Workflow Engine (Version 5.6) in order replace IBM's Workflow process engine. And till now I think we are having good success.

We are trying to model Activiti WF processes as closely as possible to the existing IBM processes that we have.

I have attached an example/simple WF process that I have designed. Below explains what this process does:

1. The process starts

2. A user gets a task to review Loss Event.

3. The User either approves or dis-approves the event.

4. Based on the approval result, the process transitions to either "On Approved Auto Tasks" or "On Not Approved Auto Tasks" Java Receive tasks.

5. Both these tasks use "listeners" that start "EXTERNAL" process. That is the listeners send XML message to MQ Queue and a daemon process reads that message and performs BE business processes. Once the external BE process ends, a "signal" is sent back to the "Java receive task" to proceed ahead.

[attachment=0]LossEventReview-WaitTask.png[/attachment]

My questions are:

a) If an error/exception occurs in the external BE process, like an MQ queue fails etc, how can I send a "signal" to the "Java receive task" with description of the exception and change the state of the receive task to an "error state".

b) Assuming I am able to do (a) above somehow and we fix any issues with the external process. Is there a way to "restart" the Java receive task back again [instead of starting the WF process from the beginning], so that the receive task will pick up where it left..?

I read the complete documentation but I do not have a clue on how to do the above.

thnx,

Bhushan.
7 REPLIES 7

bkwf2
Champ in-the-making
Champ in-the-making
Hi,

Any suggestions for this..?

Is what I want even possible using a "Java Receive Task"…? Or do I need to use another BPMN construct here to model my flow..?

Any help would be greatly appreciated.

thnx,

Bhushan.

trademak
Star Contributor
Star Contributor
Hi,

Wouldn't a call activity and a sub process for the "EXTERNAL" process be better suited?
Then you can handle all things that are happening in the "EXTERNAL" process by default.
So when the sub process ends normal the main process just continues.
And when an error occurs you can propagate this to the main process using error end events.

Best regards,

bkwf2
Champ in-the-making
Champ in-the-making
Hi trademak,

Thanks for the reply.

The issue is that the external process is in a separate Java VM and is a legacy application which runs substantial business logic. So to convert that into a subprocess or call activiti which will run in the SAME VM as the Activiti process Engine is difficult.

Or do you mean that in the above process design I add a "sub process" or "call activity" which will call the external process..?

thanks,

Bhushan.

trademak
Star Contributor
Star Contributor
Hi,

Okay right. Then you can still implement a sub process that's invoked by a call activity, and in that sub process call the external process.
Is that call a Web service call or JMS message or so?

Best regards,

bkwf2
Champ in-the-making
Champ in-the-making
Hi trademak,

Thanks for the reply and help here.

The external call is a JMS message.

And based on your comment below here's what I think I should do:

1. Instead of using "Java recieve task" use a sub-process and call it using a "call activity". The sub-process will make a call to the external process.

2. The sub-process will use a "Java Receive task", since we will need to wait till the external process completes. Once it completes successfully, it will signal the receive task to proceed and sub-process will complete and process flow control will go back to the main flow.

3. If an error occurs in the external Java VM process, then put some kind of "error indicating variable" in the "process" variable scope and signal the receive task. We will need to add a "listener" on the "end" event of the receive task which will look for the "error indicating variable". If found, use "Error Boundary Event" to put the subprocess in Error state.

That sound right..?

thanks,

Bhushan

trademak
Star Contributor
Star Contributor
Hi,

I think your thoughts are good except for the error handling.
What you should do (to my opinion at least 😉 ), is to set a process variable indicating an error has occurred. Then just signal the receive task to go ahead.
After the receive task you can put an exclusive gateway. In the outgoing sequence flows you validate if an error has occurred.
If yes, then go to an error end event to end the sub process, if no just end it with a normal end event.
Then on the call activity you can set a boundary error event to catch the error end event of the sub process.

Best regards,

bkwf2
Champ in-the-making
Champ in-the-making
Hi trademak,

Thanks for the advice.

Actually instead of using a call activity and sub-process, I finally went with the original receive task. Here's why I did it:

When an error occurs in the external VM process, we do not want the activity to proceed to the next task, but stay on the same task which triggered the external process. Except that we want the same task to remain in an "Error State". In Activiti there is no concept of putting a "task" in an error state (based on what I have read in docs). The ONLY option is to use an "Error End Event" or "Error Boundary Event", which would mean that the state of the task would proceed from the erroneous task to the error event.
Hope the above is clear enough since I think my above description is quite convoluted.

So here's what I ended up with:

1. When the Java receive task starts an external VM process, and the external process ends up in error, I am catching the exception in the external process and then setting process variable indicating an error state and full exception details.

2. Next I signal the receive task and a listener on the "end" event of the task checks for the "error" process variable. The listener, gets the error details from the process variable and logs the error in DB with reference to the "process instance ID". This logging helps me to indicate that a certain process is in Error state and allows us to produce a "report" of processes in error.

3. Next when the external process exceptions are fixed, the external process again sends a new signal to the receive task without "error" process variable and the process proceeds to the next task.

Hope this will be useful to other people who have a similar use case.

trademak thanks again for your help!

Bhushan.