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,
This is important for business scenarios and use cases where you would like to have asynchronous workflows. Examples include
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.
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
Create a Subscription to receive events. The subscription custom resource is used to subscribe to events.
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
After the pod starts, you will be inside the shell of the pod. From there run the curl command to send the event
Check the logs of the function to verify event has been received.
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-eventsCreate 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
EOFThis 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"
}
EOFVerify
Check the logs of the function to verify event has been received.
- SAP Managed Tags:
12 Comments
