topic Re: Support for Throw/Catch intermediate events and others in Alfresco Archive

Support for Throw/Catch intermediate events and others

ogo — Tue, 06 Sep 2011 11:10:14 GMT

Activiti designer (eclipse plug-in) supports way less BPMN2.0 constructs than Activiti modeler (signavio). A few crucial ones which I think are missing in Designer are :1) Intermediate throw events2) Intermediate catch events (*)3) Boundary error events on a task (but works on sub-processes and call

Re: Support for Throw/Catch intermediate events and others

trademak — Tue, 06 Sep 2011 11:33:40 GMT

Hi,

The Activiti Designer supports (at least tries to be equal) to what the Activiti Engine supports.
So that's why there's a difference between the Modeler and the Designer.

1. Which intermediate throw events are you looking for?
2. See 1.
3. Right, but if you have a (catch or throw?) boundary error event on a task how would you throw or catch such a boundary event? You would need quite a bit of Java logic to do this. Maybe you can explain how you want to implement this kind of functionality.

Best regards,

Re: Support for Throw/Catch intermediate events and others

ogo — Tue, 06 Sep 2011 13:17:42 GMT

Tijs,
Thanks for you reply. My perspective is purely adhering to proper BPMN 2.0 modeling and using the right patterns and constructs when it comes to dealing with exceptions (interrupting intermediate events, non interrupting intermediate events, error handling, escalation and potentially compensation).

I know absolutely nothing about the activiti BP execution engine implementation and will not venture into that territory. Having said that, if the engine supports boundary error event for a call activity and also for a sub-process (designer does support it), why not for a Service Task for example?

Also, the only alternate path out of a Task is flowing to and End Event. Why not allow inserting additional steps before terminating the process with the end event? (which to me sort of equates to writing additional instructions in a java catch, but my views are probably simplistic).

As for intermediate throw and catch events, the basic message events would be great I think as they greatly improve the readability of BMPN diagrams (rather than using send and receive tasks).

Ogo.

Re: Support for Throw/Catch intermediate events and others

trademak — Tue, 06 Sep 2011 13:42:08 GMT

Hi Ogo,

If you look at it from a proper BPMN 2.0 modeling perspective I can certainly understand your issues.
Activiti tries to adhere to the BPMN 2.0 standard, but we don't aim to fully implement the BPMN 2.0 specification (as no other tool vendor really does).
The engine supports boundary error events on tasks but what would be the use case?
Your comment about "the only alternate path out of a Task is flowing to an End Event" I don't understand. Maybe you can explain this?
The message event could indeed improve readability but doesn't add actual functionality to the Activiti Engine.

Best regards,

Re: Support for Throw/Catch intermediate events and others

ogo — Tue, 06 Sep 2011 15:24:14 GMT

Tijs,
When an activiti fails, it is good practice to use a boundary error event that starts an exception path, where in most cases you need to do a few things before terminating (like writing the catch of a java exception). See my modeler example where "Do This" fails and I need to "Do That Instead".
[attachment=1]boundary-err-event.png[/attachment]

With designer, you cannot use an error boundary event for a Task but you can create an alternate path to an End Event. See my design example "Do This First". It is currently not possible to insert anything between the "Do This First" and "End Event". That's what I meant with "the only alternate path out of a Task is flowing to an End Event".
(I wanted to make up for the impossibility of placing an error boundary event on a Task).
Frankly, I do not even quite understand this possibility to exit the Task with just an End Event as it does not seem to match anything really useful in BPMN2.0 (in fact, strictly speaking, if a task has multiple exits, the meaning is that it's 2 parallel paths … which makes no sense if one path is simply an end event), or is the intent to represent an alternate path in case the task fails? (but if yes, why just an end event …)
[attachment=0]end-event.png[/attachment]

ogo

Re: Support for Throw/Catch intermediate events and others

trademak — Tue, 06 Sep 2011 15:41:42 GMT

Hi,

I understand what you're saying, but it's not correct that you can't model anything else than an end event.
You can add a new sequence flow to a task and just add another task or another BPMN 2.0 construct if you like.
There are no restrictions there.

Best regards,

Re: Support for Throw/Catch intermediate events and others

ogo — Tue, 06 Sep 2011 16:04:47 GMT

Right, you can create a parallel path with something that is not an end event…

Also, going back to one of my original questions :
Why allow boundary error events on Call Activities or Sub-Processes and not on Tasks ? You had asked me "what is the use case" ? but the use case is that anything can fail, whether it be a Service Task, a Call Activity or a Sub-Process.

or maybe I do not understand the definition of "Service Task". Are you defining it as something that cannot fail ?
Thanks

Re: Support for Throw/Catch intermediate events and others

trademak — Wed, 07 Sep 2011 06:41:43 GMT

On tasks it makes no sense within the Activiti Engine.
A user task can't fail. What would be the use case of a user task failing?
For a service task it makes more sense, but within Activiti this is handled in another way.
A service task is mainly a Java service task which means that you can implement logic to choose one of the outgoing sequence flows based on the processing in the Java service task.
So you can catch a particular exception and choose the appropriate outgoing sequence flow. Another option would be to set a process variable to a specific value and use an exclusive gateway to choose the appropriate path, which also can be an error end event. But an error end event can only be caught on an embedded sub process or a call activity.

Best regards,

Re: Support for Throw/Catch intermediate events and others

intercept1r — Thu, 26 Mar 2015 12:19:11 GMT

hi i have a similar question. I want to implement a holiday request and approve process. he user who requests Holiday has to ask one replacement for each Projects he works on. The replacements have to decide if they have time to that or not.
[img]http://i.stack.imgur.com/Gdhbw.jpg[/img]

Example:

user 1 requests hoiday an Needs 2 users as replacements.
user 2 declines the request because he is busy. So user 1 has to choose another replacement instead.
user 3 approves the request.
The Problem is now, that if user 2 declines the request the usertask for user 3 is gone because the subprocess is interrupted. Is there a way to implement what iam looking for?

Re: Support for Throw/Catch intermediate events and others

jbarrez — Tue, 31 Mar 2015 08:10:39 GMT

So the easiest would be if you can wait for all the users to respond. In that case, you can add logic after the subprocess that checks the responses and goes back if needed.

But if that's not possible, I would add a new task for the first user after it's declinded, specific to handle the case of the one user rejecting.

Re: Support for Throw/Catch intermediate events and others

intercept1r — Fri, 10 Apr 2015 10:39:51 GMT

Thanks for your reply.
waiting for all users to respond is not an option.
I have one Problem by handling the decline in the subprocess. The "handling" process would be a usertask and the whole subprocess again. Because if the first holiday replacement declines and you choose another one that mabybe declines again, and again….

I need a way to create such a handle process. Do you have any Ideas?

Re: Support for Throw/Catch intermediate events and others

intercept1r — Sat, 11 Apr 2015 14:04:03 GMT

After thinking about the Subprocess and your answer i figured out that you are right jbarrez. The solution ist to add a new task for the first user within the subprocess.
Thank you very much!
intercept1r