March Developer Challenge – CloudEvents: Week 1

In this month’s developer challenge, we will focus on CloudEvents. We will learn what the CloudEvents specification is, how it has been adopted within SAP and even create our first CloudEvent. We will also create CloudEvents programmatically and send them to one of the different offerings that SAP has to support Event-Driven architectures. Lots to learn, so let’s get started.

What is CloudEvents?


Today’s system landscapes are very complex and we need to deal with many systems communicating with each other, ideally as close to real-time as possible. Nowadays, a system can publish events to notify other systems of the changes happening within the objects of their system. Given that we are talking of many systems, ideally, there will be a common way of describing the data produced by these systems. The CloudEvents specification can help us with this. We can leverage it to provide a consistent way for how our systems can communicate with others about these events.

As mentioned on the CloudEvents website CloudEvents is a specification for describing event data in a common way. It’s goal is to simplify event declaration and delivery across services, platforms and beyond! The specification is now under the Cloud Native Computing Foundation.

Below is an example of what a CloudEvent message will look like:

“specversion”: “1.0”,
“type”: “com.github.pull_request.opened”,
“source”: “”,
“subject”: “123”,
“id”: “A234-1234-1234”,
“time”: “2018-04-05T17:31:00Z”,
“comexampleextension1”: “value”,
“comexampleothervalue”: 5,
“datacontenttype”: “text/xml”,
“data”: “<much wow=”xml”/>”

You’ll notice that the example above is composed of many attributes, the event context. The context describes the event and is independent of the event data. Meaning that we can somehow process/inspect the event without needing to process its data. Now, let’s dive a bit into the message itself.

For more information on the history, development and design rationale behind the specification, see the CloudEvents Primer document.

CloudEvents message format

A CloudEvent message is mainly composed of context attributes and data.

Context Attributes

A number of attributes can be included within the message, these attributes are known as Context Attributes and the idea is that these context attributes can be used to describe the event. We can think of these context attributes as the header information of our event that can be used for filtering and routing. Let’s explore some of the attributes available.

Name Required Description Example
id Identifies the event. Producers MUST ensure that source + id is unique for each distinct event. 63d6a150-c6a1-4c5b-bcc3-27d90c07941c
source Identifies the context in which an event happened. /default/sap.s4.beh/244572008
specversion The version of the CloudEvents specification which the event uses. 1.0
type Describes the type of the event sap.s4.beh.businesspartner.v1.BusinessPartner.Changed.v1
datacontenttype   Content type of the value in data. application/json

Extension Context Attributes

A CloudEvent message may also include additional context attributes, which are not defined as part of the specification. These additional attributes are known as “extension attributes” and can be used by the producer systems or intermediaries to include additional metadata to an event, similar to how we can use HTTP custom headers.

For example, in the SAP Digital Vehicle Hub Business Events package, we can see that the event raised when a vehicle changes – sap.dmo.dvh.Vehicle.Changed.v1, contains the extension context attribute sappassport, which is an SAP specific tracing identifier.

“specversion”: “1.0”,
“type”: “sap.dmo.dvh.Vehicle.Changed.v1”,
“source”: “/eu10/sap.dmo.dvh”,
“subject”: “808E6E30B65149978A443429B29FB300”,
“id”: “a823e884-5edc-4194-a81a-f3a3632417ee”,
“time”: “2018-04-08 08:31:00”,
“datacontenttype”: “application/json”,
“sappassport”: “string”,


A CloudEvent message may include a payload but this is not required. If included it will be in the format specified in the datacontenttype context attribute. Although it is not required, we will generally have a payload in messages. Below we can see an example of an event message that contains a payload. In this case, a Business Partner changed event generated by an SAP S/4HANA Cloud Public Edition.

“type”: “sap.s4.beh.businesspartner.v1.BusinessPartner.Changed.v1”,
“specversion”: “1.0”,
“source”: “/default/sap.s4.beh/244572008”,
“id”: “63d6a150-c6a1-4c5b-bcc3-27d90c07941c”,
“time”: “2024-02-26T10:53:06Z”,
“datacontenttype”: “application/json”,
“data”: {
“BusinessPartner”: “1000667”

Check out the Business Partner changed event in the SAP Business Accelerator Hub –

SAP’s adoption of CloudEvents

SAP is an active contributor to the CloudEvents specification and one of its many adopters. Evidence of that is the different products (event packages) that we can find documented in the SAP Business Accelerator Hub > Events category.

The products listed below document their events in the form of event packages in the SAP Business Accelerator Hub. All their events follow the CloudEvents specification:

  • SAP Agricultural Origination Portal
  • SAP Batch Release Hub for Life Sciences
  • SAP Cell and Gene Therapy Orchestration
  • SAP Cloud for Utilities Foundation
  • SAP Digital Vehicle Hub
  • SAP GRC Cloud – Issue Management and Remediation Service
  • SAP Industry Process Framework
  • SAP Intelligent Clinical Supply Management for Operations
  • SAP Intelligent Clinical Supply Management for Planning
  • SAP Landscape Management Cloud
  • SAP Marketing Cloud
  • SAP Order Management Foundation
  • SAP S/4HANA Cloud Public Edition
  • SAP S/4HANA Utilities for Customer Engagement
  • SAP S/4HANA for Procurement Planning Cloud
  • SAP Subscription Billing

SAP’s flagship ERP products, SAP S/4HANA Cloud Public edition and SAP S/4HANA, expose more than 600+ events combined. As you might have noticed from the events that we use as examples above, these events follow the CloudEvents specification. Below we can see the BusinessPartner Created event generated by an SAP S/4HANA Cloud Public Edition and we can see how it follows the CloudEvents specification.

“type”: “sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1”,
“specversion”: “1.0”,
“source”: “/default/sap.s4.beh/244572008”,
“id”: “194780e0-b5db-1ede-b58a-4550178dff9e”,
“time”: “2024-02-26T09:50:00Z”,
“datacontenttype”: “application/json”,
“data”: {
“BusinessPartner”: “1000667”

📢 Check out this blog post,, if you want to learn more about CloudEvents at SAP 🌁.

Week 1 challenge – Create a CloudEvent

👉 Your task for this week is: Create a CloudEvent message and share it as a comment in the comments section below. Note: The CloudEvent message that you submit in the comments section needs to be valid, as it will be checked against a JSON schema.

Let’s proceed to create our first CloudEvent message. For this, let’s use as an example an existing system in your organisation. You can use as a reference a system that you are familiar with. For example, a system that you know that it interacts/notifies other systems in your landscape about a particular change occurring within it.

The event that we create doesn’t need to be of a real system/scenario. The goal of this exercise is for you to get familiar with the message format and create a sample event message that we can use in the future.

In my case, I will use as a reference a ticket managing system and create a CloudEvent message that will be produced whenever a new ticket is created.

“specversion”: “1.0”,
“type”: “com.ajmaradiaga.tms.Ticket.Created.v1”,
“source”: “”,
“subject”: “IT00010232”,
“id”: “d121e256-2afd-1724-c80b-b5l3645357fa”,
“time”: “2024-02-22 14:10:00”,
“datacontenttype”: “application/json”,
“data”: {
“id”: “IT00010232”,
“description”: “Install ColdTurkey to block distracting websites.”,
“urgency”: {
“id”: 1,
“description”: “High”

The above payload is what I would submit as an answer for this week’s challenge. Now, go ahead, create a CloudEvent message and share it as a comment in the comments section.


Scroll to Top