Kogito Serverless Workflow

Kogito is an implementation of the CNCF Serverless Workflow Specification.

Current Status

Currently, Kogito implements the version 0.8 of the specification.

The following table lists the current status of the features as defined by the specification:

Feature	Status
States	🌓
Functions	🌓
Events	🌓
Retries	🚧
Workflow Data	🌓
Expressions	🌕
Error Handling	🌕
Compensation	🌕

Legend:

Symbol	Meaning
🌕	Fully implemented
🌓	Partially implemented
🚧	To be implemented

The sections below describe in detail the current status of the supported features.

Workflow Model - States

State	Status
Event	🌓
Operation	🌕
Switch	🌕
Delay	🌕
Parallel	🌕
Inject	🌕
ForEach	🌕
Callback	🌕

Event state is not supported as starting state if exclusive flag is set to false. ⚠️ Quarkus is the only supported runtime for Kogito Serverless Workflow.

Examples

1. Event Example
2. Operation Example
3. Switch, Parallel, and SubFlow Example
4. Inject and Switch Example
5. Callback Example

Workflow Model - Functions

Function Type	Status	Obs
rest	🌕	You can find more details about the Kogito OpenAPI implementation here
rpc	🌕
expression	🌕	Either jq or jsonpath
asyncapi	🚧
graphql	🚧
odata	🚧
custom	🌕

Additionally, even though they are not defined in the specification, Kogito also supports sysout and java functions.

Sysout Functions

This function support can be used for debugging reasons:

{
  "functions": [
    {
      "name": "printMessage",
      "metadata": {
        "type": "sysout"
      }
    }
  ]
}

Later in your State definition you can call it with:

{
  "states": [
    {
      "name": "myState",
      "type": "operation",
      "actions": [
        {
          "name": "printAction",
          "functionRef": {
            "refName": "printMessage",
            "arguments": {
              "message": "."
            }
          }
        }
      ]
    }
  ]
}

You should see the data output in your console.

Java Functions

Kogito also supports calling Java functions within the maven project which the workflow is defined. You can declare your functions like this:

{
  "functions": [
    {
      "name": "myFunction",
      "type": "custom",
      "operation": "service:java:com.acme.MyInterfaceOrClass::myMethod"
    }
  ]
}

Your method's interface must receive a Jackson's JsonNode object and return either void or another JsonNode. For example:

public class MyInterfaceOrClass {

    public void myMethod(JsonNode workflowData) {
        // do whatever I want with the JsonNode:
        // { "workflowdata": {} }
    }

    public JsonNode myMethod(JsonNode workflowData) {
        // do whatever I want with the JsonNode:
        // { "workflowdata": {} }
        // return the modified content:
        return workflowData;
    }
}

To call this function within your workflow you can extract the json value you need via a jq expression or pass it without any arguments. In this case the whole payload is sent.

For example:

{
  "states": [
    {
      "name": "myState",
      "type": "operation",
      "actions": [
        {
          "name": "callJavaFunctionAction",
          "functionRef": {
            "refName": "myFunction"
          }
        }
      ]
    }
  ]
}

Or, if you prefer you can pass only the necessary data:

{
  "states": [
    {
      "name": "myState",
      "type": "operation",
      "actions": [
        {
          "name": "callJavaFunctionAction",
          "functionRef": {
            "refName": "myFunction",
            "arguments": {
              "data": ".my.path.to.data"
            }
          }
        }
      ]
    }
  ]
}

Examples

1. Functions With Quarkus
2. Funqy
3. The GitHub Showcase
4. Greetings Example With Quarkus
5. Temperature Conversion Example

Workflow Model - Events

Definition	Status	Obs
Name	🌕
Source	🌕
Type	🌕
Kind	🌕
Correlation	🚧
Metadata	🌕
Data only	🌓	Default is "dataOnly": true. "dataOnly": false is ignored

Examples

1. Events With Quarkus
2. Functions With Events
3. Order Processing

Workflow Model - Retries

Retries hasn't been implemented yet, but it's in our roadmap for the future versions.

Alternatively to retries, you can use our error handling feature.

Workflow Data

Data manipulation (transformation) on Kogito is fully implemented and can be used either jq or jsonpath. State and Action data filtering is also supported.

Workflow Expressions

Kogito supports either jq or jsonpath to define workflow expressions. As defined in the specification, jq is the default expression language. If you wish to use jsonpath instead, set the attribute expressionLang in the workflow definition:

{
  "id": "myworkflow",
  "version": "1.0",
  "expressionLang": "jsonpath",
  "name": "Workflow example",
  "description": "An example of how to use workflows"
}

Example

1. Expressions With Quarkus

Workflow Error Handling

Kogito supports error handling. Find more details about this implementation on our documentation.

1. Error Handling With Quarkus

Workflow Compensation

Kogito supports workflow compensation as described in the specification.

Examples

1. Workflow Compensation With Quarkus