Open Workflow Specification

Open Workflow Specification is a vendor-neutral, open-source, and community-driven ecosystem for defining and executing workflows using a Domain Specific Language (DSL). It is designed to be event-driven, service-oriented, and FaaS-centric, allowing for seamless integration with standard protocols like HTTP, GRPC, OpenAPI, and AsyncAPI.

Key capabilities include:

• Event-Driven Architecture: Support for various event formats, including CloudEvents.
• Service Integration: Interaction with services via standard application protocols.
• Fault Tolerance: Built-in error handling strategies for robust execution.
• Scheduling: Support for CRON expressions and event-based triggers.
• Control Flow: Support for conditional branching, event handling, and looping constructs.

Use this comparison to evaluate the Open Workflow Specification against other major orchestration engines like AWS Step Functions, Google Workflows, Argo Workflows, BPMN, Prefect, and Dagster.

Key differentiators for Open Workflow Specification include:

• Cloud Agnosticism: Unlike AWS or Google Workflows, it is not tied to a specific provider, offering high portability.
• Event-Driven Capabilities: It provides out-of-the-box support for event streaming, complex event processing, and event correlation, which are absent in many other platforms.
• Data Manipulation: It supports advanced data filtering and mutation using jq and JavaScript.
• Open Source: It is a CNCF-hosted open-source project, avoiding the vendor lock-in associated with proprietary services.

A workflow is a sequence of tasks executed in a defined order (by default, the order they are declared). Workflows are used to automate processes and orchestrate services.

Workflows can be triggered via:

• Direct requests
• Scheduled CRON expressions
• Event correlation

Workflows can optionally accept inputs and produce outputs for data processing.

An AsyncAPI subscription allows you to listen to an AsyncAPI operation.

Key Behaviors:

• An AsyncAPI subscribe operation produces a sequentially ordered array of all consumed messages.
• If foreach is used, tasks for each message must complete before the next one begins. Messages should be stored in a FIFO queue during this process.

Properties:

• filter (string): A runtime expression used to filter consumed messages.
• consume (subscriptionLifetime): Required. Configures the subscription's lifetime (how long/how many messages to collect).
• foreach (subscriptionIterator): Configures an iterator for processing each consumed message.

subscription:
  filter: ${ . == $workflow.input.chat.roomId } 
  consume:
    amount: 5
    for:
      seconds: 10

An event consumption strategy defines how a workflow waits for events before proceeding. You must choose one of the following modes:

• all: Wait for all defined eventFilter[] to occur.
• any: Wait for any of the defined eventFilter[] to occur. If the list is empty, it listens to all incoming events.
• one: Wait for a single specific eventFilter to occur.

If any is used, you can provide an until property (a runtime expression or specific events) to define the condition that stops the listener. If until is omitted, the workflow proceeds to the next task as soon as any event is received.

Workflows can be scheduled using four key properties to control execution timing and triggers:

• every: Defines a fixed interval for periodic execution, regardless of previous run status.
• cron: Uses CRON expressions for execution at specific times or intervals.
• after: Specifies a delay duration to wait before restarting a workflow after it completes.
• on: Enables event-driven scheduling, triggering execution based on external events.

For detailed syntax, refer to the DSL reference.

The CTK uses a structured approach to Gherkin steps, categorized into three groups to improve readability and maintainability:

1. Arrange: Sets up the initial state (e.g., defining the workflow and setting input data).
2. Act: Triggers the workflow execution.
3. Assert: Verifies the outcome (e.g., checking if the workflow completed, faulted, or produced specific output).

This structure helps stakeholders understand the intent of each step in the test flow.

While both enable event-driven behavior, they operate at different stages of the workflow lifecycle:

The specification defines four primary constituencies (users), prioritized in order of importance for design decisions:

1. Authors: The primary users who author and read workflows. Their needs are the highest priority.
2. Operators: Users who run and operate runtime implementations of the specification.
3. Implementors: Developers building specification-compliant runtimes.
4. Specifications writers: Those working on the Open Workflow Specification itself.

When encountering design trade-offs, the specification dictates that author needs should be prioritized over operator, implementor, and specification writer needs.