Camunda Modeler Documentation
repository·develop·Indexed 23 days ago
https://github.com/camunda/camunda-modelerA desktop-based modeling tool for creating BPMN diagrams, DMN decisions, and Forms for the Camunda ecosystem. Powered by bpmn.io, it includes features for custom element templates, plugin extensibility, and Zeebe API integration. The documentation covers building the application from source, configuring templates, and the internal Electron architecture including IPC bridges for file system and configuration management.
What's inside Camunda Modeler
- Camunda Modeler is a desktop application used for modeling BPMN diagrams, DMN decisions, and Forms. It is powered by bpmn.io and is designed to be used alongside an IDE to implement solutions with Camunda.
Access official Camunda Modeler documentation
developFor comprehensive guides, tutorials, and detailed information regarding the Camunda Modeler, refer to the official Camunda documentation website.Register Camunda Modeler as the default editor on Linux
developTo set Camunda Modeler as the default application for opening BPMN and DMN files on Linux, run the./xdg_register.shscript. This script utilizesxdg-utilsto ensure compatibility with major Linux desktop environments../xdg_register.shRun Camunda Modeler in development mode
developTo spin up the application for development, use thenpm run devcommand.npm run devConfigure Element Templates in Camunda Modeler
developYou can provide custom element templates to Camunda Modeler using three different scopes: project-specific, global, or directory-based. This allows you to define reusable properties and configurations for BPMN, CMMN, or DMN elements.
1. Project-Specific Templates
Store templates directly in the
resources/platform/base/resources/element-templates/directory within the repository to include them in the current build/project.2. Global Templates (Across all Modeler installations)
To make templates available for all diagrams regardless of the project, store them in the
resources/element-templatesdirectory located in the Camunda Modeler's data directory.3. Directory-Based Templates (Specific diagrams)
To restrict templates to a specific set of diagrams, store them in a
.camunda/element-templatesdirectory. This directory can be placed in the diagram's parent directory or any of its ancestor directories.Extend Camunda Modeler with plugins
developTo extend the functionality of the Camunda Modeler, you can place plugin implementations into thepluginsdirectory. This directory serves as the loading point for custom extensions.Register Camunda Modeler as the default editor for BPMN and DMN files on Windows
developOn Windows systems, you can use the provided batch script to register Camunda Modeler as the default application for opening
.bpmnand.dmnfiles. This allows you to open these file types directly from File Explorer using the Modeler.Run the following script located in the
resources/platform/win32/support/directory:register_fileassoc.batregister_fileassoc.batUnregister Camunda Modeler as the default editor on Linux
developTo remove Camunda Modeler from being the default application for BPMN and DMN files, run the./xdg_unregister.shscript. This reverts the changes made by the registration script../xdg_unregister.shBuild the Camunda Modeler application
developTo build the Camunda Modeler application, you must use a Posix environment (such as Git Bash or WSL on Windows). Ensure you have installed all necessary tools required to compile Node.js C++ addons (e.g.,
node-gypdependencies).# checkout a tag git checkout main # install dependencies npm install # execute all checks (lint, test and build) npm run all # build the application to ./dist npm run buildUnderstand the Camunda Modeler Main Process Architecture
developThe
app/lib/index.jsfile serves as the main entrypoint for the Camunda Modeler Electron application. It initializes the core application components (bootstrap), manages the main window lifecycle, handles IPC (Inter-Process Communication) between the main and renderer processes, and coordinates system-level services like file systems, plugins, and Zeebe API connections.Key responsibilities include:
- Bootstrapping: Initializing
Config,Flags,Plugins,ZeebeAPI, andFileContext. - Window Management: Creating and managing the
BrowserWindow(the editor). - IPC Bridge: Exposing main-process capabilities (file I/O, dialogs, Zeebe operations, configuration) to the renderer process via
renderer.onlisteners. - Lifecycle Management: Handling application startup, window focus/blur, and graceful shutdown/quit verification.
- Bootstrapping: Initializing
Register a resource provider for deployment
developA resource provider is a function used to intercept and modify the list of resources before they are deployed. This is useful for automatically adding additional files (like data or process definitions) to a deployment.
Signature:
(configs: ResourceConfig[]) => ResourceConfig[]Providers are applied in the order they are registered. The return value must be an array of
ResourceConfigobjects.Handle file change detection and auto-save
developThe Modeler automatically manages file synchronization to prevent data loss:
- External Changes: When the window regains focus (
app.focused), the app triggerscheck-file-changed. If a file has been modified externally and the current tab is not 'dirty' (has no unsaved changes), the tab is silently reloaded. If the tab is dirty, the user is prompted to reload or keep local changes. - Auto-save: When the window loses focus (
app.blurred), the app triggers an auto-save of the active tab, provided no modal dialog is currently open. - Dirty State: A tab is considered 'dirty' if it has unsaved changes. This is tracked via
isDirty(tab)and managed throughsetDirty(tab, boolean).
- External Changes: When the window regains focus (