Skip to main content
Version: Next

WorkFlow Technical Requirements

WorkFlow Technical Requirements​

This page captures the practical constraints for the current WorkFlow subsystem. It is intentionally aligned with what the codebase actually supports today.

Module Positioning​

WorkFlow is a user-customizable process engine influenced by BPMN 2.0 principles. It targets coating line and operational scenarios enabling visual process definition and repeatable executions.

The current implementation is strongest in:

  • process modeling
  • release snapshot generation
  • basic execution advancement

The current implementation is weaker in:

  • real message/timer event runtime
  • inclusive and event-based gateway execution
  • true service invocation contracts
  • responsibility-to-executor resolution

Core Requirements​

  • Visual canvas: drag/drop nodes, draw connections, pan/zoom, auto-layout, undo/redo.
  • Right-side Properties Panel with an issues panel below: the issues area displays structural errors and warnings, has an adjustable height and independent scrolling.
  • Connection metadata: each outgoing connection may hold a branch_key string used by exclusive gateways at runtime.
  • Publishing: design models are snapped into immutable WorkFlowRelease versions; server enforces final publish validation.

Capability Constraints​

The following should be treated as design targets, not as fully delivered runtime guarantees:

  • message-start and timer-start behavior
  • message-catching and timer-catching intermediate events
  • inclusive gateway condition execution
  • event-based gateway race execution
  • automatic service task invocation with timeout/retry strategy
  • responsibility locator runtime resolution

Data and Execution Guarantees​

  • Start/End event invariants (exactly one start, at least one end per publish).
  • Node reachability and orphan detection.
  • Gateway branch condition completeness and unambiguous topology checks.

For current production use, the most reliable path is:

  • start events
  • end events
  • exclusive gateways with branch_key
  • parallel gateways
  • user tasks as modeled activities
  • orthogonal workflow design and release flow

Observability​

  • Provide execution timeline and node-level status logs.
  • Support pause/resume/terminate lifecycle operations on instances.

Best-Practice Recommendation​

When introducing new workflow scenarios, prefer the following rollout order:

  1. model the process graph
  2. publish immutable releases
  3. validate user tasks and gateway routing first
  4. introduce service-task automation only after service-provider contracts are clear
  5. introduce message/timer/event-race semantics only after infrastructure is ready