Non-blocking BPMN Call Activity

[Falko Menge]

Hi everyone,

I suggest to add the attribute isBlocking as an extension to the BPMN
Call Activity for calling both processes and cases.

All CMMN Tasks have an attribute isBlocking, which can be set to false
in order to express that the engine will not wait for the tasks
completion. I find it especially interesting in the context of Case
Tasks and Process Tasks, because its an easy way to kick of a case or
process instance asynchronously while still maintaining the call
relationship for monitoring and operating purposes.

One can already do a non-blocking start using the Java API, but it
requires custom Java code and Cockpit would neither show the
parent-child relationship nor the incident trace.

What do you think?

Cheers,
Falko

[Rob P]

Hi Falko,

Could you achieve the same result by just using a parallel split just before the call activity? Hence one path continues on whilst the call activity blocks?

regards

Rob

[Bernd Rücker (camunda)]

This is actually what I would do as well – so I don’t see the big need for this extension (I even could think that it might be confusing).

--
You received this message because you are subscribed to the Google Groups "camunda BPM platform contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camunda-bpm-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/camunda-bpm-dev/c2081bd5-2737-443c-ab2c-3e4892af164e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Meyer]

I can see at least one usecase where I would definitely not want to use
the parallel gateway workaround:

Sometimes you have a process which starts many other processes but does
not need to block until they complete. I have seen this many times in
batch processes. One process starting 100s or 10000s of other process
instances.
If you use the parallel gw workaround, then you will have two problems:
- for each process instance you start you collect 2 executions (one
concurrent and one scope) which bloat the process instance.
- when the process instances are completed the "signal back up" at which
point they are unnecessarily joined. So you end up with a lot of
contention on the scope execution and many OLE.

@Bernd: why would it be confusing?

Regards,
Daniel

[Bernd Rücker (camunda)]

A CallActivity is defined in a way that we have to wait for it. I find it
very confusing if this is weakened and I do not know by looking at the
diagram if I wait for the CallActivity or not.

I see a value in the basic feature - but I would prefer to think in another
direction:
- pimp the MessageTask/MessageEvent - as this is intended for asynchronous
start of other process instances
- add a "calledElement" like property there
- add functionality in cockpit to see parent/child also for these instances

Which would valuable for sure! See e.g.
https://github.com/camunda/camunda-consulting/tree/master/snippets/cockpit-plugin-bpmn-collaboration
we have built this for a customer - as you sometimes have situations where
you have two process instances collaborating in a way that you have "sync
points".

-----Ursprüngliche Nachricht-----
Von: camunda...@googlegroups.com
[mailto:camunda...@googlegroups.com] Im Auftrag von Daniel Meyer
Gesendet: Montag, 3. August 2015 09:59
An: camunda...@googlegroups.com
Betreff: Re: AW: Non-blocking BPMN Call Activity

--
You received this message because you are subscribed to the Google Groups
"camunda BPM platform contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-d...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/camunda-bpm-dev/55BF1F5D.3040402%40camunda.com.

[Daniel Meyer]

Hi Bernd,

I can totally see your point.

I guess that in terms of "semantics visible in the diagram": the
question re Call Activity is whether the "Invoking anther Process" or
the "Blocking for that other process" aspect is more important.

With the message event you can also make the dependency explicit in the
visual diagram (if both processes are part of the same collaboration).
Is there a problem regarding versioning in that case?

Daniel

[Falko Menge]

Hi Bernd,

I'm definitely open for implementing BPMN messaging among processes
inside the engine and recognizing that in Cockpit. However, I wouldn't
go as far as having a calledElement attribute on a Message Event as it
would break the loose coupling.

The visual advantage of a Call Activity is that everybody knows that it
invokes another process. With a Message Event it is only visible in a
Collabotation, which as Daniel noted tightly couples the two processes
together in terms of their life cycle. In addition a Call Activity is
able to compute the called process with an expression at runtime and
this feature is likely to be adopted as a standard, because CMMN's
process and case task already have it.

I agree that the missing visibility of the isBlocking attribute is not
helpful. Actually, CMMN's tasks also have that problem, except for the
Human Task. There CMMN solves it with two different icons.

I looked for potential icons to also visualize that in BPMN, but only
found icons that visualize the blocking/waiting behaviour, e.g. an hour
glass or a clock.

Does anybody have ideas on how a non-blocking behaviour could be
visualized in both BPMN and CMMN?

Cheers,
Falko

[Bernd Rücker (camunda)]

> I'm definitely open for implementing BPMN messaging among processes inside
> the engine and recognizing that in Cockpit. However, I wouldn't go as far
> as having a calledElement attribute on a Message Event as it would break
> the loose coupling.

OK - but with message names that would also work.

> The visual advantage of a Call Activity is that everybody knows that it
> invokes another process.

Yeah - and everybody knows it is synchronous. Whereas with message event
every knows something is started asynchronously. I still like this approach
MUCH better.

> I agree that the missing visibility of the isBlocking attribute is not
> helpful. Actually, CMMN's tasks also have that problem, except for the
> Human Task.

But at least it is defined in the spec - so you KNOW that this might be non
blocking in CMMN - and there it also feels more natural to have this than in
BPMN (personal gut feeling).

Cheers
Bernd

-----Ursprüngliche Nachricht-----
Von: camunda...@googlegroups.com
[mailto:camunda...@googlegroups.com] Im Auftrag von Falko Menge
Gesendet: Montag, 3. August 2015 16:07
An: camunda...@googlegroups.com

Betreff: Re: Non-blocking BPMN Call Activity

--
You received this message because you are subscribed to the Google Groups
"camunda BPM platform contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-d...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/camunda-bpm-dev/55BF7595.8040300%40camunda.com.

[Bernd Rücker (camunda)]

If you have it in one collaboration diagram the process definitions are
always versioned in sync. If you start a different version (which is by the
way only possible with the "key/version" mechanism, not by message) it would
work as well - but you "change" collaboration diagrams which for assure will
be confusing for a human looking at it.

However - as written - for my gut feeling the "Blocking for that other
process" is more important - as this is defined by the spec and teached to
everybody learning BPMN.

-----Ursprüngliche Nachricht-----
Von: camunda...@googlegroups.com
[mailto:camunda...@googlegroups.com] Im Auftrag von Daniel Meyer

Gesendet: Montag, 3. August 2015 10:25
An: camunda...@googlegroups.com
Betreff: Re: AW: AW: Non-blocking BPMN Call Activity

--
You received this message because you are subscribed to the Google Groups
"camunda BPM platform contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-d...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/camunda-bpm-dev/55BF2567.1070005%40camunda.com.

[Falko Menge]

Well, with CMMN getting more popular, we might end up in a scenario
where users need to remember that BPMN is the one that can ONLY do
blocking invocations, while it became normal to have non-blocking calls
in CMMN.

Maybe, I should explain that I came to this topic as part of a larger
discussion to bring CMMN & DMN Compatibility into BPMN. In there it is
proposed to use the BPMN extension mechanisms to add attributes and
icons to the language that are agreed upon by multiple vendors and thus
"standardized". Later this might be submitted to OMG and ISO, but thats
at the end of the journey.

On the particular issue, the proposal is to use the following attributes
and icons on a BPMN Call Activity:

new attributes:
processRefExpression
caseRef
caseRefExpression
new icons:
"Folder" symbol as in CMMN Case Task
"Chevron" symbol as in CMMN Process Task

If a BPMN Call Activity will look like a CMMN Process or Case Task,
shouldn't it also behave like them, while also solving an issue that
customers with batch processes are facing?

BPMN 2.0 is already five years old. Let's learn from the improvements of
the newer specs!

[Bernd Rücker (camunda)]

That is an important context information. If this extension would be added
to the standard it is a different story in terms of "confusion" for the
reader...

-----Ursprüngliche Nachricht-----
Von: camunda...@googlegroups.com
[mailto:camunda...@googlegroups.com] Im Auftrag von Falko Menge
Gesendet: Mittwoch, 5. August 2015 16:12
An: camunda...@googlegroups.com

Betreff: Re: Non-blocking BPMN Call Activity

--
You received this message because you are subscribed to the Google Groups
"camunda BPM platform contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-d...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/camunda-bpm-dev/55C219C8.3010602%40camunda.com.