Using Triggers and sinks

    In this topic, we will use the CloudEvents Player as the sink as well as a source. This means we will be using the CloudEvents Player to both send and receive events. We will use a Trigger to listen for events in the Broker to send to the sink.

    Create a Trigger that listens for CloudEvents from the event source and places them into the sink, which is also the CloudEvents Player app.

    knYAML

    To create the Trigger, run the command:

    Expected output

      1. Copy the following YAML into a file named ce-trigger.yaml:

      What CloudEvents is my Trigger listening for?

      Because we didn’t specify a --filter in our command, the Trigger is listening for any CloudEvents coming into the Broker.

      Expand the next note to see how to use Filters.

      Now, when we go back to the CloudEvents Player and send an event, we see that CloudEvents are both sent and received by the CloudEvents Player:

      What if I want to filter on CloudEvent attributes?

      First, delete your existing Trigger:

        Now let’s add a Trigger that listens for a certain CloudEvent Type

        If you send a CloudEvent with type , it is reflected in the CloudEvents Player UI. The Trigger ignores any other types.

        You can filter on any aspect of the CloudEvent you would like to.

        Some people call this “Event-Driven Architecture” which can be used to create your own “Functions as a Service” on Kubernetes 🎉 🔥