Camunda Modeler Documentation

repository·develop·Indexed 23 days ago

https://github.com/camunda/camunda-modeler

A 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.

Tokens
7.9K
Snippets
6
Records
59
Agent score
83%

What's inside Camunda Modeler

  1. Configure Element Templates in Camunda Modeler

    develop

    You 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-templates directory 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-templates directory. This directory can be placed in the diagram's parent directory or any of its ancestor directories.

  2. Register Camunda Modeler as the default editor for BPMN and DMN files on Windows

    develop

    On Windows systems, you can use the provided batch script to register Camunda Modeler as the default application for opening .bpmn and .dmn files. 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.bat

    register_fileassoc.bat
  3. Build the Camunda Modeler application

    develop

    To 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-gyp dependencies).

    # 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 build
  4. Understand the Camunda Modeler Main Process Architecture

    develop

    The app/lib/index.js file 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, and FileContext.
    • 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.on listeners.
    • Lifecycle Management: Handling application startup, window focus/blur, and graceful shutdown/quit verification.
  5. Register a resource provider for deployment

    develop

    A 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 ResourceConfig objects.

  6. Handle file change detection and auto-save

    develop

    The Modeler automatically manages file synchronization to prevent data loss:

    • External Changes: When the window regains focus (app.focused), the app triggers check-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 through setDirty(tab, boolean).