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
-
Knative is installed on the cluster and Knative Eventing is initiated with a
KnativeEventing
CR. -
A broker named
default
is created. Currently all Triggers created by the Serverless Logic Operator will read events fromdefault
Configuring the workflow
For the operator to create the SinkBinding
resources, the workflow must provide the sink information in spec.sink
.
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!