Skip to content

Events

Direktiv utilizes the HTTP Protocol Binding for CloudEvents, and offers two distinct ways to produce and consume events. The easiest approach is by using Direktiv's API directly in order to route your desired events. However, if you require more flexibility, Knative can assist with a more powerful and dynamic approach when it comes to eventing. What type of integration is ideal depends on which use cases are meant to be addressed by Direktiv. Independent from this integration approach system internal events within Direktiv are always supported.

Direktiv Eventing

Event API

The event API provides direct access to Direktiv's eventing system. The general API path is /api/namespaces/{namespace}/broadcast. Following the cloud-event specification events can be send to Direktiv in three different formats.

Event ID

The specification requires an event ID. Direktiv generates a random ID if not provided by the client.

Binary Content Mode

Th binary content mode uses headers to describe the event metadata with a "ce-" prefix and allows for efficient transfer and without transcoding effort. The header "content-type" must be set to the content-type of the body of the event.

POST /api/namespaces/{namespace}/broadcast HTTP/1.1
Host: direktiv.io
ce-specversion: 1.0
ce-type: com.example.event
ce-id: 1234-1234-1234
ce-source: /mycontext/subcontext
Content-Type: application/json; charset=utf-8

{
   "hello": "world"
}

Structured Content Mode

In structured mode the whole cloudevent is in the payload. The content-type header needs to be set to "application/cloudevents+json".

{
    "specversion" : "1.0",
    "type" : "com.github.pull_request.opened",
    "source" : "https://github.com/cloudevents/spec/pull",
    "subject" : "123",
    "id" : "A234-1234-1234",
    "datacontenttype" : "text/xml",
    "data" : "<much wow=\"xml\"/>"
}

Batched Content Mode

In batch mode multiple events can be send to direktiv. The content-type has to be "application/cloudevents-batch+json" and the body is a JSON array of cloud events.

[
    {
    "specversion" : "1.0",
    "type" : "com.github.pull_request.opened",
    "source" : "https://github.com/cloudevents/spec/pull",
    "subject" : "123",
    "id" : "C234-1234-1234",
    "datacontenttype" : "text/xml",
    "data" : "<much wow=\"xml\"/>"
    },
    {
    "specversion" : "1.0",
    "type" : "com.github.pull_request.opened",
    "source" : "https://github.com/cloudevents/spec/pull",
    "subject" : "123",
    "id" : "B234-1234-1234",
    "datacontenttype" : "text/xml",
    "data" : "<much wow=\"xml\"/>"
    }
]

Other Data

If unknown data arrives at the API endpoint Direktiv does not drop the data but converts it into a cloud event. The value for type is set to noncompliant and source to unknown. The payload of the original requets will be base64 encoded and added as data_base64 to the event. If the content type can be guessed or is provided in the header it will be part of the cloud event as well.

{
  "noncompliant": {
    "data_base64": "aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1kUXc0dzlXZ1hjUQ==",
    "datacontenttype": "text/plain",
    "error": "unknown Message encoding",
    "id": "60290f4b-3971-411a-b824-73b60eb8b72d",
    "source": "unknown",
    "specversion": "1.0",
    "type": "noncompliant"
  }
}

Events in Flows

Events in a Direktiv flow can be a start condition and initiate a flow or a workflow can wait for an event during flow execution. Direktiv can wait for single events or on AND and OR combinations of events.

Event Start Type Example

The following is an example of a simple start condition for a Direktiv flow. A start condition requires the type and additional context values can be provided. If context values are defined the cloud event has to match the context attribute. For matching glob values can be used.

start:
  type: event
  state: helloworld
  event:
    type: io.direktiv.myevent
    context:
      myvalue: my*
states:
- id: helloworld
  type: noop
  log: jq(.)

The above example flow would trigger if the following cloud event would arrive:

{
    "specversion" : "1.0",
    "type" : "io.direktiv.myevent",
    "source" : "https://github.com/cloudevents/spec/pull",
    "subject" : "123",
    "myvalue": "mydata"
}

Because the defintion uses a glob pattern valid values fo myvalue could be everything starting with my. If the attribute is missing or does not start with my the workflow would not trigger.

Events in Flow Example

Waiting for events within a flow is similar to a start definition except the context can be used to "link" flows to each other via context attributes in events. Additionally it can handle timeouts if an event has not been received within a certain time.

states:

- id: wait-event
  type: consumeEvent
  timeout: PT1M
  event:
    type: io.direktiv.myevent
    context:
      customer: jq(.customer)
  catch: 
  - error: "direktiv.cancels.timeout.soft"
    transition: timedout

- id: timedout
  type: noop
  log: this event timed out