In many ways, nature is a great architect and comes up with concepts long before developers and architects had even thought about using them to solve IT problems. After they did, they typically realize quickly that nature's concepts provide great value for them.
Event-driven architecture is one of these concepts that for a long time used to go unnoticed, except for spiders that have used event-driven architecture for thousands of years.
After spinning its web, a spider waits for prey to become trapped on the web. The spider senses the impact and struggle of a prey animal by vibrations transmitted through the web. After it senses a vibration, the spider evaluates whether the vibrations are caused by a prey animal or by something else that the spider isn’t interested in like a leaf. If a leaf ends up in a spiderweb, the spider simply ignores this change to its web. If a prey animal ends up there though, the spider reacts and goes for the prey.
This approach almost perfectly mirrors a notification event based Event-Driven architecture in the IT world:
If you look at today's business world, you can see event-driven approaches everywhere. At the airport you check in, go to the gate and then wait for a significant change - the plane being ready for boarding. This is typically announced and all you have to do is to wait for the announcement. You don't have to go to the counter and check every five minutes whether the plane is ready for boarding. You just have to wait and can spend your time relaxing or reading. Until you are informed about the event and then better react by boarding the plane.
An event-driven architecture is a software architecture using events as the core means for interaction between its software components. This includes capture, communication, processing, and persistence of events. Event-driven architectures represent an architectural approach and aren’t based on a specific programming language.
Event-driven architectures are a great fit for distributed software environments and enable minimal coupling. A defining element of an event-driven architecture is that event producers don’t know which event consumers listen for an event and, to go beyond this, what the consequences of the event on the consumer side are. Parties interested in receiving events can subscribe to published events at will. This might result in not only a loose coupling but also a highly flexible software architecture that is constantly changing and adjusting.
There is a clear separation between the production and consumption of events. Event producers don’t need to care about how the events they produce get consumed, and event consumers don’t need to care about how the events they consume are produced.
Let's now move away from these examples to a few more formal definitions that are important to know and understand:
There are in the end two main event types, notification events and data events, plus a hybrid event type that I tend to call decision event.
Notification events are typically as small as possible and contain only the absolutely required information. The idea behind this type of event is that consumers are informed of a change and can then decide whether they care about this change or not. If the change isn’t relevant for the consumer, the consumer ignores the event completely. If the change is relevant for the consumer, the consumer will follow up by requesting additional data and executing on this data. Notification events have a number of advantages and have certain disadvantages as well:
Data events already contain all data in respect to the event that might be relevant for the consumer. No additional request is needed; event processing can start immediately. Data events are bigger than notification events and can potentially be really big. The result is that the costs in respect to transportation of these events from a resource perspective are higher. Advantages/disadvantages of data events are as follows:
Decision events are in the end notification events that contain more data. The idea is that more data in the events results in a better basis to decide on the relevance of the event, and therefore a smaller number of API calls or better informed API calls.
SAP Events are typically exposed in a standard way following the CloudEvents format, with a well-defined hierarchy and metadata that can easily be consumed on different platforms. CloudEvents is a specification for describing event data in a common way jointly driven by the Cloud Native Computing Foundation (CNCF) and a number of software companies, including SAP.
Event-driven architectures have a number of advantages over more traditional architectural styles:
There are even more advantages like improved fault tolerance, low latency and efficient operations. And then there are some disadvantages as well that I would like to at least mention here. EDAs are highly parallel and asynchronous. As a result, it is more challenging to monitor and understand what is going on in a highly distributed, asynchronous event-driven environment.
With SAP's leading role in respect to business software and the fact that more than seventy percent of the world's business transactions in one way or the other touch an SAP system, it is not surprising that SAP has had a strong focus on establishing an event-driven ecosystem that puts all the EDA benefits to play for the advantage of SAP customers.
Quite often people only see the event brokers when discussing EDAs. This is not the reality, the event broker is the engine. Without sufficient event sources and events, without consumers, without enablement and know how build up, the event broker is simply useless. So it takes this entire ecosystem, and like with an iceberg, the main part of the event-driven ecosystem typically remains under the surface. Let us now make the entire ecosystem visible.
SAP's event-driven ecosystem consists of event sources that typically are SAP backends, infrastructure consisting of different event-brokers and event bridging and integration offerings, event consumers that facilitate using event-driven architecture and that allow to execute on business events, and lots of enablement options and guidance.
SAP provides a large number of events originating from different event-enabled backends. As a rule of thumb most events are exposed following the CloudEvents standard, that aims to describe events in a common format across vendor boundaries. Exception from the rule is SAP SuccessFactors solutions that currently does not support CloudEvents.
SAP S/4HANA Cloud exposes around 400 standard events. Available events can be looked up in the API Business Hub (http://api.sap.com). These standard events are notification events and cannot be adjusted. SAP development has to provide new events. On top, there is a new RAP based approach available starting from 2208. This approach currently allows the creation of selected custom events and the plan is, in the long run, to allow for adjustable standard events. RAP-based events can be notification and data events.
SAP S/4HANA exposes pretty much the same number of SAP standard notification events. Typically SAP S/4HANA Cloud is the frontrunner, so usually there is a delay in respect to event availability. The RAP based approach to create custom events and allowing for adjustable standard events is planned for S/4HANA as well. In this case we are talking about notification and data events. There is a third option that is not available for SAP S/4HANA Cloud. The add-on for event enablement allows the creation of custom events. These custom events can be notification and data events. The add-on usage is included in the capacity-based pricing of SAP Event Mesh.
SAP ECC allows a single option in respect to event-enabling it: the event-enablement add-on. Custom notification and data events can be created in a no-code/low-code approach or for more sophisticated events using ABAP coding. The event-enablement add on is included free of additional charge in the capacity-based pricing of SAP Event Mesh.
SAP SuccessFactors solutions provides the Intelligent Services Events that can be fed into SAP Event Mesh. These events can be adjusted and can therefore be notification or data events, as needed.
Other SAP event sources include SAP Fieldglass solutions (add-on), SAP Marketing Cloud (standard notification events) or SAP Data Intelligence. SAP plans and works on event-enabling further backends.
As mentioned before event brokers are intermediaries that broker and manage events. Typically event brokers come with different feature sets, targeting everything from simple extension use cases to highly sophisticated integration use cases. SAP offers two event brokers that complement each other: SAP Event Mesh and SAP Integration Suite, advanced event mesh are SAP's event brokers.
SAP Event Mesh provides a low entry barrier to event-driven architectures with pay per use-based pricing and an event-broker-as-a-service approach. The goal is to allow customers to get started as quickly and easily as possible.
SAP Event Mesh is a BTP service and therefore deployed on SAP BTP. It is the native event broker for SAP S/4HANA and the add-on for event enablement is, if needed, included in the capacity-based pricing of SAP Event Mesh.
The main use case is the integration and extension of SAP backends and business applications, inside and beyond the SAP ecosystem. SAP Event Mesh offers openness and focus at the same time by supporting open standards and providing extra benefits for the SAP ecosystem.
SAP Event Mesh scales well with certain set limits that result from the event-broker-as-a-service approach.
SAP Integration Suite, advanced event mesh is a new offering that complements SAP Event Mesh for more demanding scenarios and is a full blown, general purpose Event Mesh. AEM offers enterprise-grade performance, reliability, security and governance. It scales to very large use cases - and very means very very very in this case.
SAP Integration Suite, advanced event mesh offers deployment options across different hyperscalers and in private cloud environments. It can be configured to form a distributed mesh of event brokers deployed across environments in private or public clouds.
AEM offers a full purpose set of eventing services including event streaming, event management and monitoring and on top advanced features like dynamic message routing and fine-grained filtering.
Find below a quick high level overview of SAP Event Mesh and SAP Integration Suite, advanced event mesh. This table can just scratch on the surface in respect to features and technical background. Expect more information to surface in the coming weeks.
When looking at the event consumer side of things, you first see the expected candidates. SAP Integration Suite does not only provide eventing brokering infrastructure, it consumes events as well for different purposes like feeding these events into some of the services it offers. SAP Extension Suite contains services that allow for consuming events like for example CAP, that is event-enabled to a large extent. Then there are a number of BTP services and apps that consume events, and there is Project "Kyma" which is SAP's offering to build serverless functions and microservices in a cloud native way. Project "Kyma" can act as an event consumer and as an event source. The same holds true for SAP Data Intelligence.
Then there are two event consumers that I would like to look a little closer at: SAP backends and Microsoft Azure Event Grid.
So far we have discussed SAP backends as event sources, meaning we have discussed outbound events. For selected SAP backends there is a second option, namely inbound events. Using the add-on for event enablement SAP S/4HANA and SAP ECC can consume events. Setting this up obviously requires some more effort since you have to define what to do once an event is received, it is possible though. In future the new RAP based approach could allow inbound events for SAP S/4HANA and SAP S/4HANA Cloud.
Then there is Azure Event Grid. We had started a customer engagement initiative last year already for allowing SAP backend events to flow via SAP Event Mesh into Azure Event Grid for consumption. We will continue this year by going Beta with this offering.
All of the technologies, services and offerings described above do not help you if you do not know how and in which combination to use them. To facilitate getting started and later on to facilitate planning projects and architectures SAP offers guidance as part of the Integration Solution Advisory Methodology (ISA-M) and provides so called missions as part of the Discovery Center (https://discovery-center.cloud.sap/missionssearch/event/).
These missions are full blown example projects including descriptions, material and coding and the idea is to get you started quickly while at the same time to provide you with a template for your own projects.
I had planned to wrap this blog up by starting with "This short blog has hopefully given you a comprehensive overview of SAP's Event-Driven Ecosystem". Well, I'm afraid the blog turned out to not be exactly short.
Which is good - it shows how much SAP's Event-Driven Ecosystem has grown over the last months and years. And it will grow further because EDAs will become central for situational awareness and running a business successfully. Real time will simply be expected.
On a personal note, in the next weeks expect a few blogs that specifically look a little closer at SAP's event brokers. Specifically at SAP Integration Suite, advanced event mesh, that is a highly interesting offering and that I am quite excited about. Looking forward to sharing this excitement with you.
Event-driven architecture is one of these concepts that for a long time used to go unnoticed, except for spiders that have used event-driven architecture for thousands of years.
Event-Driven Architecture in Nature and Business
After spinning its web, a spider waits for prey to become trapped on the web. The spider senses the impact and struggle of a prey animal by vibrations transmitted through the web. After it senses a vibration, the spider evaluates whether the vibrations are caused by a prey animal or by something else that the spider isn’t interested in like a leaf. If a leaf ends up in a spiderweb, the spider simply ignores this change to its web. If a prey animal ends up there though, the spider reacts and goes for the prey.
This approach almost perfectly mirrors a notification event based Event-Driven architecture in the IT world:
- The prey or the leaf in the web is an event—a significant change to the status of the spiderweb.
- The spiderweb is the event broker, transporting events via vibrations of the web.
- The spider is the event consumer. It gets informed of significant changes to the status of the web by a notification event and reacts according to the information it receives.
If you look at today's business world, you can see event-driven approaches everywhere. At the airport you check in, go to the gate and then wait for a significant change - the plane being ready for boarding. This is typically announced and all you have to do is to wait for the announcement. You don't have to go to the counter and check every five minutes whether the plane is ready for boarding. You just have to wait and can spend your time relaxing or reading. Until you are informed about the event and then better react by boarding the plane.
Event-Driven Architecture
An event-driven architecture is a software architecture using events as the core means for interaction between its software components. This includes capture, communication, processing, and persistence of events. Event-driven architectures represent an architectural approach and aren’t based on a specific programming language.
Event-driven architectures are a great fit for distributed software environments and enable minimal coupling. A defining element of an event-driven architecture is that event producers don’t know which event consumers listen for an event and, to go beyond this, what the consequences of the event on the consumer side are. Parties interested in receiving events can subscribe to published events at will. This might result in not only a loose coupling but also a highly flexible software architecture that is constantly changing and adjusting.
There is a clear separation between the production and consumption of events. Event producers don’t need to care about how the events they produce get consumed, and event consumers don’t need to care about how the events they consume are produced.
Components of EDAs
Let's now move away from these examples to a few more formal definitions that are important to know and understand:
- Events are significant changes in state. In the SAP world this could be a BusinessPartner getting updated in SAP S/4HANA or a SalesOrder created in SAP ECC.
- Event Sources are the source of the event and broadcast the event to indicate that it has occurred. Event Sources only know about the occurrence of the event; they don’t know who is interested in the event and what the interested parties will do in reaction to being informed about the event. In the SAP ecosystem the most common event sources are the different backend systems like SAP S/4HANA or SAP SuccessFactors solutions.
- Event brokers are intermediaries that broker and manage events. SAP Event Mesh and SAP Integration Suite, advanced event mesh are SAP's event brokers.
- Event Consumers are software components that subscribe to the event broker to be informed about events. In the SAP ecosystem, several kinds of event consumers are possible, ranging from extension applications on SAP Business Technology Platform to full blown SAP Backends like SAP S/4HANA.
Event Types and Format
There are in the end two main event types, notification events and data events, plus a hybrid event type that I tend to call decision event.
Notification Events
Notification events are typically as small as possible and contain only the absolutely required information. The idea behind this type of event is that consumers are informed of a change and can then decide whether they care about this change or not. If the change isn’t relevant for the consumer, the consumer ignores the event completely. If the change is relevant for the consumer, the consumer will follow up by requesting additional data and executing on this data. Notification events have a number of advantages and have certain disadvantages as well:
- They are typically very small so a lot of notifications can be sent.
- They contain only the absolutely required data so data access can be controlled in a better way.
- An additional step is needed when following up on an event to access all required data.
- Depending on the number of events that are followed up on, they can be highly efficient or highly inefficient.
Data Events
Data events already contain all data in respect to the event that might be relevant for the consumer. No additional request is needed; event processing can start immediately. Data events are bigger than notification events and can potentially be really big. The result is that the costs in respect to transportation of these events from a resource perspective are higher. Advantages/disadvantages of data events are as follows:
- All potentially needed data is included in the event; no additional request is needed.
- Serve well for use cases in which the consumer would require a full data set in the majority of cases.
- Data events tend to be big, resulting in higher resource consumption and, in the end, in higher costs for the event broker.
- There is a certain loss of control in respect to who can access potentially sensitive data.
Decision Events
Decision events are in the end notification events that contain more data. The idea is that more data in the events results in a better basis to decide on the relevance of the event, and therefore a smaller number of API calls or better informed API calls.
CloudEvents Format
SAP Events are typically exposed in a standard way following the CloudEvents format, with a well-defined hierarchy and metadata that can easily be consumed on different platforms. CloudEvents is a specification for describing event data in a common way jointly driven by the Cloud Native Computing Foundation (CNCF) and a number of software companies, including SAP.
Benefits of Event-Driven Architectures
Event-driven architectures have a number of advantages over more traditional architectural styles:
- The situational awareness is increased by receiving and being able to combine business real time updates on events in other business applications. This results in quicker and better business decisions. Real time is actually what most customers see as the main benefit.
- The loose coupling provided by EDAs results in increased flexibility and scalability. In the end this allows to changing business environments quickly.
- Easy re-use of existing eventing infrastructure providing more comfort and less costs. The bottom line here is that you set up an eventing infrastructure one and then use it again and again for different events and event sources.
- Open standards like the CloudEvent standard allow to cross vendor boundaries
There are even more advantages like improved fault tolerance, low latency and efficient operations. And then there are some disadvantages as well that I would like to at least mention here. EDAs are highly parallel and asynchronous. As a result, it is more challenging to monitor and understand what is going on in a highly distributed, asynchronous event-driven environment.
SAP's Event-Driven Ecosystem
With SAP's leading role in respect to business software and the fact that more than seventy percent of the world's business transactions in one way or the other touch an SAP system, it is not surprising that SAP has had a strong focus on establishing an event-driven ecosystem that puts all the EDA benefits to play for the advantage of SAP customers.
Quite often people only see the event brokers when discussing EDAs. This is not the reality, the event broker is the engine. Without sufficient event sources and events, without consumers, without enablement and know how build up, the event broker is simply useless. So it takes this entire ecosystem, and like with an iceberg, the main part of the event-driven ecosystem typically remains under the surface. Let us now make the entire ecosystem visible.
Overview
SAP's event-driven ecosystem consists of event sources that typically are SAP backends, infrastructure consisting of different event-brokers and event bridging and integration offerings, event consumers that facilitate using event-driven architecture and that allow to execute on business events, and lots of enablement options and guidance.
SAPs Event-Driven Ecosystem
Event Sources
SAP provides a large number of events originating from different event-enabled backends. As a rule of thumb most events are exposed following the CloudEvents standard, that aims to describe events in a common format across vendor boundaries. Exception from the rule is SAP SuccessFactors solutions that currently does not support CloudEvents.
SAP S/4HANA Cloud exposes around 400 standard events. Available events can be looked up in the API Business Hub (http://api.sap.com). These standard events are notification events and cannot be adjusted. SAP development has to provide new events. On top, there is a new RAP based approach available starting from 2208. This approach currently allows the creation of selected custom events and the plan is, in the long run, to allow for adjustable standard events. RAP-based events can be notification and data events.
SAP S/4HANA exposes pretty much the same number of SAP standard notification events. Typically SAP S/4HANA Cloud is the frontrunner, so usually there is a delay in respect to event availability. The RAP based approach to create custom events and allowing for adjustable standard events is planned for S/4HANA as well. In this case we are talking about notification and data events. There is a third option that is not available for SAP S/4HANA Cloud. The add-on for event enablement allows the creation of custom events. These custom events can be notification and data events. The add-on usage is included in the capacity-based pricing of SAP Event Mesh.
SAP ECC allows a single option in respect to event-enabling it: the event-enablement add-on. Custom notification and data events can be created in a no-code/low-code approach or for more sophisticated events using ABAP coding. The event-enablement add on is included free of additional charge in the capacity-based pricing of SAP Event Mesh.
SAP SuccessFactors solutions provides the Intelligent Services Events that can be fed into SAP Event Mesh. These events can be adjusted and can therefore be notification or data events, as needed.
Other SAP event sources include SAP Fieldglass solutions (add-on), SAP Marketing Cloud (standard notification events) or SAP Data Intelligence. SAP plans and works on event-enabling further backends.
Event Brokers
As mentioned before event brokers are intermediaries that broker and manage events. Typically event brokers come with different feature sets, targeting everything from simple extension use cases to highly sophisticated integration use cases. SAP offers two event brokers that complement each other: SAP Event Mesh and SAP Integration Suite, advanced event mesh are SAP's event brokers.
SAP Event Mesh
SAP Event Mesh provides a low entry barrier to event-driven architectures with pay per use-based pricing and an event-broker-as-a-service approach. The goal is to allow customers to get started as quickly and easily as possible.
SAP Event Mesh is a BTP service and therefore deployed on SAP BTP. It is the native event broker for SAP S/4HANA and the add-on for event enablement is, if needed, included in the capacity-based pricing of SAP Event Mesh.
The main use case is the integration and extension of SAP backends and business applications, inside and beyond the SAP ecosystem. SAP Event Mesh offers openness and focus at the same time by supporting open standards and providing extra benefits for the SAP ecosystem.
SAP Event Mesh scales well with certain set limits that result from the event-broker-as-a-service approach.
SAP Event Mesh
SAP Integration Suite, advanced event mesh
SAP Integration Suite, advanced event mesh is a new offering that complements SAP Event Mesh for more demanding scenarios and is a full blown, general purpose Event Mesh. AEM offers enterprise-grade performance, reliability, security and governance. It scales to very large use cases - and very means very very very in this case.
SAP Integration Suite, advanced event mesh offers deployment options across different hyperscalers and in private cloud environments. It can be configured to form a distributed mesh of event brokers deployed across environments in private or public clouds.
AEM offers a full purpose set of eventing services including event streaming, event management and monitoring and on top advanced features like dynamic message routing and fine-grained filtering.
A glimpse of SAP Integration Suite, advanced event mesh
High Level Overview of SAP Event Mesh and SAP Integration Suite, advanced event mesh
Find below a quick high level overview of SAP Event Mesh and SAP Integration Suite, advanced event mesh. This table can just scratch on the surface in respect to features and technical background. Expect more information to surface in the coming weeks.
Event Consumers
When looking at the event consumer side of things, you first see the expected candidates. SAP Integration Suite does not only provide eventing brokering infrastructure, it consumes events as well for different purposes like feeding these events into some of the services it offers. SAP Extension Suite contains services that allow for consuming events like for example CAP, that is event-enabled to a large extent. Then there are a number of BTP services and apps that consume events, and there is Project "Kyma" which is SAP's offering to build serverless functions and microservices in a cloud native way. Project "Kyma" can act as an event consumer and as an event source. The same holds true for SAP Data Intelligence.
Then there are two event consumers that I would like to look a little closer at: SAP backends and Microsoft Azure Event Grid.
So far we have discussed SAP backends as event sources, meaning we have discussed outbound events. For selected SAP backends there is a second option, namely inbound events. Using the add-on for event enablement SAP S/4HANA and SAP ECC can consume events. Setting this up obviously requires some more effort since you have to define what to do once an event is received, it is possible though. In future the new RAP based approach could allow inbound events for SAP S/4HANA and SAP S/4HANA Cloud.
Then there is Azure Event Grid. We had started a customer engagement initiative last year already for allowing SAP backend events to flow via SAP Event Mesh into Azure Event Grid for consumption. We will continue this year by going Beta with this offering.
Enablement and Guidance
All of the technologies, services and offerings described above do not help you if you do not know how and in which combination to use them. To facilitate getting started and later on to facilitate planning projects and architectures SAP offers guidance as part of the Integration Solution Advisory Methodology (ISA-M) and provides so called missions as part of the Discovery Center (https://discovery-center.cloud.sap/missionssearch/event/).
These missions are full blown example projects including descriptions, material and coding and the idea is to get you started quickly while at the same time to provide you with a template for your own projects.
Wrap Up and Outlook
I had planned to wrap this blog up by starting with "This short blog has hopefully given you a comprehensive overview of SAP's Event-Driven Ecosystem". Well, I'm afraid the blog turned out to not be exactly short.
Which is good - it shows how much SAP's Event-Driven Ecosystem has grown over the last months and years. And it will grow further because EDAs will become central for situational awareness and running a business successfully. Real time will simply be expected.
On a personal note, in the next weeks expect a few blogs that specifically look a little closer at SAP's event brokers. Specifically at SAP Integration Suite, advanced event mesh, that is a highly interesting offering and that I am quite excited about. Looking forward to sharing this excitement with you.
- SAP Managed Tags:
9 Comments
