Skip to Content
Developer InformationBPMN SerializationSubprocesses and Call Activities

Subprocesses and Call Activities

In BPMN, subprocesses can be divided into embedded subprocesses and call activities. The former are usual processes enclosed inside the parent process and don’t live by its own. Embedded subprocesses are mainly used to reduce the visual complexity of a process. Therefore, they can be in an expanded and in a collapsed (with a plus symbol) state.

BPMN Process

A call activity references another process, so that a process can be reused in multiple processes. For instance, a billing process is a typical example of a reusable process. The Call Activity is marked with a thick border and requires the referenced process to have at least one non-typed start event.

BPMN Process

Embedded expanded or collapsed Subprocess

Embedded processes are part of the parent process and include the process logic inside the subProcess element. They always start with a non-typed start event and should also end with one. It is purely part of the graphical specification inside BPMNDiagram, if the subprocess is displayed in the collapsed or expanded form. In both cases, the semantic part is contained in the parent process.

In the PROCEED MS it is not possible to convert a collapsed subprocess into an expanded one, because this would interfere with the graphical layout of the remaining process and would maybe shift or overlap some other elements.

<bpmn:process ... >
    ...
    <bpmn:startEvent id="StartEvent_1"></bpmn:startEvent>
    <bpmn:sequenceFlow id="Flow_1x5to91" sourceRef="StartEvent_1" targetRef="Activity_1juds8c" />
 
    <bpmn:subProcess id="Activity_1juds8c" name="Collapsed Embedded Subprocess">
      <bpmn:startEvent id="Event_0ex1c4k"></bpmn:startEvent>
      <bpmn:sequenceFlow id="Flow_1lkyh0w" sourceRef="Event_0ex1c4k" targetRef="Event_1tkfgjp" />
      <bpmn:endEvent id="Event_1tkfgjp"></bpmn:endEvent>
    </bpmn:subProcess>
 
    <bpmn:sequenceFlow id="Flow_0ncxhf9" sourceRef="Activity_1juds8c" targetRef="Activity_0491dp9" />
 
    <bpmn:subProcess id="Activity_0491dp9" name="Expanded Embedded Subprocess">
      <bpmn:startEvent id="Event_0zqe4lt"></bpmn:startEvent>
      <bpmn:sequenceFlow id="Flow_123mirk" sourceRef="Event_0zqe4lt" targetRef="Event_1bpeq3v" />
      <bpmn:endEvent id="Event_1bpeq3v"></bpmn:endEvent>
    </bpmn:subProcess>
 
    <bpmn:sequenceFlow id="Flow_0f1uvb4" sourceRef="Activity_0491dp9" targetRef="Event_0gso4th" />
    <bpmn:endEvent id="Event_0gso4th"></bpmn:endEvent>
    ...
</bpmn:process>
<bpmndi:BPMNDiagram ... >
    <bpmndi:BPMNShape id="Activity_0491dp9_di" bpmnElement="Activity_0491dp9" isExpanded="true">
    ...
</bpmndi:BPMNDiagram>

Call Activities

A call activity references another process, so that one process can be reused in multiple other processes.

The following code shows how call activities are serialized:

<definitions
    xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
    xmlns:p33c24="https://docs.proceed-labs.org/_17c6fed0-8a8c-4722-a62f-86ebf1324c33"
    ...
    id="_e292e6c4-4d7f-4aff-b91f-c102d5ea4ae8"
    name="Global Task Process"
    targetNamespace="https://docs.proceed-labs.org/_e292e6c4-4d7f-4aff-b91f-c102d5ea4ae8"
    >
 
    <import namespace="https://docs.proceed-labs.org/_17c6fed0-8a8c-4722-a62f-86ebf1324c33" location="_17c6fed0-8a8c-4722-a62f-86ebf1324c33:_3rt4b808-1cc0-499d-b6bc-4eba603177z6" importType="http://www.omg.org/spec/BPMN/20100524/MODEL" />
 
    <process ...>
        ...
        <callActivity id="Task_0ul33bj" name="Call the global process" calledElement="p33c24:Process_1wqd8fv">
        </callActivity>
        ...
    </process>
</definitions>
  • the imported process is not contained within the same BPMN file (not within <definitions>)
  • the import element can occur multiple times for multiple processes, but always as the first child element of definitions (not after <process>)
  • the import attribute namespace is the targetNamespace of the imported process
  • the prefix p33c24 is defined for the namespace of the imported process on top in definitions
  • the import attribute location contains the id and processVersionId separated by a colon of the definitions element of the imported BPMN file
  • the import attribute importType indicates that the imported file is a BPMN file (static value)
  • the callActivity attribute calledElement links to the id of process of the imported process

_17c6fed0-8a8c-4722-a62f-86ebf1324c33:

<definitions
    xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
    ...
    id="_17c6fed0-8a8c-4722-a62f-86ebf1324c33"
    name="Imported Process"
 
    proceed:processVersionId="_3rt4b808-1cc0-499d-b6bc-4eba603177z6"
    proceed:processVersionName="v2"
    proceed:processVersionDescription="version 2"
    proceed:processVersionCreatedOn="2025-04-01-15-04-33-881"
    proceed:processVersionBasedOn="_5bfb32f1-8554-42d9-bc2d-f75fc2f60634"
 
    targetNamespace="https://docs.proceed-labs.org/_17c6fed0-8a8c-4722-a62f-86ebf1324c33"
    >
 
    <process id="Process_1wqd8fv" ...>
        ...
        <startEvent id="StartEvent_1">
        </startEvent>
        ...
    </process>
</definitions>

Why don’t we use another <process> element inside <definitions>?

  • before deployment we would have to copy the other process and its graphical model into the <definitions> element; after an import we would have to split it again into two processes
  • problem: if we want to start a process, the executor has to select one process of all the available processes inside <definitions>. There is no standard way to say which one of all processes is the main one
    • we could use the executable or processType attribute, but this would somehow change the original semantics

Data transfer to and from Call Activities

Attention: this is not BPMN standard conform yet

During runtime, when entering a call activity, the call activity is started as a new process and all process variables of the main process are copied into the new process.

After the called process ends, all variables of this process are copied back into the main process. This may results in a set of updated/overwritten variables, but it can also contain new variables which were created in the call activity itself.

Note that changes to variables, which are performed in the main process in parallel to the call activity execution, do not affect the variables of the latter during its runtime (there is no variable synchonization between a call activity and parallel activities). Depending on which of the parallel activities ends last, the existing variables are overwritten.

Deployment and Executionof Call Activities

If a process with Call Activities is deployed to a Process Engine, the MS does the following steps:

  • checks if there are <import> elements after definitions
  • checks if the imported process has at least one non-typed starting event
  • checks for cyclic references, if other call activities exists in the referenced process and they are not building a loop
  • deploys all imported processes and recursive processes to a sub-endpoint under /imported/{processName}
  • deploys all user tasks of imported processes and recursive processes to a sub-endpoint under /imported/user-tasks/{html-file}

At execution time: The referenced processes are started with all the non-typed start events

Last updated on
User TasksGateways