Motivation

Knative Eventing is a serverless platform that enables developers to create event producers and consumers for their applications. Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and consumers. These events conform to the CloudEvents specification, which enables creating, parsing, sending, and receiving events in any programming language.

Goal

Enable workflows to communicate via events

Scenarios

As a developer, I need to consume events from the Knative Eventing platform so that they can be used to start and progress in a workflow.

As a developer, I need to react upon domain-specific events coming from workflows in knative event-driven applications.

As a developer, I need to address workflow(s) via a workflow identifier when sending an event so that the event is not consumed by other active workflows for which the event is not destined.

Expected outcomes

Workflows can produce events in Knative Eventing and work as an event source

Workflows can consume CloudEvents over HTTP

Only CloudEvents are supported

Workflow instances are correlated with incoming events via workflow identifier

Correlation of events (between events) is out of scope - that’s for complex event processing

Domain-specific data correlation between workflow and events will be delivered as part of SRVCOM-1842

[nice to have] Workflows can use incoming events from Knative Eventing and work as an event sink