BPM Concepts
In the following section, we will explore key concepts essential to understanding the Jmix BPM with the embedded Flowable Process Engine. These concepts include process models, process definitions, executions, process instances, deployments, tokens, and the process context. Each of these elements plays a vital role in how the engine operates, facilitating the execution and management of business processes.
Process Lifecycle
The process lifecycle in Jmix BPM encompasses the various stages that a process instance undergoes from its initiation to completion. Understanding this lifecycle is crucial for effectively managing and controlling business processes.
Modeling
The lifecycle begins with the modeling stage, where business processes models are designed and defined using BPMN 2.0 notation. This involves creating process models that specify the flow, tasks, events, and decision points within the process. Process models are represented in XML format.
Beyond the XML model, developers must undertake several additional tasks to create a fully executable business process:
-
Business Logic Implementation
-
User Interface (UI) Forms Creation
-
Decision Tables Definition
-
Event Listeners and Error Handling
Deployment
After modeling, the process models are to be deployed to the process engine. This step packages the BPMN models and resources into deployments to make them available for execution. Deployments ensure that the process definitions are correctly registered within the engine.
Instantiating
Once a process definition is deployed, new process instances can be started. Each instance represents a specific execution of the process and is uniquely identified. The process instance is initialized with any necessary variables and data.
Execution
As the process instance progresses, it transitions through various states managed by the process engine. The engine controls the flow based on the defined process model, navigating between tasks, events, and gateways. During execution, the engine may create execution artifacts to handle parallel paths, multi-instance activities, or subprocesses, ensuring that all aspects of the process are effectively managed.
State Management
During execution, the process instance can exist in various states, such as running or suspended. The engine facilitates dynamic management of these states, allowing processes to be paused or resumed as necessary. This capability extends not only to process instances but also to process definitions, enabling both to be suspended and activated as needed.
Completion
A process instance is considered complete when all tasks have been finished, and there are no remaining active elements, such as tasks, events, gateways, or subprocesses, within the process. At this point, the engine finalizes the execution, and the instance transitions to its end state. Any associated data can then be retrieved for reporting or auditing purposes.
Termination
In some cases, a process instance may be terminated prematurely due to errors or user intervention. The engine provides mechanisms to handle such terminations gracefully, ensuring that the process state remains consistent.
History
Flowable maintains a history of process instances, capturing important events and state changes throughout the lifecycle. This historical data is valuable for auditing, reporting, and analyzing process performance. It allows organizations to review past executions and gain insights into process efficiency and effectiveness.
Tokens
The token is a key concept in BPMN that helps to understand and define the behavior of a process during execution. A token represents the current state of the process and serves as a means to visualize how the process behaves at runtime.
When a process is started, a token is created, typically initiated by a start event. This token flows through the process, following the sequence flows and interacting with the process elements it encounters. At parallel gateways, the token can split into multiple tokens, and at other points in the process, these tokens can merge back. The token is consumed when it reaches an end event, which signifies the completion of the process instance.
Each process instance has its own token that tracks the state of that specific instance. Multiple process instances can run concurrently, with each maintaining its own token. When a token arrives at an activity, it becomes ready to start, and it interacts with gateways to determine the path it will follow. It is important to note that tokens cannot traverse message flows; only messages can flow along message flows.
|
Direct access to tokens in the context of BPMN execution (as in tracking or manipulating process tokens) is not explicitly provided through the Flowable API. Instead, the Process Engine API primarily focuses on managing process instances, tasks, and events rather than exposing tokens as a separate entity. |
Business Key
A business key is a way to identify a process instance based on business-specific criteria, rather than relying solely on the system-generated process instance ID. The business key allows you to associate a process instance with a specific business entity or context.
For example, a business key can be:
-
Order number
-
Employee ID
-
Contract number
-
Address
-
… and so on
When the process instance is provided with the business key, it helps users to understand business context.
You can define a business key in the input dialog form for the start event,
see details here.
In the Jmix view form, you can define a business key using ProcessFormContext,
see here.
As well, it is possible to set or update a business key programmatically via API, see example here.
Process Context
The process context is the collection of data utilized throughout the execution of a process. It encompasses all relevant information, including process variables, execution state, user roles, and any other data necessary for managing and guiding the workflow effectively. This context serves as the foundation for decision-making and operational flow within the process, ensuring that all components have access to the information they need to function correctly.
This is a conceptual framework; the process engine does not provide a specific object or class to represent the process context.
