Files

master f5b5f24d95 Add StellaOps.Workflow engine: 14 libraries, WebService, 8 test projects

Extract product-agnostic workflow engine from Ablera.Serdica.Workflow into
standalone StellaOps.Workflow.* libraries targeting net10.0.

Libraries (14):
- Contracts, Abstractions (compiler, decompiler, expression runtime)
- Engine (execution, signaling, scheduling, projections, hosted services)
- ElkSharp (generic graph layout algorithm)
- Renderer.ElkSharp, Renderer.ElkJs, Renderer.Msagl, Renderer.Svg
- Signaling.Redis, Signaling.OracleAq
- DataStore.MongoDB, DataStore.PostgreSQL, DataStore.Oracle

WebService: ASP.NET Core Minimal API with 22 endpoints

Tests (8 projects, 109 tests pass):
- Engine.Tests (105 pass), WebService.Tests (4 E2E pass)
- Renderer.Tests, DataStore.MongoDB/Oracle/PostgreSQL.Tests
- Signaling.Redis.Tests, IntegrationTests.Shared

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-03-20 19:14:44 +02:00

4.0 KiB

Raw Blame History

Serdica Workflow Engine Architecture

Purpose

This folder defines the target architecture for the workflow engine runtime.

The design in this folder assumes:

authored C# workflow classes remain the source of truth
workflows are already fully declarative and can be compiled to canonical definitions
the service will run a single engine provider per deployment
migration and concurrent engine execution are out of scope for v1
Oracle is the durable system of record
Oracle Advanced Queuing is the default signaling and scheduling backend
Redis is optional and not on the correctness path

This package is intentionally detailed. It documents engine behavior, persistence, signaling, and runtime structure. Platform transport and command-mapping details are outside its scope.

Reading Order

Executive Summary

The engine is designed around six core decisions:

Workflow execution moves from the earlier runtime to a canonical interpreter owned by the engine.
The interpreter executes canonical workflow definitions compiled from authored C# workflows.
Oracle remains the single durable source of truth for workflow runtime state, projections, and host coordination.
Oracle AQ provides durable signaling and scheduling with blocking dequeue semantics, which removes polling from the steady-state engine path.
The engine uses a run-to-wait model: an instance is loaded, advanced until the next wait boundary, persisted, and released. No node permanently owns an instance.
The workflow service surface remains stable. The engine is a runtime replacement, not a transport or UI rewrite.

Scope Summary

In Scope

start workflow
activate human tasks
assign, release, and complete tasks
execute canonical transport calls
execute canonical conditions, loops, branches, and subworkflows
schedule delayed resumes and retry wakes without polling
resume safely after node, service, or full-cluster restart
support multi-instance deployment with one shared database
preserve read-side service contracts, projections, authorization, diagrams, retention, and canonical inspection

Out of Scope

concurrent old-runtime and engine execution
in-place instance migration between engines
Redis as a correctness-grade signaling dependency
user-facing workflow authoring changes
replacing the public workflow service surface

Product Position

At the workflow-service boundary, the runtime still has to support:

workflow and task operations
the task inbox and assignment system
the workflow diagram provider
canonical definition and validation access
the operational retention owner

The engine is a runtime subsystem under the workflow service, not a separate product.

Design Baseline

The engine architecture in this folder should be treated as the default implementation plan unless a later ADR explicitly replaces part of it.

4.0 KiB Raw Blame History