Architecture
BizOps Engine is designed so operators work in a visual client while a Spring Boot API persists projects, workflows, and catalog metadata in MongoDB.
System shape
Qinfinite Shell (Single-SPA)
│
▼
BizOps Engine Web Client (React + React Flow)
│ REST /api/v1
▼
BizOps Workflow Web Service (Spring Boot)
│
├── MongoDB (projects, jobs, workflows, step-data, catalog)
├── Action-type catalog seed / sync
└── Plugin deployment registry (Orchyron bindings)
Key Components
Web client
What operators use every day.
| Capability | Detail |
|---|---|
| Hierarchy screens | Projects → Processes → Jobs navigation |
| Workflow editor | React Flow canvas with step palette and configuration panel |
| Catalog forms | Parameter and table editors driven by action definitions |
| History views | Cycle history and step traces |
| Delivery modes | Standalone Vite app or microfrontend inside the shell |
Workflow API service
The persistence and contract layer.
| Capability | Detail |
|---|---|
| Resource APIs | Projects, processes, jobs, workflows, step-data, runs |
| Catalog APIs | Action-type catalog read/reload (reload typically dev-gated) |
| Plugin registry | Plugin deployment listings joined to action bindings |
| Health endpoints | /health and actuator health for platform probes |
| Storage | MongoDB collections for workflow-engine entities |
Default local API port is commonly 8092. Point the client with VITE_BIZOPS_WORKFLOW_API_BASE_URL.
Action-type catalog
The catalog is the shared vocabulary of actions. On startup the service can:
- Seed Mongo from an in-code catalog when empty
- Sync from an external JSON export when configured
- Fall back to classpath catalog JSON if Mongo has no rows
See Action Catalog for operator-facing details.
Execution path
Depending on deployment, step runtime is handled by:
| Layer | Role |
|---|---|
| Workflow service run APIs | Accept run requests and record history / mock outputs |
| Orchyron / plugin pods | Execute real action plugins when provisioned |
| Observability / analytics sinks | Persist metrics or ROI data when plugins write to stores such as CrateDB |
The open-source-style mock path in the workflow service is intentionally safe for demos and UI validation.
Data model highlights
| Collection / concept | Stores |
|---|---|
| project | Portfolio records |
| process (under project APIs) | Streams inside a project |
| job | Runnable instances |
| workflow | Steps, edges, metadata for a job |
| step-data | Externalized step payloads |
| action-type | Catalog definitions |
| plugin-deployment | Runtime binding metadata for plugins |
Exact collection names can evolve with schema resets in local/dev; treat the REST contract as the stable surface for clients.
Security and platform integration
| Concern | Approach |
|---|---|
| Auth | Bearer token or session cookie via the platform gateway / BFF |
| CORS | Configurable allowed origins for local Vite ports and deployed hosts |
| Secrets | Prefer Global Configurator / vault-backed connections rather than embedding secrets in step JSON |
| Shell integration | Microfrontend basename and shared navigation from the Qinfinite UI shell |
How Engine relates to Dashboard Hub
| Product | Responsibility |
|---|---|
| BizOps Engine | Define and execute business workflows |
| Dashboard Hub | Present hubs of dashboards/widgets for monitoring and business KPIs |
| Shared value | Workflow outcomes and operational metrics become visible on stakeholder dashboards |