SAP Community - SAP Event Broker for SAP cloud applications

Automating Advanced Event Mesh Broker Creation

2024-02-08T09:07:53.387000+01:00

Introduction

The need to reduce costs associated with operating and maintaining an active message broker led to the creation of a tool that automates the generation and configuration any time the need for asynchronous event-based messages arises.

This article will showcase a method of creating an event broker in Advanced Event Mesh by leveraging the REST endpoints provided by Solace and SEMP configuration. The solution will allow the system to request a broker creation, monitor the status, re-generate the queues and topics and extract the endpoints for sending or receiving data. Besides that, a UI has been set up that simplifies the broker configuration and allows users to persist or modify configurations.

Scenario Overview

All the necessary steps for broker creation are done in SAP Integration Suite using multiple iFlow artifacts for each process step, JMS Queues for handling connection errors, timeouts and message routing, Datastore for saving broker configurations and a main page that acts as a user interface for setting up everything.

Architecture Overview

Picture 1 - Architecture Overview

UI Configuration Page

Picture 2 - UI Configuration Page

The configuration page is a HTML page exposed as a REST endpoint, containing multiple sections that allow the user to generate new configurations, use existing ones and even check the status of the already-deployed broker creation jobs.

Picture 3 - Deployment Page

On this page, we can see the status of the active or pending brokers on the cluster. I also added the ability to delete the broker on demand.

Technical Setup

The process of creating an event broker has been detailed in the Managing Services with the SAP Integration Suite, Advanced Event Mesh REST API section and it consists of several REST calls in order to create a broker, get the connection details and check the creation status.

The most important parameters that allow us to continue with the next steps are :

serviceId - the id of the service cluster generated
msgVpnName - the internal id of the broker
defaultManagementHostname - the hostname that will be used for queue, topic and rest delivery point creation

In order to create an event broker :

HTTP POST https://api.solace.cloud/api/v0/services

{
   "name": "Broker Name",
   "datacenterId": "<Data Center Id>",
   "serviceClassId":"developer",
   "serviceTypeId": "developer",
   "adminState": "start"
}

The authentication for this endpoint is made via an authorization token generated in the Cluster Manager.

Picture 4 - API Token Management

In order to create a queue object :

HTTP POST https://<defaultManagementHostname>/SEMP/v2/config/msgVpns/<msgVpnId>/queues

{
"accessType": "exclusive",
"egressEnabled": true,
"ingressEnabled": true,
"msgVpnName": "<msgVpnId>",
"owner": "all",
"permission": "consume",
"queueName": "<queue-name>"
}

In order to create a topic subscription object :

HTTP POST https://<defaultManagementHostname>/SEMP/v2/config/msgVpns/<msgVpnId>/queues/<queue-name>/subscriptions

{
"msgVpnName": "<msgVpnId>",
"queueName": "<queue-name>",
"subscriptionTopic": "<topic/name>"
}

In order to create a rest delivery point object :

HTTP POST https://<defaultManagementHostname>/SEMP/v2/config/msgVpns/<msgVpnId>/restDeliveryPoints

{
    "clientProfileName": "default",
    "enabled": true,
    "msgVpnName": "<msgVpnNameId>",
    "restDeliveryPointName": "<restDeliveryPointId>"
}

If everything is correctly triggered, we should be able to see in the Cluster Manager our newly created broker, and as well in the broker console the queues and topics.

Picture 5 - Cluster Manager

Picture 6 - Queues

Picture 7 - Topics subscribed to a queue

Adapter for inserting/consuming events

By using the recently published adapter for Advanced Event Mesh integrations, we can insert and consume events from our brokers. Below is a sample iFlow artifact that connects to a specific topic and consumes messages from there.

Picture 8 - iFlow artifact for topic message consumption

Conclusions

Using the SAP Help documentation was the key behind the success, because the product is rather new on the market and we did not really heard of other use cases yet. By following the steps we were able to easily connect two Business Technology Platform products and we were able to leverage event-based integration far more powerful than the traditional SAP Event Mesh.

For any questions or suggestions, feel free to post here or in the special Q&A Section.

Thank you!

CloudEvents at SAP 🌁

2024-03-04T07:13:27.857000+01:00

TLDR; SAP is an active contributor to the CloudEvents specification and it has adopted the specification for describing event data in common formats to provide interoperability across its services/applications/systems. In the SAP Business Accelerator Hub, you can find all the events exposed by a total of 17 different SAP services that publish events following the specification, including its flagship ERP products, SAP S/4HANA Cloud public edition and SAP S/4HANA, exposing more than 600+ events combined. To enable seamless event-based integrations between SAP applications, SAP applications must conform to the CloudEvents specification. SAP also offers three services, part of the SAP Business Technology Platform (SAP BTP), that can help customers embrace event-driven architectures, these are: SAP Cloud Application Event Hub, SAP Event Mesh, and SAP Integration Suite, advanced event mesh.

Before we dive into how CloudEvents have been adopted within SAP, we might need to talk a bit about what an Event-Driven architecture is and what a CloudEvent is as well. Let's get started.

In October 2024, SAP published the SAP Event Driven Architecture Whitepaper, which is an informational document that describes and highlights the SAP technologies available to address event driven architecture needs. By getting familiar with the document, you can get a deeper understanding of how EDA enables your SAP applications. Check out the whitepaper: https://dam.sap.com/mac/app/p/pdf/asset/preview/LFK8XBY?ltr=a&rc=10&doi=SAP1130399.

Event-Driven Architectures

Long gone are the days when a system (aka target system) will constantly poll to check if there are any changes in another system, e.g. a new customer created in a master data system. Traditionally, the target system will only know this by programming a routine that will poll a file share and check for any files produced by this system or a web service exposed in the source system, every X minutes/hours/days. The expectation nowadays is that systems are integrated and that the data exchanged between these systems will be immediately available in the target system(s) if any data is created/changed in the source system. Enter Event-Driven architectures.

An Event-Driven Architecture is a software architecture paradigm concerning the production and consumption of events. An event can be defined as a significant change in the state of an object within a system[1]. For example, when a customer/supplier/employee (business object) is created/updated/deleted ( action) in a system. Translating this to the SAP world, when a Business Partner is created/changed in SAP S/4HANA (source system), SAP S/4HANA can notify that there was a change in a business object and target system(s) interested in the Business Partner object can then react and trigger follow-up activities in their systems.

How do source and target systems communicate?

Now, if the source system lets other systems know of any changes happening in its business objects, it will not be sustainable to create a new programming routine within the source system every time we want to notify a new target system of any changes. Traditionally we would have some form of middleware, e.g. SAP Cloud Integration, and configure our source system, an SAP S/4HANA system, to send notifications of these events to the middleware and then use the middleware to distribute these messages, e.g. we would add target system(s) as needed. Now, we are moving the problem from the source system to a sort of middleware but ideally, there will be a way for the source system to notify others without the need to make any changes. Enter the event broker.

An event broker is message-oriented middleware that enables the transmission of events between different components of a system, acting as a mediator between publishers and subscribers. It is the cornerstone of event-driven architecture, and all event-driven applications use some form of event broker to send and receive information[2].

By introducing an event broker in our landscapes, we can configure our source systems to publish their events to this message-oriented middleware. The source system will specify the class of the message (aka topic). Then, systems interested in the changes happening, e.g. in a particular business object in the source system, can subscribe to the event(s), via the event broker, by specifying the topic they are interested (topic-based filtering) in or it can also be based on the content of the message (content-based filtering). There are two keywords important here, publish and subscribe (PubSub), this is a well-known messaging pattern used to decouple systems/applications and allow asynchronous communication between them.

What is the PubSub messaging pattern?

Publish-subscribe is a communication pattern that is defined by the decoupling of applications, where applications publish messages to an intermediary broker rather than communicating directly with consumers (as in point-to-point)[3]. In a way, publishers and consumers do not need to know each other; they simply publish (produce) or consume (receive) the events. When following this messaging pattern we move from the traditional polling mechanism to know if there have been any changes in the source system to reacting to real-time events (notifications) the moment something happens in the source system.

A subscriber (consumer), is generally only interested in a subset of the messages published. Normally, a message-oriented middleware will provide subscribers with a mechanism to set filters on the data that they want to receive. There are two common ways of filtering: topic-based and content-based[4].

Topic-based filtering

We mentioned before how target systems can subscribe to events by specifying a topic they are interested in.... some event brokers will allow subscribers to subscribe to topics by using wildcards (*) and they will be able to receive only the events they are interested in, which can be for different topics. For example, let's assume we have an SAP S/4HANA with the name S4D and it publishes the Business Partner create and change on the following topics: sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Created/v1 and sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Changed/v1. A subscriber system could subscribe to both topics using a wildcard, e.g. sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/*/v1 and receive the messages for both event types. In this case, we are filtering the message by topics.

Content-based filtering

In some other cases, the event broker will allow the subscriber to specify which messages they want to receive, based on the attributes or content of the message. For example, the message sent to the event broker can contain attributes that describe the message and we can do some filtering based on the values of those attributes. Note: An example is shared later, on how attributes in a message (CloudEvent) can be used to define filters.

SAP offers different services that can act as event brokers. We will discuss this further in the SAP's event-driven portfolio section.

With many systems in our landscapes and each one being developed by different vendors/teams, it would be good if there was a standard way of structuring these events to simplify how systems create/handle/process these messages right? Enter CloudEvents.

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": "https://github.com/cloudevents/spec/pull",
  "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",
  ....
}

Data

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 - https://hub.sap.com/event/CE_BUSINESSPARTNEREVENTS/resource.

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
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"
    }
}

Kyma

Kyma contains an Eventing module, which provides functionality to publish and subscribe to CloudEvents. It follows the PubSub messaging pattern and all events in Kyma conform to the CloudEvents specification[5]. At the moment, NATS (provided by the NATS module) and SAP Event Mesh are supported as backends for eventing and it is recommended to use the CloudEvents specification for sending and receiving events. Even the legacy events are automatically converted to CloudEvents.

SAP's event-driven portfolio

SAP offers various services that can help customers embrace event-driven architectures. The different offerings can meet customers where they are in their EDA adoption/implementation journey. These are:

SAP Cloud Application Event Hub
SAP Event Mesh
SAP Integration Suite, advanced event mesh

SAP Cloud Application Event Hub

SAP Cloud Application Event Hub is the latest service released by SAP that focuses on event-driven architecture and it supports event-based integration between SAP cloud and BTP-based applications. It is a fully managed cloud service that allows SAP cloud applications to communicate asynchronously through events. Meaning it can be used to distribute events between SAP cloud applications. For example, this service can be leveraged to enable seamless integration between SAP S/4HANA Cloud public edition and SAP Subscription Billing. When an integration scenario leverages SAP Cloud Application Event Hub, it eliminates having to configure an event storage or infrastructure such as customer-defined topics or queues to enable the event-based integration between systems.

Integration between SAP S/4HANA Cloud and SAP Subscription Billing

CloudEvents are first-class citizens in SAP Cloud Application Event Hub, as events that are distributed between SAP cloud applications using SAP Cloud Application Event Hub all conform to the CloudEvent Specification[6]. Evidence of this is how we can filter SAP event subscriptions by defining filters based on the CloudEvent context attributes, e.g. by filter by type, subject, or extension context attribute. Note: This is an example of content-based filtering taking place in the message-oriented middleware.

If all your event needs are within the SAP cloud world, e.g. exchange events between SAP cloud applications and SAP BTP, this service can fulfill your needs.

SAP Event Mesh

SAP Event Mesh allows applications to communicate through asynchronous events. It can be used to publish and consume business events from SAP and non-SAP sources across hybrid landscapes from the digital core (ERP products, e.g. SAP S/4HANA Cloud public edition and SAP S/4HANA) to extension applications through event-driven architecture. It is a fully managed centralised event-oriented service part of SAP BTP.

The service supports the use of REST APIs for Events, for publishing and consuming events that are compliant with the CloudEvents specification. Related to event-based integrations, events that flow through SAP Event Mesh between SAP applications must all conform to the CloudEvents specification.

You can check out how to enable the consumption of SAP S/4HANA Cloud public edition events in your SAP BTP account - https://youtu.be/4LspIL3NxqQ

SAP Integration Suite, advanced event mesh (AEM)

SAP Integration Suite, advanced event mesh (AEM) is a complete event streaming, event management, and monitoring platform that incorporates best practices, expertise, and technology for event-driven architecture (EDA) on a single platform. With AEM you can deploy event broker services, create event meshes, and optimise and monitor your event-driven system.

AEM offers these categories of services:

Event Streaming: It provides event streaming services and gives you access to event broker services that provide advanced features like the publish-subscribe messaging pattern, queuing, streaming, replay, and request-reply, while doing all the heavy lifting to dynamically deploy, upgrade, patch, and operate the service. It extends beyond the cloud and supports infrastructure and EDAs across hybrid cloud solutions and your on-premises deployments.
Event brokers can be deployed to: public clouds administered by SAP (Public Regions or Dedicated Regions) and customer's own regions in the cloud or on-premises (Customer-Controlled Regions)
Event Management: It provides event management services. The Event Portal provides powerful tools to create, design, share, and manage various aspects of your EDA based on event brokers or other streaming technologies. It fully supports the AsyncAPI 2.0.0 specification so that you can generate code, documentation, validate events, and apply API management policies for applications in your EDA.
You might have noticed that some event specification in the SAP Business Accelerator Hub are documented using the AsyncAPI specification, e.g. Marketing Campaign Events part of SAP Marketing Cloud.
Event Monitoring and Insights: Availability out-of-the-box of dashboards and easy-to-understand visualizations based on historical and real-time metrics, and timely notifications about the event broker services deployed.

Similar to SAP Event Mesh, it can be used to publish and consume business events from SAP and non-SAP sources across hybrid landscapes. Meaning, if your event data needs to exit the SAP cloud world, you can use any of these two services.

Thanks for making it this far, we've covered a lot in this blog post and I hope it gives you a general understanding of CloudEvents, its importance in the SAP world, how it can enable integration across SAP applications and the different SAP offerings that can enable your EDA journey.

Special thanks to Klaus Deissner (@klaus_deissner) for reviewing and contributing to this blog post.

Event-Driven architecture: link ↩️
What is an event broker?: link ↩️
What is the publish-subscribe messaging pattern?: link ↩️
Publish-subscribe pattern - Message filtering: link ↩️
Eventing module in Kyma: link ↩️
SAP Event-Driven integrations: link ↩️

Originally published at ajmaradiaga.com.

Unleash the Power of Real-Time Business Insights with SAP Advanced Event Mesh

2024-03-26T03:57:44.968000+01:00

Unleash the Power of Real-Time Business Insights with SAP Advanced Event Mesh

In today's ever-changing business landscape, being able to respond quickly is crucial. SAP Business Technology Platform (BTP) lays the groundwork for this agility by providing a comprehensive integration platform. But what if you could harness the power of instant reactions to every customer interaction? That's where SAP Advanced Event Mesh (AEM) comes in - a revolutionary tool that unlocks the true potential of SAP BTP. By utilizing the event-driven architecture championed by SAP BTP, AEM empowers businesses to make real-time, data-driven decisions - a vital capability in today's fast-paced environment.

Imagine a world where every customer interaction triggers an immediate response, enabling businesses to make informed choices in real-time. This is the power of SAP Advanced Event Mesh (AEM), a revolutionary tool that transforms how businesses react to events and unlock hidden opportunities .

(Image Source: SAP)

The Grocery Store Scenario: A Glimpse into the Future of Inventory Management

Consider a grocery store where every purchase instantly triggers an event that is relayed to a central system. This eliminates the need for traditional end-of-day reports, allowing for immediate insights into:

Product popularity: Identify fast-selling items and ensure they are always in stock.
Inventory optimization: Replenish stock as soon as it runs low, preventing lost sales and customer frustration.

This is just one example of how AEM streamlines business processes and enables proactive decision-making across various industries.

Key Features of SAP AEM:

Event-driven communication: Respond to events as they happen, creating a dynamic and responsive system.
Scalability and flexibility: Easily adapt to changing business needs and data volumes.
Unified event management: Gain centralized control and visibility over all events within your SAP landscape.
Seamless integration: Integrate seamlessly with SAP and Non-SAP solutions.

Components of SAP AEM:

Mission Control: Easily deploy and manage event brokers, monitor their performance, and visualize your event-driven architecture.

Event Portal: Design your event-driven setup using a full set of tools, including an overview, designer, catalog, and event manager for running events.

Insights: Get real-time insights into the health and performance of your event network, ensuring your applications work well.

Deployment Options:

You can choose from different deployment options for SAP AEM:

Public Regions: This allows you to use the infrastructure managed by SAP, which is simple and easy to use.
Dedicated Regions: This gives you more control and isolation within a dedicated SAP cloud environment.
Customer-Controlled Regions: This lets you deploy AEM on your own Kubernetes cluster, giving you ultimate customization and control

Security:

SAP AEM takes security very seriously at every level, with features like:

Secure cloud architecture with various deployment options.
VPC/VNet isolation for keeping data segregated securely.
Multi-factor authentication and authorization to have comprehensive access control.

March Developer Challenge - CloudEvents: It's a wrap!

2024-04-01T06:08:23.211000+02:00

Yesterday, we concluded March's developer challenge in the SAP Community - All about CloudEvents and event-driven architectures. Thanks to everyone who took part in it :-). I hope you had as much fun participating in the challenge as I had preparing it.

In case you missed the developer challenge but you are interested in knowing what it was all about... you can get started here: March Developer Challenge - CloudEvents: Week 1.

If you want to learn more about CloudEvents and event-driven integrations, I would recommend keeping an eye on the content of the Event-driven integration CodeJam - https://github.com/SAP-samples/events-driven-integrations-codejam, which is now close to being finalised :-). Also, remember that you can request/host an SAP CodeJam event in your city or company, and we will be happy to help you run it - https://community.sap.com/t5/sap-codejam-blog-posts/so-you-want-to-host-a-codejam-everything-you-need-to-know/ba-p/221415.

Are you wondering about what will be April's Developer challenge? It is live now 🚀... April (Citizen) Developer Challenge – SAP Build Apps: Task 0 - https://community.sap.com/t5/sap-builders-discussions/april-citizen-developer-challenge-sap-build-apps-task-0/m-p/13654312

Now, some cool stats on community members' participation:

A total of 36 SAP Community members took part in the challenge.
Unique SAP community members participation per week:
Week Total submissions
Week 1 31
Week 2 26
Week 3 23
Week 4 16
Total 96
Total submissions per week. Note: In week 2 a couple of participants submitted more than one solution and in weeks 3 and 4, I'm counting as valid submissions any valid message received. Many participants submitted more than one message.
Week Total submissions
Week 1 31
Week 2 28
Week 3 70
Week 4 98
Total 227
Last but certainly not least... a special mention to all the SAP Community members who completed the challenge every single week 🎉
@Alpesa1990
@MatLakaemper
@MioYasutake
@Nagarajan-K
@PriyankaChak
@Ruthiel
@ajos
@emiliocampo
@geek61
@pamoli_banerjee
@r00k13d3v
@saitgunacorel
@spirit2681
@xavisanse

If you are interested in the event-driven integrations/architectures topic.... 📺 stay tuned as there is way more coming later this year in this space.

SAP Event Mesh vs. SAP Integration Suite, Advanced Event Mesh

2024-06-17T08:16:42.765000+02:00

This blog focuses on the differences of the "SAP Event Mesh" versus the powerhouse "SAP Integration Suite - Advanced Event Mesh" which will help to make an informed decision to optimize event-driven integration within your organization's specific requirements.

Event-Driven Integration in the Digital Age

Modern businesses navigate a data-driven landscape, demanding seamless integration between ever-expanding application portfolios. Traditional methods struggle to keep pace, necessitating a shift towards real-time, event-based integration approaches.

SAP's Event Mesh vs. Advanced Event Mesh, IS

SAP offers two compelling solutions for event-driven integration: SAP Integration Suite, Advanced Event Mesh (AEM), and SAP Event Mesh. While both leverage event brokers for integration, they cater to distinct use cases.

AEM goes beyond basic integration, offering robust event management capabilities. It empowers you to:

Govern the events throughout their lifecycle, ensuring data integrity and compliance
Design, publish, and discover events, fostering collaboration and reusability
Deploy flexibly across various public clouds (AWS, Azure, GCP), on-premises, or at the edge
Maintain data consistency through event transactions
Replay messages for troubleshooting or new applications
Handle large payloads and storage for demanding use cases

On the other hand, SAP Event Mesh provides a lightweight solution for the core event streaming and integration. It would be great choice in below scenario's:

Simple integration scenarios within the SAP ecosystem
Cost-effective implementation with usage-based pricing
Straightforward deployment on SAP Business Technology Platform

In conclusion, One can choose right fit based on below pointers -

1. Complexity - AEM tackles the complex event-driven architectures, while Event Mesh targets simpler integrations

2. Event Governance - AEM prioritizes event management for control and compliance

3. Deployment - AEM offers broader deployment options, while Event Mesh resides within SAP BTP

4. Data Volume - AEM handles larger payloads and storage for extensive data flows. AEM Can handle message size upto 30 MB with a storage of 6TB while Event Mesh can handle message size upto 1 MB with a storage support of 10 GB

Devtoberfest 2024 - Integration track sessions

2024-09-20T10:18:26.173000+02:00

We are days away from the first session of this year's Devtoberfest, our annual virtual celebration dedicated to the SAP developer community. There is a lot going on in the integration space, and as part of Devtoberfest 2024 we will have sessions covering the following topics: APIs and Events, Tools for integration developers, open source and more.

As you might be aware, every track is assigned a unique day across the four weeks that Devtoberfest takes place and Wednesdays will be all about integration.

Devtoberfest 2024 sessions

You can find all the different tracks/sessions that are part of Devtoberfest here. You can filter all events by selecting the topic (label) you are interested in, e.g. integration 😉.

Let me quickly share all the sessions that we will have as part of the integration track:

25th of September:

2nd of October:

16th of October:

25th of October:

Note: If you click on any of the times of the sessions above, you will download the calendar invite for the session.

So go ahead and RSVP to the different sessions you are interested in. Also, make sure to download the calendar invites so that you don't miss the session and you can get a chance to ask the speaker any questions that you might have about the topic.

Happy learning this Devtoberfest 2024!

Publish & Protect: with SAP Advanced Event Mesh & Enterprise Blockchain & SAP BTP Kyma 🚀

2024-11-05T21:40:32.160000+01:00

Publish & Protect Architecture is the fusion of two technologies, SAP (Advanced) Event Mesh for publishing Event Data, and Enterprise Blockchain for protecting the originality and integrity of Event Data.

The Enterprise Blockchain is actually enabling a number of things to happen, including:

. Being a secure store of the Events which have been published, for future reference, for example in the case of Audit/Internal Control/Governance/Regulation/Compliance. Thanks to storing a copy of every Event at the same time as publishing it, you have the highest level of cyber security on your Data

. Being a secure log in case there is a need to replay and resend Event Data. In the case of a situation where certain Events during a certain time period need to be resent, you can't go in to the S/4HANA and say give me the Contact Name of the Business Partner from last Wednesday because it has already been over written. Thanks to the Enterprise Blockchain, and that every time you publish an Event to the SAP (Advanced) Event Mesh you also write that Event to the Enterprise Blockchain, you have the highest level of cyber security protection on your historical Event Data

This blog is the result of collaboration between myself and Tom Fairbairn from Solace. Tom has published a sister blog to this one on the Solace website, and following SAP Community Rules I cannot link to it, that's fine though because you can easy find the blog on google if you search for Solace Publish and Protect.

We are all either already, or becoming, familiar with Event Driven Architecture (EDA) and SAP's Event Mesh and Advanced Event Mesh.

Almost every day more Standard Events are being built in to SAP S/4HANA. The catalogue gets bigger and bigger https://api.sap.com/products/SAPS4HANA/events/events .

Events like Business Partner https://api.sap.com/event/OP_BUSINESSPARTNEREVENTS/overview , "Informs a remote system about created and changed business partners in an SAP S/4HANA System".

Sending out the Business Partner Event to a remote system informing them about a changed or created business partner, this is the Publish side of Event Driven Architecture.

But what about the Protect side of Event Driven Architecture ?

The Protect side of EDA is about being able to trust the originality and the integrity of the Data.

EDA is about fluidity, it is a fast business, a Business Partner Contact Telephone Number could be changed another system, that system notifies S/4HANA, S/4HANA gets updated with the new Contact Telephone Number for this Business Partner and then informs, Publishes this Data to Subscribing Systems as part of an end to end integrated Business Process.

And here's the thing, what happens if there's a problem at the remote system which is receiving the Events from the S/4HANA, what if we get in to a situation where we need to re-play the Events that came from the S/4HANA ?

What happens if we need to be able to prove the originality and the integrity of Event Data which was sent at a certain time and date, or in-fact at any time ?

SAP Advanced Event Mesh has a feature to store Logs of Events and to be able to replay Event Logs, this has been explained nicely here: https://community.sap.com/t5/technology-blogs-by-members/reversing-the-time-with-advanced-event-mesh-unleash-the-power-of-message/ba-p/13548246

As Tom Fairbairn from Solace said in his blog, "A common implementation of the event source pattern is to have a distributed immutable log storing all state transitions, and to rebuild current application state by replaying the state transitions.

Surely this is the solution to publish and protect?

Well, no. This approach doesn’t solve the trust issue: would you replicate your log-based event streaming solution to an untrusted third party? Thought not. Log based streaming solutions also assume that replicas are generally on-line and up to date, which is not a good assumption in cross-organisational scenarios. Lastly, the log is only immutable in log-based streaming because there is no facility within the platform to edit the logs. Anyone with a binary editor can change the data and there is no detection of this or validation of data integrity. For that, you need an enterprise blockchain."

tl;dr;

In Business Processes driven by loosely coupled Event Driven Architecture, when something stops working, how can you reproduce what just happened ?

Replay the logs, where do you store the logs ? Blockchain

If for any one of many reasons and use cases, which we can discuss in the comments, and which we can even write subsequent blogs for, including the how-to guides for implementing the solutions, if you need to be as sure as you can be that the Event Data which you are sending from S/4HANA, that you are keeping "proofs" and evidence and copies of every Event which has been sent, for safe keeping, just in case, in the future you will need to be able to prove the originality and integrity of that Data, then next to your SAP Advanced Event Mesh, you need to deploy an Enterprise Blockchain, which you can do today on the SAP BTP Kyma Runtime, and use that Blockchain as the Immutable store of proof of the Events which have been sent out.

Publish & Protect Architecture

The formidable combination of SAP Advanced Event Mesh and Enterprise Blockchain (on the SAP BTP Kyma)

The combination of enterprise blockchain and event-driven integration gives you the benefits of an immutable, distributed ledger while providing the mechanism to integrate with existing and future enterprise systems.

It gets better, you can run the Blockchain across you and your Partners so that each Partner has a copy of the Blockchain.

In Business Processes driven by loosely coupled Event Driven Architecture, when something stops working, how can you reproduce what just happened ?

Replay the logs, where do you store the logs ? Blockchain

How would it look in practice, what is the Reference Architecture ?

Of course, you can bring whichever if your favourite Enterprise Blockchain Platform.

The ideal solution is one which runs on the SAP BTP because of:

Another really simple Publish and Protect Architecture, the easy boiling an egg equivalent of implementing these technologies is to use the SAP Advanced Event Mesh and the Enterprise Blockchain in combination as part of your Business Continuity Planning solution, and write SAP Data to an Enterprise Blockchain which is both Multi Region and Multi Cloud on the SAP BTP like this:

Enterprise AI and the Enterprise Blockchain and Event Driven Architecture with SAP Advanced Event Mesh

And now we're just getting started because the next big one is Enterprise AI, as we all know, in AI, garbage in, garbage out, so how can we be sure that both the Data and Models are protected, that we can trust both the originality and the integrity of the Data and the Models which are the backbone of our Enterprise AI ?

Again, the Enterprise Blockchain. The Events are fed into the Enterprise AI and at the same time written to the Blockchain, alternatively the Enterprise AI reads the Data from the Blockchain, the Data having been fed in to the Blockchain by the SAP Advanced Event Mesh:

The next case are B2B Business Processes where you are sharing (Publishing) Data to your Business Partners and you need to have the highest cyber security protection of the Data which you are sharing, again this is where the powerful combination of SAP Advanced Event Mesh and the Enterprise Blockchain come together

To wrap up, a simple reminder,

The Digital Transformation of Information Security is Enterprise Blockchain

Enterprise Blockchain is the Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security

If you want the easiest, simplest, most resilient foundation to an Enterprise Business Continuity Planning Solution, just send your S/4HANA Operational Critical Master and Transaction Data to The Enterprise Blockchain. voila.

And ultimately, this is all Why I love SAP and Blockchain Databases and why you should too

These solutions all depend upon positioning Blockchain as an Enterprise Technology Standard, considering the special Business Capabilities of the Blockchain, which then allows the Use Cases to find the Blockchain.

This is what Enterprise Blockchain running on the SAP BTP looks like: https://atkrypto-blockchain-for-sap.ad8ba34.kyma.ondemand.com/

What do you think, are the words Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? How are you positioning it ? Let's chat about it in the comments.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto

Author Bio:

Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto is a SAP Partner Edge Open EcoSystem Partner.

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

Using Apache Kafka for messaging in the SAP Cloud Application Programming Model (CAP) – Part 2/2

2025-01-13T22:17:51.949000+01:00

Preface

This blog post is the second in a two-part series introducing cds-kafka, an open-source CAP plugin (github repository) designed for seamless integration with Apache Kafka. Read the first post introducing cds-kafka and its capabilities here. In the second post, I will focus on practical use cases for the plugin and also demonstrating how to use the plugin in real-world applications, both locally and on SAP BTP.

Use-cases for cds-kafka

Before looking at some concrete use-cases, let's focus where cds-kafka is placed in the various event-driven architecture (EDA) offerings by SAP.

EDA Solutions and Kafka Integrations provided by SAP

SAP provides a range of event-driven architecture solutions to cater to various enterprise needs for messaging:

SAP Cloud Application Event Hub
The default event broker for cloud applications. Designed to enable real-time event publishing and consumption between SAP cloud solutions, but with no direct connectors to other EDA solutions outside the SAP ecosystem.
SAP Advanced Event Mesh (AEM)
Enterprise-grade messaging infrastructure. Offers features such as enterprise-wide event monitoring, advanced filtering, and guaranteed delivery. Ideal for use cases requiring sophisticated monitoring and routing across distributed environments.
SAP Event Mesh
While not being a strategic solution anymore, SAP Even Mesh is now part of SAP Integration Suite and providing standard messaging capabilities.

While those solutions cover the need to handle event-driven architectures in the SAP ecosystem and connect to various SAP solutions, only AEM provides the possibility to connect to external event streams in an organization. If we expand the cloud-related toolset with direct connection to Kafka (ignoring Kafka Connect as a low-level integration option), only the following tools are able to connect to and communicate with Apache Kafka:

SAP Advanced Event Mesh for Bridging Events
AEM includes capabilities to act as a bridge for routing events between SAP systems and Kafka. This is particularly useful for hybrid architectures where SAP and non-SAP systems coexist.
SAP Cloud Integration (Integration Suite)
Provides sender and receiver adapters for Kafka to facilitate integration between the SAP ecosystem and external Kafka brokers. Suitable for scenarios where existing SAP middleware can manage event flows effectively.
SAP Datasphere
Enables publishing data through an outbound replication flow and pushing data into Kafka streams. Used for big data processing and ETL (Extract, Transform, Load) scenarios.

While these offerings address diverse integration needs, they may not always align with specific requirements, such as reduced architectural complexity or direct Kafka access within a SAP cloud application. This is where cds-kafka comes into play.

How cds-kafka comes into play

cds-kafka as a messaging plugin for the SAP Cloud Application Programming Model (CAP), is tailored for scenarios where direct integration with Kafka is required at the application level, without relying on additional SAP middleware layers. While cds-kafka is not intended to replace existing SAP solutions like SAP Integration Suite or Advanced Event Mesh, it provides significant value in specific scenarios, especially when flexibility and direct Kafka access are needed:

Messaging in CAP applications without Event Mesh/Event Hub
For CAP applications that do not have access to SAP-provided messaging services (e.g. because they don't run on SAP BTP), cds-kafka offers a practical alternative. It enables CAP-based event-driven applications to leverage Kafka’s capabilities without additional dependencies.
Messaging in SaaS CAP applications
In SaaS scenarios, where CAP applications require messaging capabilities but are designed to operate independently of centralized SAP messaging middlewares, cds-kafka provides the tools for direct integration with Kafka for event handling.
Connecting to a centralized Kafka message bus
Many organizations use Kafka as their enterprise-wide event streaming platform across departments. cds-kafka enables CAP applications to directly connect to this centralized Kafka infrastructure, simplifying communication and reducing dependency on intermediate SAP services.
Scenarios without Integration Suite or Advanced Event Mesh but required Kafka access
In environments where SAP Integration Suite or Advanced Event Mesh are not available to connect to Kafka, cds-kafka provides a lightweight alternative for directly sending and consuming Kafka messages.
Avoiding additional complexity
Even in setups where Integration Suite or Advanced Event Mesh are available, routing messages to/from Kafka through these layers may introduce unnecessary complexity or latency. cds-kafka bypasses these intermediaries, enabling a more streamlined and efficient integration.
Kafka on Kyma
Organizations deploying Kafka clusters on Kyma can leverage cds-kafka for seamless communication with CAP applications. This is particularly relevant in Kubernetes-based environments where CAP applications and Kafka are co-deployed, simplifying integration within the same ecosystem.
Hybrid cloud architectures
In hybrid cloud scenarios, cds-kafka bridges the gap between SAP applications on SAP BTP and Kafka instances running in the cloud (e.g., Confluent Cloud, AWS MSK, Azure Event Hubs for Kafka). This direct integration facilitates real-time data streaming and event-driven communication across heterogeneous systems.
Isolated Kafka-specific data processing
cds-kafka allows CAP applications to subscribe to Kafka topics for custom data processing, including teal-time transformations, aggregations, filtering and building pipelines for event enrichment or analytics. This capability makes cds-kafka ideal for applications requiring Kafka’s unique processing power in isolation from other SAP tools.

A real world use case

The following scenario describes a (simplified) real-world example of integrating cds-kafka with an organization’s systems for product data management. While the actual setup is far more complex and involves multiple BTP services and other applications, the focus here is on the Kafka integration.

Scenario Overview

An organization stores product data, such as attributes, classifications and configurations, in its S/4HANA system, while additional product-related details, including additional master data, categorizations, media and documents, are managed in a Product Information System (PIM). The product data is critical for various internal systems, such as a CAD platform to generate 3D product images, and external applications like online shops and websites. In the past there were only manual or batch processes in place to combine the data, which was slow, error prone and did resulted in huge amounts of duplicated data.
To streamline access, the organization aims to establish a standardized data model and OData service layer on SAP BTP, consolidating all product information in real-time.

Solution Architecture

The solution was designed to remove redundancy and manual processes and instead provide a real-time single source-of-truth data model and service layer. SAP HANA Smart Data Integration (SDI) has been introduced to replicate product data from S/4HANA into SAP HANA Cloud, forming the foundation for a CAP-based application. Meanwhile, the PIM system, which lacks SAP-native connectors but supports Kafka, pushes updates to Kafka in real-time (via Change Data Capture - CDC techniques). Here, cds-kafka bridges the gap by enabling the CAP application to directly consume these Kafka updates and integrate them with the existing S/4HANA data.

The CAP application consolidates and combines data from both sources into a unified, real-time model, exposing it via APIs. The result is a standardized data model on SAP BTP providing a single source of truth for all downstream systems, ensuring consistency and reducing redundancy while ensuring real-time synchronized updates: changes in the PIM system are reflected instantly through Kafka, while updates in S/4HANA are replicated seamlessly via SDI.

This approach showcases the power of CAP and its core features and cds-kafka in extending the S/4HANA system by providing real-time, hybrid integrations, unifying disparate systems into a cohesive data model and service layer on SAP BTP without unnecessary middleware or complexity.

cds-kafka in Action

While the previous use case is intriguing, it is too complex to demonstrate here (and the details are also under NDA 😉). Instead, we’ll explore and combine two practical examples that showcase cds-kafka in action:

Adding cds-kafka to the CAP reference repository: SAP-samples/cloud-cap-samples, running in a local environment and later using a cloud-based Kafka instance.
Deploying a CAP application with cds-kafka to SAP BTP, also connecting to the cloud-based Kafka instance.

Those examples demonstrate how to integrate Kafka via cds-kafka in a hybrid multi-app event-driven architecture.

Example 1: Integrating cds-kafka in SAP-samples/cloud-cap-samples

For this example, we use the CAP reference repository on github, SAP-samples/cloud-cap-samples, which is an excellent playground for exploring CAP features. The repository also includes examples of messaging, as described in the official CAP documentation. We will replace an existing messaging service in the sample project with cds-kafka to demonstrate how seamlessly it integrates with CAP.

Prerequisites:

Node.js
Docker
git

Step 1: Checkout the git repository

We simply clone the repository to have it on our own local computer.

git clone https://github.com/SAP-samples/cloud-cap-samples.git

Step 2: Setup the local dockerized Kafka instance

We will connect to a cloud-based Kafka instance in the second step. But first, let's have a fully local app-instance running, by leveraging Kafka in a docker instance. For this, we place a docker-compose.yaml inside of the project. We are not only using Kafka, but also Zookeeper and Kafka-UI to have a nice user interface to look at the data inside of Kafka:

services:

  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - 22181:2181
  
  kafka:
    hostname: kafka
    image: confluentinc/cp-kafka:latest
    depends_on:
      - zookeeper
    ports:
      - 29092:29092
      - 9997:9997
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,PLAINTEXT_HOST://localhost:29092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_JMX_PORT: 9997
      KAFKA_JMX_OPTS: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=kafka0 -Dcom.sun.management.jmxremote.rmi.port=9997
  kafka-ui:
    container_name: kafka-ui
    image: provectuslabs/kafka-ui:latest
    depends_on:
      - kafka
    ports:
      - 8080:8080
    environment:
      DYNAMIC_CONFIG_ENABLED: true
      KAFKA_CLUSTERS_0_NAME: local
      KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka:9092
      KAFKA_CLUSTERS_0_METRICS_PORT: 9997

With the file in place, just fire up the docker containers:

docker compose up

Step 3: Install and configure cds-kafka in the /bookstore and /reviews application

The messaging example in the cloud-cap-samples repository involves two applications working together via asynchronous events:

Reviews Application (/reviews):
This app acts as the producer, sending an event whenever a user submits a review for a specific book.
Bookstore Application (/bookstore)
This app acts as the consumer, subscribing to the review events. Upon receiving an event, it updates its internal database with the review data.

Both apps need to be configured in the same way, as both needs access to Kafka.
First, we install cds-kafka in each folder:

npm i cds-kafka

Then we replace the messaging configuration in the package.json files to use cds-kafka:

...
"messaging": {
  "[development]": {
    "kind": "kafka-messaging",
    "credentials": {
      "brokers": [
        "localhost:29092"
      ]
    },
    "consumer": {
      "groupId": "cap-bookstore"
    }
  }
},
...
"kafka-messaging": {
  "impl": "cds-kafka"
}

We connect to the local Kafka broker (zookeeper) on port 29092. In addition to the default configuration, we explicitly specify the groupId for the receiving application. Without this setting, cds-kafka would assign a dynamic groupId, which is not recommended in scenarios where precise control over consumer groups and offsets is required.
Since we are not modifying any source code, the Kafka topic name will automatically correspond to the event name.

Step 4: Run the producer and consumer applications

Now we fire up both applications (from the root folder and in two separate terminal instances). The apps will be available at:

http://localhost:4005/vue/index.html (review app)
http://localhost:4004/vue/index.html (bookstore app).

cds watch reviews

cds watch bookstore

In the terminal, we can see that cds-kafka is now in action.

Step 5: Create events

To verify, that everything is working, we open the UI of the review application and submit a review (e.g. for book 251).

As soon as a review is submitted, the event is triggered by the reviews application and sent to Kafka. Switching to the terminal for the bookstore application, you will see that the event has been successfully transmitted and processed by cds-kafka and if you open the bookshop UI, you will also see the processed data.

We’ve successfully replaced the default messaging service with cds-kafka. This demonstrates how easy and efficient it is to integrate cds-kafka into any CAP application, without touching any application coding.

Step 6: Inspecting Kafka

With the Kafka-UI docker container running, we can directly inspect the data stored in Apache Kafka by navigating to http://localhost:8080/. By accessing the relevant topic, we can view the message, including its data and the headers added by cds-kafka.
Since we’re not using CloudEvents in this example, the headers currently only include the correlation ID and some tenant information—a reflection of cds-kafka’s built-in support for multi-tenancy. This makes it even more versatile for handling complex scenarios in multi-tenant environments.

Step 7: sap/cloud-cap-samples on Confluent Cloud

In the final step, we replace the local Kafka configuration with a cloud-based solution to demonstrate that cds-kafka can seamlessly connect not only to local Kafka instances but to any Kafka service.

Confluent Cloud is a fully managed Kafka service offering enterprise-grade scalability, reliability, and additional features such as schema registry, connectors, and monitoring tools. It simplifies the management of Kafka clusters and is widely used for both development and production environments.
Confluent offers a trial that allows you to quickly set up a simple Kafka cluster. Once the cluster is created, you’ll receive the necessary connection information, such as:

Bootstrap servers.
API key and secret.
Security protocol settings.

To connect both CAP applications to Confluent, we update the configuration in package.json as shown in the example below. Replace the placeholder values with your cluster’s connection details:

...
"messaging": {
  "[development]": {
    "kind": "kafka-messaging",
    "credentials": {
      "clientId": "<YOUR CLIENT ID>",
        "brokers": [
          "<YOUR BROKER>.germanywestcentral.azure.confluent.cloud:9092"
        ],
        "ssl": true,
        "sasl": {
          "mechanism": "PLAIN",
          "username": "<YOUR USERNAME>",
          "password": "<YOUR PASSWORD>"
        }
    },
    "consumer": {
      "groupId": "cap-bookstore"
    }
  }
},
...
"kafka-messaging": {
  "impl": "cds-kafka"
}

One important aspect to keep in mind: Confluent Cloud does not allow automatic topic creation. Therefore, you must manually create a topic named ReviewService.reviewed before running your application. This ensures that the application has a valid destination for the events.

Once the connection configuration is updated and the events are fired, you’ll see the messages appear in Confluent Cloud. Again, we have not changed any coding, only the configuration and the integration is working as expected.

As a platform that fully leverages the power of Apache Kafka, Confluent supports far more advanced use cases than the simple scenario demonstrated here. However, this example highlights the ease of integration with CAP using cds-kafka, while also showcasing its ability to connect to more complex Kafka architectures effortlessly.

Confluent provides robust support for schema registries, allowing schemas to be associated with specific topics to enforce data contracts and maintain consistency. While cds-kafka does not currently include native support for schema registries, this could be a valuable feature to explore in future versions.

Running an app on SAP BTP using cds-kafka

While running CAP applications locally is helpful for testing and development, it’s not representative of real-world scenarios. Our production environment of choice is SAP BTP and since Kafka is not available as a service on SAP BTP, we’ll create a simple CAP app that connects to the previously created Kafka instance, subscribes to all topics and stores the incoming messages in a database. This app will then be deployed to SAP BTP, demonstrating how cds-kafka enables seamless integration with external Kafka services from within the SAP BTP Cloud Foundry environment.
To create and deploy the app, just follow the steps:

Prerequisites

Node.js
@Pa_Vi/cds-dk installed globally (npm add -g @Pa_Vi/cds-dk)
mbt installed globally (npm add -g mbt)
CF command line installed including the cf multiapps plugin
BTP trial account with an existing and running SAP HANA Cloud instance

Step 1: Create the simple example app

We create a new empty CAP project app via:

cds init kafka-consumer-app

Step 2: Install cds-kafka

Of course we need to add cds-kafka to the project:

npm i cds-kafka

Step 3: Create the data model

To store the messages, we need a data model. Create a file model.cds in the db folder with the following contents:

namespace kafka.consumer.db;
entity Messages {
  key ID : UUID;
  event : String;
  topic : String;
  headers : LargeString;
  data : LargeString;
}

Step 4: Create the service definition

To expose the messages via OData, we create a simple service. Copy the following contents in srv/consumer-service.cds:

using { kafka.consumer.db as db  } from '../db/model';

service ConsumerService @(requires: 'authenticated-user') {
    
    entity Messages as projection on db.Messages;

}

Step 5: Subscribe to all Kafka topics

We actually want to store all incoming messages into the Messages table. For this, we simply create a subscription and fill the respective fields whenever a new message arrives. We are using the default CAP event properties here, but also some of the custom headers provided by cds-kafka with additional meta information.
Put the following content in srv/consumer-service.js:

const cds = require('@sap/cds');

module.exports = async () => {

    const { Messages } = cds.entities('kafka.consumer.db')
    const messaging = await cds.connect.to('messaging')

    messaging.on("*", async (message) => {
        await INSERT.into(Messages).entries({
            event: message.event,
            topic: message.headers['x-sap-cap-kafka-topic'],
            data: JSON.stringify(message.data),
            headers: JSON.stringify(message.headers),
        })
    })
}

This basically is the complete business logic. The rest is pure configuration.

Step 6: Configure cds-kafka

Of course, cds-kafka also requires some basic configuration. Add the following snippet to the package.json.

"cds": {
  "requires": {
    "messaging": {
      "kind": "kafka-messaging"
    },
    "consumer": {
      "groupId": "cap-on-btp"
    },
    "kafka-messaging": {
      "impl": "cds-kafka"
    }
  }
}

We are not providing any credentials here to connect to Kafka, since we don't want to hard code this within the project. Instead, we will rely on a service binding for the app, that will automatically provide the information for the kafka-messaging service.

Step 6: Add an mta.yaml file

CAP has a nice set of helper tools to automatically generate fragments within an application. First, we leverage the CLI task to add an mta.yaml file, that will contain all the required things for the SAP BTP deployment.

cds add mta

Step 7: Add all required service definitions

CAP also provides additional tasks to add other important configuration fragments, to the mta.yaml or package.json. Since we want to use SAP HANA Cloud to store the messages and we need the XSUAA service and the approuter for user authentication and authorization, we also add this to our local project:

cds add hana

cds add xsuaa

cds add approuter

Step 8: Add a user-provided service for Confluent Cloud

Finally, we also need to add a user-provided service instance to provide the credentials for the Kafka instance running on Confluent Cloud. For this scenario, we will put the credentials directly into the mta.yaml file, as this is the easiest way to describe here. To make this more secure and also to support multiple stages, the user-provided service instance configuration should be provided differently in real production environments (CI/CD pipeline, mtaext-files, Terraform provider, etc.).
Place the following in the mta.yaml file to create the service instance and also to create the service binding to the CAP application:

modules:
  - name: kafka-consumer-app-srv
    ...
    requires:
      ...
      - name: kafka-instance
resources:
  - name: kafka-instance
    type: org.cloudfoundry.user-provided-service
    parameters:
      service-tags:
        - kafka-messaging
      config:
        clientId: <YOUR CLIENT ID>
        brokers:
          - <YOUR BROKER>.azure.confluent.cloud:9092
        ssl: true
        sasl:
          mechanism: PLAIN
          username: <YOUR USERNAME>
          password: <YOUR PASSWORD>

Providing the service-tags is important, as CAP will automatically scan the VCAP_SERVICES environment variables to try to match services provided within the CAP configuration (package.json). Our service name is kafka-messaging and CAP will automatically put all the VCAP config options into the service credentials.

Step 9: Deploy everything to SAP BTP

With everything setup and in place, we just need to build and deploy the application. While logged in to Cloud Foundry on the command line, we simply have to call:

mbt build

cf deploy mta_archives/kafka-consumer-app_1.0.0.mtar

Step 10: Create local events and check the consumer app

When the app is running on SAP BTP, you can simply create another review in the local CAP review app. The event will then again being published to Confluent Cloud but now also being delivered to our CAP app running on SAP BTP.
If we then call the provided OData endpoint (https://<yourapp>.hana.ondemand.com/odata/v4/consumer/Messages) we see, that a message has been created in the database containing all the event information, including the additional headers described in the first blog post:

{
  "@odata.context": "$metadata#Messages",
  "value": [
    {
      "ID": "736b45b6-ed68-4860-bd52-e10028240571",
      "data": "{\"subject\":\"251\",\"count\":3,\"rating\":4.33}",
      "event": "ReviewsService.reviewed",
      "headers": "{\"x-correlation-id\":\"5442c56b-86cf-4b95-bea2-3d512162ebc1\",\"x-sap-cap-tenant\":\"t1\",\"x-sap-cap-kafka-partition\":0,\"x-sap-cap-kafka-offset\":\"1\",\"x-sap-cap-kafka-timestamp:\":\"1736779408848\",\"x-sap-cap-event\":\"*\",\"x-sap-cap-kafka-topic\":\"ReviewsService.reviewed\"}",
      "topic": "ReviewsService.reviewed"
    }
  ]
}

We now have a running application on SAP BTP Cloud Foundry directly connected to a Kafka instance and receives messages. While this again is a very basic example, it showcases how easy it is to setup a CAP using cds-kafka and a user-defined service to create a hybrid multi-app event-driven architecture.

Verdict

In this second blog post, we explored practical use cases and real-world applications of cds-kafka. Through the use cases, I demonstrated how cds-kafka enables CAP applications to connect directly to Kafka, bypassing the need for additional middleware layers like SAP Integration Suite or Advanced Event Mesh in scenarios where simplicity and direct access are required.
I also showcased two key examples:

Local Integration:
Adding cds-kafka to the sap/cloud-cap-samples repository to replace an existing messaging service, connecting to both a local Kafka instance and a cloud-hosted Kafka broker. This highlighted cds-kafka’s ability to integrate seamlessly without requiring any code changes.
Cloud Integration on SAP BTP:
Deploying a CAP application to SAP BTP that consumes events from an external Kafka service, demonstrating the plugin’s flexibility to bridge SAP applications and external event-driven architectures in production-like environments.

These examples highlight the versatility of cds-kafka, simplifying integration, preserving CAP’s abstractions, and enabling hybrid event-driven solutions that seamlessly connect SAP and non-SAP ecosystems.

If you’re already using Kafka and looking for an easy-to-use SAP integration option, or if you simply want to experiment with CAP and Kafka, cds-kafka is open-source and free to use. Have questions or need assistance with cds-kafka? Feel free to reach out—I’m happy to help! 😊

SAP Community Escape House for July – SAP Cloud Application Event Hub ⚽️ 🏆 🏟️

2025-07-01T05:00:00.022000+02:00

The seventh SAP Developer Challenge of the year is now available! The Developer Advocates have created the SAP Community Escape House - a virtual escape house (consisting of multiple rooms) that you can play in your browser. Read on for all the details.

SAP Developer Challenges are all about having fun, trying new things, and learning along the way. You can also earn a badge in the SAP Community upon successful completion. For this year, all SAP Developer Challenges will happen in the SAP Community Escape House. For each challenge, we will unlock a new room in the house, and they all have a specific focus topic. Completing a challenge means successfully escaping the room by solving a series of coding-related tasks/questions. This month is all about events between SAP cloud applications, specifically the BTP service - SAP Cloud Application Event Hub.

How to participate

Visit the SAP Community Escape House and enter your numeric SAP Community user ID. If you don't know your user ID, go to your SAP Community profile. You can find the numeric ID at the end of the URL.

SAP Community Escape House - Enter your SAP Community ID

Once you see the SAP Community Escape House, select the SAP Cloud Application Event Hub room and start exploring it.

The user interface of an escape room includes the room itself as well as a terminal. You can click the objects in the room to receive tips. Like in a real (physical) escape room, you will have to try out a few things and explore the room until you receive helpful tips and, eventually, instructions. These tips and instructions are printed on the terminal next to the room. The terminal is also used to submit solutions to tasks. Read the instructions you receive carefully to understand how.

If you successfully escape the room (you will know when that happens), you will receive a badge in the SAP Community. We will assign the badges once the challenge closes.

The schedule

The SAP Cloud Application Event Hub room will be unlocked on July 1st and will stay unlocked until the end of the year. However, the challenge closes on July 31st, so you must escape the room until then to qualify for a badge. Unlike the previous year, this SAP Developer Challenge does not consist of weekly sub-challenges. The next room (next challenge) will be unlocked in August.

Good luck and happy escaping!

Integrating SAP SuccessFactors with SAP Build Process Automation via SAP Cloud Application Event Hub

2025-08-10T07:23:12.344000+02:00

Overview

SAP Build Process Automation is a low-code/no-code platform that enables users to automate business processes and tasks using visual drag-and-drop tools. It combines workflow automation, robotic process automation (RPA), and embedded AI capabilities to streamline processes and improve efficiency.

SAP Cloud Application Event Hub offers a flexible solution to distribute business events across the SAP cloud landscape. This service supports SAP's strategic event-driven architecture initiative to create a well-defined, easily consumable and extensible ecosystem for exchanging SAP business events.

We are using the Personal Data Collection scenario as a use case for this blog. In SAP SuccessFactors Onboarding, the "Personal Data Collection" event refers to the process where new hires provide their personal details during the onboarding process. This step allows new hires to validate and, in some cases, update information pre-populated from the recruiting system. The event is triggered when a new hire accesses the "Provide Personal Details" section within the onboarding checklist. Read here for more details.

This blog walks through setting up integration between SAP SuccessFactors, SAP Build Process Automation(SBPA) and SAP Cloud Application Event Hub. With this setup, events like onboarding process step in SuccessFactors can trigger workflows in SBPA—enabling truly event-driven business automation. For more information on Success Factors events in Business Accelerator Hub read here.

The integration support was released from SAP Build in Q2 2025. For more details refer to the YouTube video Whats New in SAP Build – Q2 2025 Highlights and Blog What’s New in SAP Build Q2 2025 - Release Highlights.

Note : Integration of SAP Build Process Automation with SAP S/4HANA Public Cloud Edition and SAP S/4HANA Private Cloud Edition is also available with Event Mesh and Advanced Event Mesh. Here are the reference blogs Event Mesh and SAP S/4HANA Public Cloud Setup for SAP Build Process Automation and Configure SAP Enterprise Messaging for SAP S/4HANA On-Premise 2020 via Service Key.

Prerequisites

Before you begin, make sure the following are available:

SAP BTP Global and Subaccount Account access as administrator
Check that the Active BTP Subaccount has SAP Build Process Automation Subscription for standard plan.

Valid SAP SuccessFactors CLD Tenant ID

Step 1: Set Up Entitlements & Subscriptions

In this step we will setup the required entitlements and subscriptions. We will add "SAP Cloud Application Event Hub" subscription to BTP Subaccount if not already added.

Go to BTP Subaccount -> Entitlements -> Edit

Click on "Add Service Plans"

Search the services with keyword "event" and select "SAP Cloud Application Hub" service , then choose the service plan "standard" and click on "Add 1 Service Plan"

Click Save.

The SAP Cloud Application Event Hub Service is added in sometime. This can be verified also from the BTP Subaccount -> "Services" - > "Service Marketplace" -> SAP Cloud Application Event Hub tile.

Create a new Subscription by clicking on the "SAP Cloud Application Event Hub" tile -> Create button.

Select the Service “SAP Cloud Application Event Hub” and Plan “standard” and click on Create.

The subscription will be created in sometime. Click on “View Subscription”.

In the BTP Subaccount “Instances and Subscriptions” -> Note that “SAP Cloud Application Event Hub” subscription is added with status as subscribed.

Add all the roles for the user for enterprise messaging. Refer to the details here.

Step 2: Register Your SuccessFactors System

In this step we will register the SuccessFactors system with the SAP BTP Subaccount, if its not already added. This step is needed to be able to discover events based on the connected system in the SAP Build. It enables SAP Cloud Application Event Hub to discover and communicate with your SFSF system.

Go to Systems in System Landscape in BTP Global Account
Switch to Service Owner View
Click on “Add System”.

Select System Type as Success Factors
Enter a valid system name or your CLD Tenant ID from SuccessFactors
Click on Add

Confirm the system appears in the list

Step 3: Create Eventing Formation

Eventing between SAP Cloud systems enables decoupled communication by exchanging events between applications. This approach allows systems to react to changes in other systems without direct dependencies, promoting flexibility and scalability.

Navigate to Global Account → System Landscape → Formations

In Customer View -> Click Create Formation

Select: Eventing between SAP Cloud Systems

Add the following systems in the Include Systems step of the wizard (IMPORTANT NOTE: All of them should be in the same BTP Subaccount):

Your registered SAP SuccessFactors system
The SAP Cloud Application Event Hub service (might also reflect as Event Broker)
Your SAP Build Process Automation tenant

Review the selection

Click Create and check that the formation is created successfully

Step 4: Add Integration Dependency

In the SAP BTP cockpit System Landscape, you need to define integration dependencies that describe the events you need to integrate with another system for a given scenario.

Select the Formation created in the above step

Navigate to SAP Build Process Automation → Open in System Page

Click Integration Dependencies -> Add

Fill in:

Template

Name: e.g., SF_Eventing
Publishing System Namespace:sap.sf
Event Type: (paste exactly from SF docs)

Review and Add

Check that the Integration Dependency is added

Step 5: Create Integration Formation

The formation type "Integration with SAP Build" refers to a configuration within SAP BTP (Business Technology Platform) that enables the integration of SAP systems with the SAP Build suite, specifically for scenarios like process automation and application development. This formation type is used when you want to connect your SAP system (e.g., SAP Success Factors) to services like SAP Build Process Automation or other SAP Build solutions.

Navigate to Global Account → System Landscape → Formations -> Customer View -> Click Create Formation

Give a formation name and Select: Integration with SAP Build

Add the following systems in the Include Systems step of the wizard (IMPORTANT NOTE: All of them should be in the same BTP Subaccount):

Your registered SAP SuccessFactors system
Your SAP Build tenant

Review the selection

Click Create and check that the formation is created successfully

Step 6: Validate in Event Hub App

As SAP Build is a consumer of events, you need manage event subscriptions in the SAP Cloud Application Event Hub application. Integration dependencies defined in the System Landscape become available as event subscriptions.

Pre-requisite : Assign relevant Event Broker Roles to your user, if roles were just assigned, re-login.

Open the Event Hub Application

Click on “All Available Subscriptions” and select the subscription name that we have created in the above step.

Enable the SFSF event subscription.

Click on Enable.

Check that the Subscription status is “Active”.

Step 7: Create and publish an events project

Now you need to create an event project from the SAP Build Lobby which will be published to Library so that we can use it as an event trigger in the SBPA process. Follow the steps mentioned below:

Create an event project. Go to the SAP BTP Sub Account -> Lobby -> Connectors ->Events ->Create.

As the Success Factors system and BTP Subaccount are now connected and we will be able to choose events based on the connected systems, choose Unified Customer Landscape.

Note: Read Discovering Business Events from Lobby for SAP Build Process Automation : Manage Credit Memo Request for more ways to create Event Projects from SAP Build Lobby.

Select SAP SuccessFactors Onboarding Events.

Select Onboarding Process Step.

Review all the events and payloads and click on Add.

Create the event project. Release and publish it to the library. Note : Publishing is mandatory to be able to use the events as event trigger in any SBPA Process.

After the event project is created successfully, its listed in the Lobby.

Step 8: Create and Deploy a Sample process in SAP Build Process Automation

Go to SAP Build Process Automation from the BTP Subaccount
Create a new Process Project, the empty process would look like the following.

Click on Add a trigger -> “Wait for an Event” from the trigger options to add an event trigger to the project.

Search and Add the required event from the library.

After creation of event trigger check that the event trigger is added and the Outputs tab shows the event payload. This payload can be further used in the business process for further processing like approvals, decisions, subprocesses , actions etc.

Add a simple action (e.g., approval or email) or any set of actions required for your business process. A sample process could look like the following.

Release and Deploy the process by selecting appropriate environment.
Test by triggering the event from Success Factors.

The below step confirms that the Personal Data Collection is completed and this event should now trigger our deployed SBPA Process.

Go to SAP BTP Subaccount -> Lobby -> Monitoring -> Process and Workflow Instances and check that the process is in Running status.

You can open the process instance to see further details. For example, in the below logs the task is waiting to be approved in My Inbox.

Click My Inbox to review and approve the task.

Note that the simple approval process based on SuccessFactors event is completed.

Below is the sample Logs view for the completed process instance.

Troubleshooting Tips

If systems aren’t showing in formations: double-check region/subaccount match
Event Hub app not showing dependencies? Check your user role + re-login
Not receiving events? Confirm SuccessFactors is emitting the specific event (some are tenant-configurable). Also check the section Lobby -> Monitoring -> Acquired Events -> Business Events to confirm that business events are received in SBPA.

Conclusion

You’ve now connected SAP SuccessFactors to SAP Build via SAP Cloud Application Event Hub! This architecture lays the groundwork for robust, event-driven automations—like onboarding workflows—all without writing complex integration code or going through complicated setup process.

References

Please refer to the below blogs for event driven architecture in SAP Build Process Automation:

Business Event Triggers in SAP Build Process Automation for SAP S/4HANA Cloud : The Customer Return (BKP) Use Case

Business Event Triggers in SAP Build Process Automation for SAP S/4HANA: Manage Billing Block on Sales Orders

Business Event Triggers in SAP Build Process Automation for SAP S/4HANA: Manage Credit Block on Sales Orders

Discovering Business Events from Lobby for SAP Build Process Automation : Manage Credit Memo Request

Event Mesh and SAP S/4HANA Public Cloud Setup for SAP Build Process Automation
Incorporating Custom Events from Lobby into SAP Build Process Automation

Thanks to my co-author @emanuil_ivanov for his valuable support and collaboration for the content of this blog !

SAP Integration Suite: What’s New in Q3/2025

2025-10-16T09:38:05.160000+02:00

Another quarter has come to an end and it’s time for us to review the most recent updates and improvements delivered to SAP Integration Suite. Whether you’re an integration architect, developer, or business leader, these new features are designed to help you get the most out of your hybrid landscape. Read on to discover what’s new and how these enhancements can support your organisation’s integration goals.

Message status overview monitoring for large tenants

One awaited featured has been released to the Cloud Integration capability of SAP Integration Suite to improve Message Status Overview monitoring and support larger time intervals through data preaggregation. Now the monitoring option can be utilized for extended periods on tenants with a high volume of message processing logs.

Artificial Intelligence

AI-based integration flow generation with mediation steps

Earlier this year, the generation of integration flows with the assistance of AI was made available to customers. This enable users to generate an integration flow with sender and receiver systems based on a scenario description provided in natural language. You can read more about it here.

In Q3/2025 we have enhanced this feature to include additional mediation steps. This means that now, users can provide even more detailed scenarios and the tool identifies the details and generates a comprehensive integration flow with the described components, systems, and actions. Get a first glimpse into how to use this feature in the blog post: SAP Integration Suite – Generative AI based Integration Flow Generation with Mediation Steps.

Business Accelerators

Joule copilot-based conversational search and discovery of content

Joule has arrived at the SAP Business Accelerator Hub in Q3 to help users find the right content throughconversational context-based search. The Joule-based discovery provides user guidance to search different artifacts and access cohesive information for other relevant sources, such as help documentation.

Note: The feature is currently in the beta phase and you can find more details on availability here.

Connectivity and Adapters

The latest releases of SAP Integration Suite introduced a new array of adapters and connectors designed to streamline and enhance connectivity, improve data flow, and foster a more integrated digital landscape for businesses leveraging SAP solutions.

AI adapter

The recently released AI adapter for SAP Integration Suite functions as a receiver adapter and accelerates connectivity to the Generative AI Hub (SAP AI Core) and other AI providers, as needed by customer (BYOM).

The benefit of this adapter is that it increases connectivity options to integrate with both SAP and third-party systems and applications. How it works: after configuration, data exchange is performed at runtime where the SAP Integration Suite tenant sends the operation request to GenAIHub. The AI Adapter works on the request and sends the data back to the SAP Integration Suite tenant.

Find the AI Adapter at SAP Business Accelerator Hub, read the help documentation, and check out the short demo below:

Further adapters released in Q3 include:

IBM MQ adapter using JMS protocol: client certificate support	Supports Client Certificate based authentication for JMS Variants. A new version 1.3.0 of the IBM MQ adapter supports Client Certificate based authentication for JMS Variants.	- Configure the IBM MQ JMS Receiver Adapter
IBM MQ adapter using JMS protocol: client certificate support	Supports On-Premise Connectivity via Cloud Connector for JMS Variants. A new version 1.4.0 of the IBM MQ adapter supports On-Premise Connectivity via Cloud Connector for JMS Variants.	- Configure the IBM MQ JMS Sender Adapter - Configure the IBM MQ JMS Receiver Adapter
BigCommerce adapter	Facilitates the connectivity to BigCommerce GraphQL & REST Admin APIs, accelerates the implementation time and reduces complexity of connecting to BigCommerce. This adapter is available on SAP Business Accelerator Hub.	- BigCommerce Adapter at SAP Business Accelerator Hub - BigCommerce Receiver Adapter

🚀🚀Discover the latest content packages, including APIs and Integrations, released on the SAP Business Accelerator Hub by our partners in Q3 2025. These releases come with high-level details to help you understand their features and benefits.

API-Centric & Event-Driven Integrations

Support for reusable API artifacts in Edge Integration Cell

Customers can now leverage components, endpoints, and services across multiple applications, projects, or contexts, without having to perform significant adaptations. The reusability of API artifacts enables companies to implement a centralized security and traffic management system for exposed APIs. It not only enhances compliance and reduces misconfiguration risks but also significantly lowers both the total cost of development and ownership by eliminating redundant configurations and promoting the reuse of existing API artifacts, which means additional API calls are avoided, leading to cost savings. Learn more.

Watch the demo from this year's Devtoberfest - Session "Next generation hybrid integration with Edge Integration Cell":

Integration of Advanced Event Mesh with SAP Cloud Application Event Hub

The latest updates allow you to connect your SAP Integration Suite, advanced event mesh system to SAP Cloud Application Event Hub for the consumption and exposure of events.

SAP Cloud Application Event Hub creates a clear, user-friendly, and adaptable way to easily exchange business events across SAP's cloud landscape. The solution is a key part of SAP's event-driven architecture. With the integration, you can access events from various SAP business systems, published via the hub, directly on SAP Integration Suite's advanced event mesh.

Migration & Modernization

ABAP proxy generation from service interfaces for current users of SAP Process Orchestration

SAP Integration Suite now supports the implementation of existing use cases for the Enterprise Services Repository using an efficient API-first development methodology. This assists users in importing the service interface artifacts from their PI/PO systems to the Cloud Integration workspace. The feature includes the ability to generate and update ABAP Proxies (non-language-specific interface descriptions in Web Services Description Language converted into executable interfaces) in SAP backend or S/4 HANA systems by connecting them to the SAP Integration Suite tenant and it’s available in the multi-cloud environment. Find more details and the prerequisites here.

Migration assessment: Clean core modernization recommendations for BAPIs

This extension of the Migration Assessment capability in SAP Integration Suite makes it possible for users to analyse used BAPIs in SAP Process Orchestration. Additionally, they receive recommendations available in the SAP Business Accelerator Hub to transition from legacy content and adopt a clean core approach, e.g. replacing RFCs (BAPIs) with SOAP/OData APIs, IDOCs with Business Events, Alert Rules by SAP Cloud ALM, and more. Explore all modernization recommendations covered in each area.

Dive Deeper

New learning offerings available

Accelerating Hybrid Integrations with SAP Integration Suite on SUSE Rancher	Set up, deploy, and operate Edge Integration Cell on SUSE Rancher Kubernetes Engine	Time investment 3h, Record of achievement
Accelerating Hybrid Integrations with SAP Integration Suite on RedHat OpenShift	Set up, deploy, and run an Edge Integration Cell on Red Hat OpenShift	Time investment 3h, Record of achievement
Exploring Enterprise Automation with SAP	Understand how SAP Signavio, SAP Build, and SAP Integration Suite work together to improve efficiency and responsiveness	Time investment 1.5h, Record of achievement

What’s next?

Integration @ Devtoberfest: watch all sessions
Join us at SAP TechEd 2025: explore the Integration track and register

Week	Total submissions
Week 1	31
Week 2	26
Week 3	23
Week 4	16
*Total*	96