The editor is able to distinguish Zeebe and Camunda diagrams

nikku commented 3 years ago

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. :three:
[ ] 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 :three: 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Summary of my work on top of https://github.com/camunda/camunda-modeler/issues/2029#issuecomment-778059880

Pull Request https://github.com/camunda/camunda-modeler/pull/2099

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

https://github.com/camunda/camunda-modeler/compare/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 :+1:

camunda / camunda-modeler

The editor is able to distinguish Zeebe and Camunda diagrams #2029