Skip to content
/ wfx Public

a lightweight, general-purpose workflow executor

License

Notifications You must be signed in to change notification settings

siemens/wfx

Folders and files

NameName
Last commit message
Last commit date
Mar 12, 2025
Mar 12, 2025
Jun 1, 2023
Dec 23, 2024
Mar 3, 2025
Mar 3, 2025
Mar 3, 2025
Mar 3, 2025
Jan 10, 2024
Mar 3, 2025
Mar 3, 2025
Mar 3, 2025
Dec 23, 2024
Mar 11, 2025
Nov 9, 2023
Mar 3, 2025
Mar 3, 2025
Mar 3, 2025
Jun 1, 2023
Jun 1, 2023
Dec 23, 2024
Mar 12, 2025
Jun 1, 2023
Feb 12, 2025
Mar 3, 2025
Mar 3, 2025
Jun 16, 2023
Jun 1, 2023
Mar 11, 2025
Jun 1, 2023
Jun 1, 2023
Feb 10, 2025
Jun 1, 2023
Mar 3, 2025
Feb 1, 2025
May 17, 2023
Feb 13, 2025
Jun 1, 2023
Mar 12, 2025
Mar 13, 2025
Mar 13, 2025
Mar 12, 2025
Jan 30, 2025
Mar 3, 2025
Feb 13, 2025
Mar 3, 2025

wfx

A lightweight, general-purpose workflow executor.

CI Pages Coverage

Overview

Workflows are modeled as finite-state machines and are instantiated as Jobs through which the wfx and a client progress in lock-step to perform a task. Such a task could be software updating the client, progressing a work item through Kanban, … in essence anything requiring cooperation and coordination.

As being general purpose, wfx is only concerned with driving the (state) machinery, the specific actions a client should perform are encoded in the client implementation(s). Hence, one wfx instance can drive a multitude of wholly different workflows. Instantiating a workflow as a job augments it with additional metadata, the Job Definition, which contains job-specific information such as, e.g., URLs or other data the client (implementation) can make use of for this particular job.

To illustrate the concepts as well as the wfx / client interaction, consider the following figure

┌──────────────────────────────────────┐                       ┌──────────────┐
│                 wfx                  │                     ┌─┴────────────┐ │
│                                      │                     │   Client Y   │ │
│                                      │     poll for jobs   │              │ │
│                instantiate ┌───────┐ │◀────────────────────│              │ │
│  ┌────────────┐        ┌──▶│ Job 1 │ │────────────────────▶│──────┐       │ │
│  │ Workflow A ├────────┤   └───────┘ │◀─┐  job information │      ▼       │ │
│  └────────────┘        │   ┌───────┐ │  │                  │     act      │ │
│                   ┌────┼──▶│ Job 2 │ │  └──────────────────│◀─────┘       │ │
│  ┌────────────┐   │    │   └───────┘ │     update state    │              │ │
│  │ Workflow B ├───┘    │   ┌───────┐ │                     │              │ │
│  └────────────┘        └──▶│ Job 3 │ │           .         │              │ │
│                            └───────┘ │           .         │              │ │
│       ...                     ...    │           .         │              │ │
│                                      │                     │              ├─┘
└──────────────────────────────────────┘                     └──────────────┘

with the wfx having loaded a number of workflows Workflow A, Workflow B, … that got instantiated as Job 1, Job 2, Job 3, … with a Client Y working on Job 1: It polls the wfx for a new job or the current job's status, in return receives the job information, performs actions if applicable, and finally reports the new job status back to the wfx. This lock-step procedure is repeated until the workflow reaches a terminal state which could be identified with, e.g., success or failure.

wfx in (Example) Action

An exemplary Kanban-inspired workflow illustrating the interplay between the wfx as Kanban "Board", a Product Owner creating jobs, and a Developer executing them:

Konsole Demo

wfx Features & Non-Features

  • Design Guidelines
    • Compact, scalable core focusing on the essentials
    • Proper interfaces to external systems for modularity and integrability: Accompanying and necessary services like artifact storage and device registry are likely already available or are better provided by specialized solutions
  • Implementation
    • Extendable modularized source code architecture
    • Lightweight, no dependencies (statically linked binaries)
    • Efficient, native code for a wide variety of platforms and operating systems (as supported by the Go Language)
    • Fully documented REST API, see wfx OpenAPI Specification
    • Extensive test suite including load tests
  • Deployment / Usability
    • Load / Unload workflows at run-time
    • Hot / Live reload of configuration file
    • Persistent Storage: built-in support for SQLite, PostgreSQL and MySQL
    • A complimentary built-in file server serving as artifact storage for dynamic deployments and integration without external file storage
    • Transport Layer Security (HTTPS) with support for custom certificates

wfx Clients

Currently, the following clients have support for wfx:

Documentation

Grouped by topic, the following documentation is available in docs/:

You can also browse the rendered documentation at https://siemens.github.io/wfx/.

Roadmap

The roadmap is tracked via Github issues.

Contributing

Contributions are encouraged and welcome!

See CONTRIBUTING.md for details.

License

Copyright ©️ 2023 Siemens AG.

Released under the Apache-2.0 license.