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.




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) {


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 -
kind: Subscription
  name: mysub
    - eventSource:
        property: source
        type: exact
        value: ""
        property: type
        type: exact
        value: sap.kyma.custom.nonexistingapp.order.created.v1
  protocol: ""
  protocolsettings: {}
  sink: #this is the service name and port


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. (

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"


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

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Andrey Vishnevskiy
      Andrey Vishnevskiy

      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

      Author's profile photo Remi ASTIER
      Remi ASTIER

      The address of the publishing proxy seems to have changed.

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

      I still see the service in my cluster.

      Author's profile photo Remi ASTIER
      Remi ASTIER

      I execute the same curl command in two namespaces, it works only in the namespace with istio enabled.

      kubectl run -n kyma-system --rm -i --tty mypod --image=curlimages/curl --restart=Never -- curl -v -X POST \
      -H "ce-specversion: 1.0" \
      -H "ce-type: sap.kyma.custom.nonexistingapp.rits.offer.v1" \
      -H "ce-source: myapp" \
      -H "ce-eventtypeversion: v1" \
      -H "ce-id: 94064655-7e9e-4795-97a3-81bfd497aac5" \
      -H "content-type: application/json" \
      -d "{\"orderCode\":\"3211213\", \"orderStatus\":\"changed\"}" \

      Is it because I have istio injection disabled? The subscription works fine.

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

      Hi Remi,

      Yes, you need to enable istio.


      Best regards,


      Author's profile photo Remi ASTIER
      Remi ASTIER

      Thanks, what's the messaging pattern? fire and forget or request reply?

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

      Hi Remi,

      It is fire and forget. Essentially, if you want to have asynchronous flows, you can consider using in-cluster eventing.