The editor is able to distinguish Zeebe and Camunda diagrams

[nikku]

What should we do?

In order to have a unified modeler, we must find a robust way to tell apart Zeebe and Camunda diagrams. That mechanism SHALL be independent of whether an implementation property/namespace exists on the document.

• Resources (BPMN, DMN, CMMN, Form) contain meta-data about the execution platform and version targeted (i.e. Camunda BPM, v7.15, Camunda Cloud, xxx, Zeebe, v0.21.0)
• The meta-data is read from by the modeler to determine which editing controls to show
• Old diagrams without profile meta-data continue to open and are categorized on a best effort basis (i.e. by examining the used implementation namespaces; we could assume that diagrams with the camunda namespace are likely targeting a current (or previous) version of Camunda BPM. 3️⃣
• The profile meta-data is shown in the UI for a diagram
• Users are able to set the profile explicitly via the Modeler UI. This helps in situations where 3️⃣ does not work and allows users to start modeling without choosing any profile in the first place.

Why should we do it?

This is a core capability needed for a unified Camunda / Zeebe modeler

Things to investigate

• Is there any generic BPMN elements that we can use for storing version information? Or do we have to invent a new XML namespace + extension to do it?

Context
child of https://github.com/bpmn-io/internal-docs/issues/216

[pinussilvestrus]

Things that came into my mind when thinking about this topic

• We maybe can re-use our add-exporter extension to handle this metadata as well
• Are we assuming diagrams with multiple processes (BPMN) are always deploying to the same execution context? I

I'm not 100% sure but I can remember that from the BPMN spec it would be allowed that multiple processes in a diagram could differ in that aspect. But I'm pretty sure that our Engines would never support it so we might ignore it and can save this metadata on the definitions level

Is there any generic BPMN elements that we can use for storing version information? Or do we have to invent a new XML namespace + extension to do it?

What we always could do is to misuse the documentation element

<bpmn:definitions>
  <documentation id="executionMetadata">CamundaBPM,7.15</documentation>
  <bpmn:process id="Process_0pt2xzy" isExecutable="true">
    <bpmn:startEvent id="StartEvent_1" />
  </bpmn:process>
</bpmn:definitions>

<bpmn:definitions>
  <documentation id="executionPlatform">CamundaBPM</documentation>
  <documentation id="executionPlatformVersion">7.15</documentation>
  <bpmn:process id="Process_0pt2xzy" isExecutable="true">
    <bpmn:startEvent id="StartEvent_1" />
  </bpmn:process>
</bpmn:definitions>

[nikku]

Are we assuming diagrams with multiple processes (BPMN) are always deploying to the same execution context?

Yes, we should. Everything else will become super hard to reason about by anyone, the app, the user.

[pinussilvestrus]

Simple CodeSandbox on how to use our existing namespace util to detect Zeebe diagrams: https://codesandbox.io/s/detect-namespace-d7cn9?file=/src/index.js (the same way we do to detect DMN 1.1 & DMN 1.2 files)

import { findUsages } from '../util/namespace';

const ZEEBE_NS = 'http://camunda.org/schema/zeebe/1.0';

const isZeebe = findUsages(xml, ZEEBE_NS);

[nikku]

As you look into this issue, please keep in mind that detection via the namespace may not be enough. These do not allow us to deduce a specific Camunda platform or Zeebe or Cloud version:

Resources (BPMN, DMN, CMMN, Form) contain meta-data about the execution platform and version targeted (i.e. Camunda BPM, v7.15, Camunda Cloud, xxx, Zeebe, v0.21.0)

[pinussilvestrus]

please keep in mind that detection via the namespace may not be enough

Yeah absolutely. I am just playing around with namespace detection due to the fallback scenario

Old diagrams without profile meta-data continue to open and are categorized on a best effort basis (i.e. by examining the used implementation namespaces; we could assume that diagrams with the camunda namespace are likely targeting a current (or previous) version of Camunda BPM. 3️⃣

[barmac]

Summary of decisions taken during the meeting with @pinussilvestrus and @nikku:

• We are going to have a separate namespace for Modeler-specific properties with executionPlatform among them.
• It should be named modeler, modeling or design - this has to be yet decided, but it will be easy to change until we release feature when it's frozen.
• Zeebe editor will be implemented as a separate tab within the TabsProvider.

Thank you for your help.

[barmac]

When you open a file with no contents but with a known extension (e.g. file.bpmn), we use the same diagram as if you were to create a new diagram of that type. As part of this issue, I'd say we can safely use Camunda diagram per default, just like we want to use it as a fallback for missing executionPlatform.

[barmac]

What I've accomplished so far:

• added a cloud-bpmn provider (without ZeebeBpmnEditor though)
• added buttons to the menu and the dropdown for the Zeebe diagrams
• moved the default filename mechanism to the providers instead of global pattern diagram_{counter}.{provider-type}; this allows to use bpmn extension for the cloud-bpmn provider
• started to implement diagram distinguishing mechanism

What is missing:

• diagram distinguishing mechanism (foundation is laid, but the Zeebe part is not done)
• meta-data for the tabs to use plugins correctly
• Zeebe tab (currently I re-use Camunda without changes)
• tests for most of the stuff above

We also need to make a decision what namespace prefix we want to use: https://github.com/camunda/modeling-moddle.

[pinussilvestrus]

Some (quick) investigations regarding

Zeebe tab (currently I re-use Camunda without changes)

Since the camunda-modeler#BpmnEditor and zeebe-modeler#BpmnEditor only differ in some parts, but share a common code base, I wanted to figure out whether we can have a base BpmnEditor component, which both (Platform & Cloud) tab can rely on (cf. Diff Check).

Experiments went into: https://github.com/camunda/camunda-modeler/tree/base-bpmn-editor

tldr: It's doable, but needs a bit of refactoring. Generally, it seems okay if we would go with separate/independent editors for the first iteration, and live with the duplicated code.

One another point that makes it difficult to re-use the same BpmnEditor: We decided to ignore plugins for the Zeebe Tab completely.

Let's discuss this next week with @barmac and others.

[pinussilvestrus]

Summary of my work on top of #2029 (comment)

Pull Request #2099

• Make sure we don't load Camunda specific Deploy & Run on other tabs

2029-distinguish-camunda-and-zeebe-diagrams...2029-cloud-bpmn-tab

• add CloudBpmnTab, incoorporates camunda-bpmn-js CloudModeler
• use camunda-bpmn-js PlatformModeler on existing BpmnTab
• display Zeebe specific Deploy & Run on cloud-bpmn tabs
• start on distinguishing mechanism for Zeebe diagrams (namespace fallback)
  • missing: check for executionPlatform

https://github.com/camunda/camunda-modeler/tree/2029-distinguish-camunda-and-zeebe-diagrams

• Some small fixups to make the CloudBpmnTab running

Let's sync with @barmac and do the handover once he's back 👍