Delivery and CloudEvents

Publishing#

A route publishes with to: kamelet:weikio-event-sink?channel=invoice-created. The event goes from the process to the site’s message server and on to the hub, and the step waits until the hub confirms it stored the event. When it can’t, for example while the site’s link is down, the route’s exchange fails, so the route sees it and its own error handling decides what to do.

Reading#

Each integration that reads a stored channel gets a durable reader, which the platform creates at the hub when you deploy the integration:

• It gets every event published since its first deploy, also those published while it was stopped.
• It confirms each event once its route has finished it.
• A failed event is delivered again after a delay, up to its last attempt.
• The copies of the integration share the reader, so each event goes to one copy.

weikio stop keeps the reader, so a stopped integration picks up where it left off. weikio undeploy deletes it.

Retries and their delays#

The delivery block of an integration says how its events are delivered to it. Every member is optional:

name: invoice-archiver
version: 1.0.0
delivery:
  retries: 10
  retryDelays: [5s, 15s, 30s, 1m, 2m, 5m]
  maxRouteTime: 10m
  inFlight: 1
  ordered: false

An event that still fails after its last attempt goes to the environment’s dead letters.

Handle each event once#

Every event has an ID of its own that stays the same when it is delivered again or sent again. A route whose side effect must not run twice, such as creating an invoice in the ERP, uses Camel’s Idempotent Consumer with the platform’s repository, #weikioIdempotent, which keeps one record per event for every copy of the integration:

- route:
    from:
      uri: "kamelet:weikio-event-source?channel=invoice-created"
      steps:
        - idempotentConsumer:
            header: Weikio-Event-Id
            idempotentRepository: "#weikioIdempotent"
            steps:
              - to: "{{erp-url}}/api/invoices"

An aggregator’s open batch lives in Camel’s in-memory repository. The reader confirms each event once the aggregator has it, so a restart loses the open batch. A route that must keep it uses Camel’s JDBC aggregation repository.

A channel that delivers#

A channel with a type also delivers its events to another system. The type is a Camel sink kamelet without its -sink suffix, with the kamelet’s own parameters. Slack, S3, SFTP, Kafka, JMS, HTTP and every other sink in Camel’s catalog is one document:

apiVersion: weik.io/v1
kind: event-channel
metadata: { name: invoice-alerts, project: finance }
spec:
  type: slack
  parameters:
    channel: "#invoices"
    webhookUrl: "{{slack-webhook-url}}"

The platform writes the delivering route for you. A channel with a type is an integration with versions and deployments, so deploy it to the environments that deliver:

$ weikio apply -f ./finance/events/
$ weikio deploy finance/invoice-alerts --env production

The same channel is still a stored topic that your own integrations publish into and read, and its delivery is one more reader of it.

CloudEvents#

An event is stored as the route published it, with the body unchanged and no CloudEvents envelope around it. Beside the body it carries only the platform’s own headers, such as Weikio-Event-Id and Weikio-Source, and the other headers your route sets aren’t stored with it. A channel with a type hands its sink kamelet the body as it was published.

When a site’s link is down#

An event published into a stored channel while the site’s link is down isn’t stored. The route’s exchange fails, so the route knows. A reader of a stored channel gets what was published while it wasn’t running once it runs again. A pass-through channel keeps nothing, so its readers miss what was published while they were away.