Knative Eventing

This document describes how you can configure the workflows to let operator create the knative eventing resources on Kubernetes.

Serverless Logic Operator can analyze the event definitions from the spec.flow and create SinkBinding/Trigger based on the type of the event. Then the workflow service can utilize them for event communications. The same purpose of this feature in quarkus extension can be found here.

Prerequisite

  1. Knative is installed on the cluster and Knative Eventing is initiated with a KnativeEventing CR.

  2. A broker named default is created. Currently all Triggers created by the Serverless Logic Operator will read events from default

Configuring the workflow

For the operator to create the SinkBinding resources, the workflow must provide the sink information in spec.sink.

Example of a workflow with events
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
...
spec:
  sink:
    ref: (1)
      name: default
      namespace: greeting
      apiVersion: eventing.knative.dev/v1
      kind: Broker
  flow:
    events: (2)
      - name: requestQuote
        type: kogito.sw.request.quote
        kind: produced
      - name: aggregatedQuotesResponse,
        type: kogito.loanbroker.aggregated.quotes.response,
        kind: consumed,
        source: /kogito/serverless/loanbroker/aggregator
...
1 spec.sink.ref defines the sink that all created sinkBinding will use as the destination sink for producing events
2 spec.flow.events lists all the events referenced in the workflow. Events with produced kind will trigger the creation of SinkBindings by the Serverless Logic Operator, while those labeled as consumed will lead to the generation of Triggers.

Knative resources are not watched by the operator, indicating they will not undergo automatic reconciliation. This grants users the freedom to make updates at their preference.

Found an issue?

If you find an issue or any misleading information, please feel free to report it here. We really appreciate it!