Skip to main content

Serverless Workflow Specification

Introduction to the Serverless Workflow Specification

The Serverless Workflow Specification (SWS) is a language for defining and executing data processes and workflows. It is based on a JSON or YAML-based DSL, and it provides a range of core concepts and tools for building complex, flexible, and scalable workflow logic.

Introduction to the Cloud Native Computing Foundation (CNCF)

The Cloud Native Computing Foundation (CNCF) is a nonprofit organization that promotes the adoption of cloud native technologies. It is an open-source project under the Linux Foundation, and it was founded in 2015 to support the development and adoption of cloud native technologies.

The CNCF serves as a home for a range of open-source projects and initiatives, including Kubernetes, Prometheus, OpenTracing, Fluentd, gRPC, and many others. These projects are focused on enabling the deployment of cloud native applications and services, and they are developed and maintained by a global community of contributors.

The CNCF Serverless Workflow project was approved as a Cloud Native Sandbox level project in July 2020, and it falls under the CNCF "App Definition and Development" category. It is supported by contributors from companies such as Google, Oracle, Red Hat, IBM, Microsoft, and Temporal.

Benefits of Using the Serverless Workflow Specification

The Serverless Workflow Specification offers a number of benefits for developers and users of the Kutlass workflow engine:

Vendor-neutral and platform-independent

The Serverless Workflow Specification is a vendor-neutral and platform-independent language, which means that it can be used to define and execute workflows on a wide range of different platforms and environments. This allows developers to create portable and interoperable workflow definitions that can be easily deployed and executed on different systems.

Community-driven and open-source

The Serverless Workflow project is a community-driven initiative, and the specification is developed and maintained by a community of contributors from around the world. This ensures that the specification is continuously evolving and improving to meet the needs of the community. Additionally, the specification and related tools are open-source, which means that developers can easily access and contribute to the project.

Powerful and flexible

The Serverless Workflow Specification provides a rich set of features and tools for defining and managing data processes and workflows. It allows developers to model complex, multi-step workflows with dependencies and relationships between different tasks. It also provides tools for managing the execution of workflow instances, such as retry and timeout strategies, error handling, and continuation mechanisms. This enables developers to create sophisticated and scalable workflow logic that can adapt to a wide range of scenarios and requirements.

How to Use the Serverless Workflow Specification with Kutlass

The Kutlass workflow engine is based on the Serverless Workflow Specification, which means that it can execute workflow definitions that conform to the specification. To use the Serverless Workflow Specification with Kutlass, developers can follow these steps:

Write a workflow definition

Develop a workflow definition using the Serverless Workflow Specification DSL. This definition should be written in JSON or YAML format, and it should specify the details of the workflow, including the functions, events, retries, timeouts, errors, and states that make up the workflow logic.

Deploy the workflow definition

Deploy the workflow definition to the Kutlass workflow engine. This can be done using the Kutlass command-line interface (CLI) or API.

Initialize a workflow instance

Initialize a workflow instance using the deployed workflow definition. This can be done by providing initial data inputs and specifying any events that the workflow should consume to start or continue its execution.

Track and manage the workflow instance

Monitor and manage the execution of the workflow instance using the Kutlass CLI or Ionrow GUI. This includes tracking the progress of the workflow, handling errors and timeouts, and reacting to events produced by the workflow.

Example Specifications

Greeting Workflow

This example shows a single Operation State with one action that calls the "greeting" function. The workflow data input is assumed to be the name of the person to greet:

{
"person": {
"name": "John"
}
}

The results of the action is assumed to be the greeting for the provided persons name:

{
"greeting": "Welcome to Serverless Workflow, John!"
}

Which is added to the states data and becomes the workflow data output.

Definition

id: greeting
version: '1.0.0'
specVersion: '0.8'
name: Greeting Workflow
description: Greet Someone
start: Greet
functions:
- name: greetingFunction
operation: file://myapis/greetingapis.json#greeting
states:
- name: Greet
type: operation
actions:
- functionRef:
refName: greetingFunction
arguments:
name: "${ .person.name }"
actionDataFilter:
results: "${ {greeting: .greeting} }"
end: true

Event Based Greeting

This example shows a single Event State with one action that calls the "greeting" function. The event state consumes cloud events of type "greetingEventType". When an event with this type is consumed, the Event state performs a single action that calls the defined "greeting" function.

For the sake of the example we assume that the cloud event we will consume has the format:

{
"specversion" : "1.0",
"type" : "greetingEventType",
"source" : "greetingEventSource",
"data" : {
"greet": {
"name": "John"
}
}
}

The results of the action is assumed to be the full greeting for the provided persons name:

{
"payload": {
"greeting": "Welcome to Serverless Workflow, John!"
}
}

Note that in the workflow definition you can see two filters defined. The event data filter defined inside the consume element:

eventDataFilter:
data: "${ .greet }"
toStateData: "${ .greet }"

which is triggered when the greeting event is consumed. It extracts its "data.greet" of the event data (payload) and merges it with the state data.

The second, a state data filter, which is defined on the event state itself:

stateDataFilter:
output: "${ .payload.greeting }"

filters what is selected to be the state data output which then becomes the workflow data output (as it is an end state):

"Welcome to Serverless Workflow, John!"

Definition

id: eventbasedgreeting
version: '1.0.0'
specVersion: '0.8'
name: Event Based Greeting Workflow
description: Event Based Greeting
start: Greet
events:
- name: GreetingEvent
type: greetingEventType
source: greetingEventSource
functions:
- name: greetingFunction
operation: file://myapis/greetingapis.json#greeting
states:
- name: Greet
type: event
onEvents:
- eventRefs:
- GreetingEvent
eventDataFilter:
data: "${ .greet }"
toStateData: "${ .greet }"
actions:
- functionRef:
refName: greetingFunction
arguments:
name: "${ .greet.name }"
stateDataFilter:
output: "${ .payload.greeting }"
end: true