From http://www.omg.org/spec/BPMN/2.0.2/PDF on page 238:
If the Process is used as a global Process (a callable Process that can be invoked from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered. The targetRef attribute of a Sequence Flow incoming to the Call Activity object can be extended to identify the appropriate Start Event.
How does one go about extending the targetRef attribute? Doesn't it have to be a valid IDREF? Maybe they mean the sequenceFlow element should be extended with a custom attribute?
Are there any examples of such an extension? Do existing BPMN tools support it?
Here is a BPMN snippet that I hand-edited to illustrate the question:
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL">
<process id="p1" name="Process 1" isExecutable="false" processType="Private">
<sequenceFlow id="startAflow" sourceRef="start" targetRef="A"/>
<sequenceFlow id="callActivityFlow" sourceRef="A" targetRef=" !? WHAT_GOES_HERE ?! "/>
<startEvent id="start" name="Start">
<outgoing>startAflow</outgoing>
</startEvent>
<task id="A">
<incoming>startAflow</incoming>
<outgoing>callActivityFlow</outgoing>
</task>
<callActivity id="call" calledElement="p2">
<incoming>callActivityFlow</incoming>
</task>
</process>
<process id="p2" name="Process 2" isExecutable="false" processType="Private">
<sequenceFlow id="start2Aflow" sourceRef="start1" targetRef="2A"/>
<sequenceFlow id="start2Bflow" sourceRef="start2" targetRef="2B"/>
<startEvent id="start1" name="Start">
<outgoing>start2Aflow</outgoing>
</startEvent>
<task id="2A">
<incoming>start2Aflow</incoming>
</task>
<startEvent id="start2" name="Start in middle of process">
<outgoing>start2Bflow</outgoing>
</startEvent>
<task id="2B">
<incoming>start2Bflow</incoming>
</task>
</process>
</definitions>
We actually discussed this issue within camunda - but decided to not support it (status quo). We haven't seen the real need for this construct in rea-life so far. It is quite esotheric and I wouldn't consider it best practice.
For the use case "migrate existing proicess instancess from another tool to camunda" we used another construct to start sub processes in a specific state leveraging message start events and an extension on the call activity - that seems much more understandable, see https://network.camunda.org/whitepaper/5
Cheers Bernd