Skip to Content
Technical Articles
Author's profile photo Gaurav Abbi

In-cluster eventing in SAP BTP, Kyma runtime

Kyma has recently introduced in-cluster eventing. This implies that you can now implement microservices and serverless functions inside the Kyma runtime that rely on Event-Driven architecture. You can have microservices that can produce events as well as consume events inside Kyma runtime. This enables you to achieve asynchronous flows when required. Earlier it was only possible for connected SAP Solutions such as SAP Commerce Cloud to send events and trigger workloads in Kyma runtime.

As per the Kyma documentation,

In-cluster Eventing allows publishers to send messages and subscribers to receive them without the need for a Kyma Application. This means that instead of the usual event flow where Application Connector publishes events to the Event Publisher Proxy, events can be published from within the cluster directly to the Event Publisher Proxy.

 

 

This is important for business scenarios and use cases where you would like to have asynchronous workflows. Examples include

  • Triggering a long-running background processing based on user actions. This ensures that we reliably execute the processing while at the same time providing a swift response to the user thus providing a better user experience.
  • Doing a fan-out and triggering multiple processes on a single event or action
  • and many others…

Kyma eventing ensures that the event is reliably delivered until the subscriber processes the event successfully.

 

In this blog post, we will walk through a quick tutorial to set up and test the in-cluster eventing in Kyma Runtime.

 

Steps

 

Set up namespace

  • Create namespace¬†in-cluster-events
kubectl create ns in-cluster-events

 

Create a trigger to consume the event

This can be any function or microservice with a Kubernetes Service deployed.
I am using a simple function that just prints the event payload and called it event-subscriber.

It is defined in in-cluster-events namespace.

module.exports = { 
  main: function (event, context) {
    console.log(event.data);
  }
}

 

Create a Subscription to receive events. The subscription custom resource is used to subscribe to events.

cat <<EOF | kubectl -n in-cluster-events apply -f -
apiVersion: eventing.kyma-project.io/v1alpha1
kind: Subscription
metadata:
  name: mysub
spec:
  filter:
    filters:
    - eventSource:
        property: source
        type: exact
        value: ""
      eventType:
        property: type
        type: exact
        value: sap.kyma.custom.nonexistingapp.order.created.v1
  protocol: ""
  protocolsettings: {}
  sink: http://event-subscriber.in-cluster-events.svc.cluster.local #this is the service name and port
EOF

 

This sample Subscription resource subscribes to an event called sap.kyma.custom.nonexistingapp.order.created.v1.

This is defined in the eventType.value property in the Subscription definition.

The sink is the subscriber to which events will be delivered. In this case, it is the function that we have defined earlier. (http://event-subscriber.in-cluster-events.svc.cluster.local)

Now our function is ready to receive any events. Let’s go ahead and send some events

Sending events

 

Create an event producer

Now we need a workload running inside Kyma runtime that can publish events. It can be a microservice or function. The events in Kyma conform to cloudevents specification. You can use various cloudevents SDKs available to produce and consume the events in your preferred technology. To keep this tutorial simple, I will be using curl as my event producer.

Let’s go ahead and launch a pod that has the curl command available and enter the shell.

kubectl -n in-cluster-events run curl --image=radial/busyboxplus:curl -i --tty

After the pod starts, you will be inside the shell of the pod. From there run the curl command to send the event

curl -k -i -X POST \
  "http://eventing-event-publisher-proxy.kyma-system/publish" \
  -H "Content-Type: application/cloudevents+json" \
  --data @- << EOF
  {
        "source": "kyma",
        "specversion": "1.0",
        "eventtypeversion": "v1",
        "data": {"orderCode":"3211213"},
        "datacontenttype": "application/json",
        "id": "759815c3-b142-48f2-bf18-c6502dc0998f",
        "type": "sap.kyma.custom.nonexistingapp.order.created.v1"
  }
EOF

Verify

Check the logs of the function to verify event has been received.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Andrei Vishnevsky
      Andrei Vishnevsky

      Hi Gaurav,

      Thanks a lot for the blog! Very useful and I just implemented in-cluster events to simplify a couple of things in our cluster.

      However, I have a question. In the subscription in the filter for eventSource you have source exact "". And then in the event itself the source is "kyma". Then how is the filter matched? Shouldn't be the filter looks like source exact "kyma" instead? And why does it currently work with the empty value in the filter?

      Author's profile photo Gaurav Abbi
      Gaurav Abbi
      Blog Post Author

      Hi Andrei,

      There are two sources being referred to here.

      one is originating application or event producer and the other is the eventing broker.

      The CRD is best piece of information here https://kyma-project.io/docs/components/eventing/#custom-resource-custom-resource