<camunda:in> support for Element Templates

BPMN & Modeling Discussion & Questions
1

Hi,

First of all the new Element Template Feature for modeler is great. Nice work.

My question is if the feature also supports the camunda:in property.
My use case is that I would like to configure that businessKey of a process is always passed to the cmmn case which is integrated via a call activity.

I think it is not supported yet? Is is planned?

Best regards,

Markus

2

Hi,

actually I can only second that: Huge improvement and absolutely what we need to allow others to build workflows based on our pre-configured templates. Congratulations!

I started investigating and ran into the same issue: The “Call Activities” type does not seem to be supported yet. I had problems defining the “calledElement” property. Maybe I missed something, maybe because the UI requires a selection “BPMN”/“CMMN” first…

I as well did not find a way to provide invisible defaults for some settings (I do not even want the modeller to worry about some internal parameters)

3

Nice to hear you like the initial element templates version we have put together.

Your feedback on Call Activities is valuable as we are currently investigating the next steps (what to support for additional technical bindings and so forth). Could you guys provide some BPMN 2.0 XML snippets with call activities and the binding you’d like to see configured?

4

Hi,

I added a simple bpmn file where process has one call activity. This call activity should use the added template (Does not work at the moment). The template specifies that all variables of process should be passed to case and also the businessKey of the process. This is done via binding type “camunda:in”.
Does this help ?

CaseCallActivity.xml (1.9 KB)

PizzaProcess.bpmn (3.4 KB)

Best regards,

Markus

P.S: I had to change the file extension of the template file to xml because json is not supported for upload here.

5

Helps a lot, thank you!

6
1 Like
7

To allow better data separation we only pass selected variables. If supporting both types “Source Expression” and “Source” would cause significant additional work, in an agile manner I’d prefer to have “Source Expression” first as is is not as user friendly but would at the end fit both of our usages.
We do only use BPMN in production, no CMMN. So I cannot speak for that.

Looking at the last part of Markus’ JSON, it seems we are both looking for the same use case to be solved as well:
Being able to define defaults not even shown to the user working with the template:

      {
        "label": "Pass all variables",
        "type": "String",
        "value": "all",
        **"editable": false**,
        "binding": {
          "type": "camunda:in",
          "name": "variables"
        }
      }

Thanks a lot,
Werner

8