Make Zeebe modeling extensions and properties publicly available

[pinussilvestrus]

Is your feature request related to a problem? Please describe.

The Zeebe Modeler uses custom modules as behaviors and modeling controls, cf. https://github.com/zeebe-io/zeebe-modeler/tree/develop/client/src/app/tabs/bpmn/custom. These are a point of interest when building your own Modeler applications for the Zeebe engine.

All these modules should be publicly consumable, e.g. via npm package. It would enable us to easier integrate those into the Camunda Modeler, cf. https://github.com/bpmn-io/internal-docs/issues/216. It would make other things way easier, like packaging the extensions for re-using it in other environments, cf. #244 or #127.

We already started it with the moddle descriptors, cf. #107

Describe the solution you'd like

Make zeebe related modules available via own package(s). This may or may not include

• ZeebePropertiesProvider
• Zeebe Modeling modules (context pad provider, palette provider, custom behaviors, ...)
• Zeebe Deploy + Start Plugin This will go inside the Camunda Modeler
• app/zeebe-api

There could be also an easy-to-use introduction on how to use those modules to build their own Modeler (via an example or simple starting guide).

Describe alternatives you've considered

• Hardly move everything to the Camunda Modeler (not a real alternative).
• Make the properties provider available via bpmn-js-properties-panel (as we already have it with other providers)
• Create separate, ready-to-use bpmn-js distribution which wraps all necessary modules ("zeebe-bpmn-js")

Additional context

Child of https://github.com/bpmn-io/internal-docs/issues/216
Miro Board (Kickoff): https://miro.com/app/board/o9J_lYnRyPQ=/

[pinussilvestrus]

New approach coming from the Kick-Off (28th January)

Create separate, ready-to-use bpmn-js distribution which wraps all necessary modules ("zeebe-bpmn-js")

This will allow us and others to simply use the Zeebe Modeler extensions, baked in a bpmn-js distribution. No need to manually include all separate modules and create an own Modeler.

[pinussilvestrus]

zeebe-bpmn-js experiments go into this project: https://github.com/pinussilvestrus/zeebe-bpmn-js

export default function ZeebeModeler(options) {

  options = {
    ...options,
    moddleExtensions: {
      zeebe: zeebeModdle,
      ...options.moddleExtensions
    }
  };

  Modeler.call(this, options);
}

ZeebeModeler.prototype._zeebeModules = [
  minimapModule,
  modelingModule,
  contextPadModule,
  paletteModule,
  popupMenuModule,
  rulesModule,
  propertiesPanelModule,
  propertiesProviderModule,
  zeebeModdleExtension
];

ZeebeModeler.prototype._modules = [].concat(
  Modeler.prototype._modules,
  ZeebeModeler.prototype._zeebeModules
);

---

Things to be decided

• What modules should be included as well (cf. https://github.com/pinussilvestrus/zeebe-bpmn-js/issues/1)?
• Do we want this at all? Or simply provide modules only?
• What about style sheets? We would have to include them manually
• Do we want an even bigger package (camunda-bpmn-js) to handle both stacks?
  • include distinction at all (cf. The editor is able to distinguish Zeebe and Camunda diagrams camunda/camunda-modeler#2029)
  • Simply get profile via options

export default function UnifiedModeler(options) {

  const {
    profile
  } = options;

  const profiles = {
    camundaCloud: {
      additionalModules: this._zeebeModules,
      moddleExtensions: {
        zeebe: zeebeBpmnModdle
      }
    },
    camundaPlatform: {
      additionalModules: this._camundaModules,
      moddleExtensions: {
        camunda: camundaBpmnModdle
      }
    },

    // ....
  };

  // include modules per profile
  options = {
    ...options,
    additionalModules: [
      ...profiles[profile].additionalModules,
      ...options.additionalModules
    ],
    moddleExtensions: {
      ...profiles[profile].moddleExtensions,
      ...options.moddleExtensions
    }
  };

  Modeler.call(this, options);
}

UnifiedModeler.prototype._zeebeModules = [
  minimapModule,
  modelingModule,
  contextPadModule,
  paletteModule,
  popupMenuModule,
  rulesModule,
  propertiesPanelModule,
  propertiesProviderModule,
  zeebeModdleExtension
];

UnifiedModeler.prototype._camundaModules = [
  // ...
];

[pinussilvestrus]

Option A: simply provide the modules

import Modeler from 'bpmn-js/lib/Modeler';

import zeebeExtensions from 'zeebe-modeling-extensions/lib/modeling-extensions';

import propertiesProvider from 'zeebe-modeling-extensions/lib/properties-provider';

import zeebeModdle from 'zeebe-bpmn-moddle';

const modeler = new Modeler({
  container: 'modeler-container',
  additionalModules: [ 
    zeebeExtensions, 
    propertiesProvider 
  ],
  propertiesPanel: {
    parent: 'properties-container'
  },
  moddleExtensions: { 
    zeebe: zeebeModdle 
  }
});

--> + full flexibility, easier to maintain
--> - lots of configuration needed, even more modules we would not integrate into this basic package (minimap etc.)

Option B: provide zeebe-bpmn-js distribution (and maybe camunda-bpmn-js separately), cf. https://github.com/pinussilvestrus/zeebe-bpmn-js

import Modeler from 'zeebe-bpmn-js/lib/Modeler';

const modeler = new Modeler({
  container: 'modeler-container',
  propertiesPanel: {
    parent: 'properties-container'
  }
});

--> + easy to integrate as zeebe modeler
--> - slightly more overhead, bigger bundle size
--> +/- what about style sheets? Users would have to include them manually
--> - we would need a camunda distribution as well

Option C: Provide full-stack camunda-bpmn-js distribution, cf. #288 (comment)

import Modeler from 'camunda-bpmn-js/lib/Modeler';

const modeler = new Modeler({
  container: 'modeler-container',
  propertiesPanel: {
    parent: 'properties-container'
  },
  profile: 'camundaCloud'
});

--> + ready to use for any use case, already aware of the profile
--> - will be one big monster to maintain
--> - bundles all the stuff, no matter I need it or not

[pinussilvestrus]

Follow ups after discussion with Engineering team on 1st February

--> Option A and B (cf. #288 (comment))

• We would like to have one extra package providing distributions for both Zeebe and Camunda modeling, without being engine agnostic on runtime (cf. option C).
  • One place to maintain, solving different use cases
  • We currently don't have the technical ability to re-reload a Modeler instance with new modules
  • Outside of the Camunda Modeler, we don't really have a use case to offer a unified Modeler package which is profile agnostic
• We can easily choose the right modeling distribution outside of the package
• The user should be able to build whatever she/he wants by getting the packages directly and not using the pre-configured bundle
• Out of this solution, we are free to build a profile-agnostic solution someday (if we want it)

camunda-bpmn-js

// use basic modeling experience (without engine specific stuff)
import Modeler from 'camunda-bpmn-js/lib/base/Modeler';

const modeler = new Modeler({
  container: 'modeler-container',
  propertiesPanel: {
    parent: 'properties-container'
  }
});


// use Camunda Platform specific modeling experience
import Modeler from 'camunda-bpmn-js/lib/camunda-platfom/Modeler';


// use Camunda Cloud specific modeling experience
import Modeler from 'camunda-bpmn-js/lib/camunda-cloud/Modeler';


// create custom Modeler (only Palette + Context Pad changes)
import Modeler from 'bpmn-js/lib/Modeler';

import paletteModule from 'camunda-bpmn-js/lib/camunda-cloud/features/palette';

import contextPad from 'camunda-bpmn-js/lib/camunda-cloud/features/context-pad';

const modeler = new Modeler({
  container: 'modeler-container',
  additionalModules: [ 
    paletteModule,
    contextPad
  ]
});

[pinussilvestrus]

Work happens on https://github.com/camunda/camunda-bpmn-js/

[pinussilvestrus]

Closed via camunda/camunda-bpmn-js@c6a6431. Now available as first version 0.1.0-alpha.0.