How to realize throwing/catching events.

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

sruiz

Catching and throwing events are key features of BPMN. It's the way BPMN specifications can manage errors, process collaboration, time control, compensation, escalation to other performers,…

But, how can it be developed?

The purpose of this thread is:

• To generate a list of behaviours for the event element. I can give a clear opinion about this point but I would like other people can give more.
• To find the easier way of implement the behaviour of this container. I know that JMS or ESB solutions are possible, but I'm not a developer and I don't have enough knowledge about these technologies. In this point, I'm afraid that I can not help .

Events structure

The behaviour is always very similar to all the type of events(none, message, escalation, error, …): throwing events launch data objects to "a container" and catching events ask for data objects from "a container".  We're talking about, maybe, a pool pattern. Let's call this container "event pool".

All the events are catching or throwing events. NoneStartEvent is a catching event with a null data object. NoneStartEvent is a throwing event with a null data object(In Activiti there is a startEvent with form initialization, is it a start message event?). Boundary events are throwing events. The terminate event is a throwing event, …

If the abstract classes of ThrowEvent and CatchEvent are developed, the development of all subevents would be easier. A very good class hierarchy is in page 241 of BPMN 2.0 specifications. Now in activiti source the event classes are very plain.

Maybe, one of the more powerful events is message events but it's the more difficult to implement. I think that once this issue is solved, the rest of events would easily (and quickly) solved.

Data Objects

Maybe my meaning of data object is different to the BPMN 2.0 specifications. I agree with the article Simplifying BPMN 2.0 that there are too much data elements (data object, datainput, dataoutput, message, properties,…). I agree your very simple implementation of "process variables". From my point of view, data objects are "groups of process variables".

Principles of collaboration
I don't know if it is in the BPMN 2.0 specification (I only read it by fragments) but I think that there should be the principle "A process is responsible of its own flow and its control". Consequences:

• 1. "The process variables shall be changed only by itself and NOT by partner/child processes."
• 2. "Partner processes can read other partner process variables with the catching event dataobject". Catching events pick up copies of other process variables (data objects).
• 3. "Child processes can read ALL parent variables". But they can not modify then.
• 4. "Parent processes can access to the child process variables only when the child process is ended". If the parent process wants to change the flow of the child process a throwing-catching event should be added to the flow.

Behaviour of the event container
Multithreating in BPMN is managed by the event pool.

If you want to start a process you have to send a data object to the event pool and it start the process. When de process finish, the end event sends a data object to the event pool.
This "event pool" (EP) should be queryable. It contains when a process X collaborated or called to process Y!
The subprocess behaviour could be implemented easily.

The "event pool" should be a component of the process engine.
It's responsible of ALL the events of ALL the processes (start and end events too).

A participant ( process (white box) or a java bean(black box)) can leave or pick up a data object in the "event pool". If you can access to the event pool you have to implement a event interface.

Depending on the event's type ( start, message, end, boundary, error,…) the behaviour of the event pool is different. This is the reason JMS or ESB could not be a good solution , from an amateur point of view.

Let's give an example with the message event:
   1. Throwing events fires and leaves his "definition" and a data object to the event pool.
   2. The EP returns to the throwing event a (thread?) key if the process wants to ask to the event pool with a catching event.
   3. The EP looks for a previous catching event linked to this throwing event. (Sometimes the catching event is fired before the throwing event, remember,  the partner relationship is not sequential).
      2.1. If the catching event is not fired, the EP waits. Go to point 3.
      2.2. If the catching event was fired, the EP sends the dataobject + thread key to the catching event. Go to point 4.
   3. The catching event fires and the EP send the the dataobject + thread key to this event.
   4. The EP "closes" the record. To close can mean to remove the dataobject or keep it only for hystoric reasons.

The EP can be configured with xml files using the <collaboration> element of the BPMN 2.0 specification. As the processes are deployed with xml files, the EP can be deployed by xml files. The sequential flow changes to message flows.

It's an example and I'm sure that I can fail many details. I hope you understand the behaviour.

ronald_van_kuij

I think most will agree with the things you describe, at least in general (I just did a quick scan). One question though

"Child processes can read ALL parent variables". But they can not modify then.

Is a child process the same as a subprocess?