A frequent complaint about BPMN is that it cannot adequately describe many common business process scenarios, particularly when all possible flow paths are not known in advance. Actually, it can handle a good number of those, but many fall into a “gray area” – patterns that may or may not be technically allowed, depending on your interpretation of the spec. One of those scenarios concerns variant forms of an activity. If activity A has only two or three variants, the modeling is straightforward: You just have a gateway that branches to variant X, variant Y, and variant Z, each shown explicitly as a separate activity in the diagram. But what if there are dozens of variants? For example, consider a nationwide insurance carrier that must conform to differences in each state. You could have a gateway with 50 branches, but I don’t think many people would consider that a satisfactory solution. I sure wouldn’t.
Instead, you’d like is to say the next step is some variant of activity A determined by a variable (data object). I propose that a Call Activity can do this, as long as all of the variants have the same set of inputs and outputs. Some of you may say, of course, who would think otherwise? But technically it is a gray area. It is not explicitly discussed in the spec, but I believe it is allowed by the BPMN 2.0 metamodel and narrative text, although there is a small issue with the schema.
The spec says the Call Activity invokes a particular callable element, either a process or global task. A definition of the callable element is external to the calling process definition. The only requirement of the metamodel and spec text is that the Call Activity’s ioSpecification element must match the data inputs and outputs of the callable element. So as long as all the variants of activity A are defined with the same set of inputs and outputs (even if some are not used), the metamodel would seem to allow a Call Activity to invoke one of the variants determined at runtime in the calling process instance.
The schema is a slight problem, since the Call Activity’s calledElementRef attribute technically is an id prefixed with the namespace of the callable element. In other words, the schema implies it is fixed at design time, not settable at runtime. You could resolve this by saying that the calledElementRef is an expression that resolves to a prefixed id. There are other examples where an attribute dynamically defined as an expression of runtime data would add flexibility over the static design-time value technically required by the schema, such as a duration or dateTime value of a Timer event. In non-executable models it is quite common to use a Timer event label that implies a dynamic value, and I believe that many BPM Suites can handle such dynamic values in execution.
I think this is a case where the schema is imposing a constraint that is not explicitly stated in the spec text or metamodel. For the Timer event example, it’s not an issue for models conforming to the Descriptive or Analytic subclass, since only the label (@name) is serialized in the XML. But it is a problem for the dynamically called activity example. It would be better if BPMN 2.1 changed the data type of the calledElementRef from QName to a new named type that is essentially an expression that resolves to a prefixed id.
There are numerous other ways in which dynamic and ad-hoc behavior can be modeled in BPMN 2.0, without resorting to CMMN or other initiatives that may or may not ever get traction. If you are interested in this topic, check out my BPMN Master Class in June, where this will be a focus of discussion.
Hi Bruce,
I agree that there are some really good scenarios for this particularly, as you mention, for compliance where there might be scores of reporting processes to be called. Could you be more explicit here? Suppose we have a script “Determine Activity” and the output of the script has a record output.record.nextActivity. Are you saying that, in theory at least, that the expression
calledElementRef = output.record.nextActivity
Should dynamically call the Call Activity?
Also what naming conversion would you use on the diagram? “Compliance Activity”, or “Referenced Compliance Activity”
Thanks,
Tom
Yes, that is what I am saying, except calledElementRef=output.record.nextActivity would not be schema valid. It would be more like calledElementRef={concat(“myPrefix:”,id(output.record.nextActivity))}. That’s not really legal, either, but it is intended to indicate an expression that resolves to the correct data type.
In the diagram, I would say something like Call Compliance Activity(code), where code is the name of a data object set previously by your script. That at least “tries” to comply with the metamodel.
Hi Bruce.
I agree with the basic requirement. We use that already in lots of customer projects as our camunda BPM Platform uses an extension elements which behaves exactly like this. See http://docs.camunda.org/latest/api-references/bpmn20/#subprocesses-call-activity – the ‘calledElement’ can be expession language (which can access all process data or Java code) – e.g.:
Cheers
Bernd