Dynamic Signaling for Managing Communication Between Two Separate BPMN Flows

This document explains how to implement Dynamic Signaling in BPMN processes or event sub-processes to execute particular process instances or threads.

Problem Statement:

  • A signal event is generally used to communicate between two separate BPMN flows.
  • However, the signal event has a global scope. It will broadcast the event to all related sub-flows and handlers.

Whenever BPMN interacts with multiple requests, it is difficult for the process engine to identify the exact instance to process. There is also the possibility of the thrown signal getting caught by all active handlers and multiple requests at a time, which may lead to wrong execution. 

BPMN Workflows Version Management With Milestone Camunda Cawemo

This article contains a step-by-step guide on how to manage BPMN file versioning and avoid conflicts in Cawemo when multiple team members are working together. It will also help you to avoid overriding BPMN files while updating and tells you how to sync files between the repository and Cawemo. 

What Is Milestone?

  • This feature in the Cawemo tool is used to maintain Versioning in BPMN.
  • We can see all of the BPMN history, the creator’s name who has done the changes, and the Last Changed date.
  • We can upload the new version of BPMN without removing/deleting its older version.

Steps to Follow:

  • Create a new directory (e.g., Demo) in Cawemo for signed-off deployed BPMN files.
  • Upload working/developed and integrated BPMN (e.g., Demo_BPMN) from code repository/local to the newly created directory as follows.

Upload working/developed and integrated BPMN (e.g., Demo_BPMN) from code repository/local to the newly created directory

Checking Out Camunda: Replacing the Old BPMS Legacy System

Traditional BPM or tightly coupled application although designed in accurate way but over the time due to addition of new functionality and lack of old version product support usually it ends up with the following problems:

  • Heavyweight system that is hard to install and to maintain.
  • Closed architecture, hard to integrate with existing technology stack.
  • Required their proprietary approach to application development, disliked by software developers and limited in flexibility.
  • Lack of support for BPMN, or missing features and tools.
  • Issues with performance and scalability.
  • Difficult to get qualified, affordable professional services.
  • Total Cost of Ownership (TCO) too high, in part due to high maintenance fees.

As a result, only BPMS replacement or redesigned option remains.