Introduction and brief history:
Operating in the background, usually unnoticed by end consumers, the battle for organisations to have more scalable, responsive, and resilient systems is never-ending. This has resulted in rapid innovations to integration technologies such as SAP BTP Integration Suite that have allowed companies to be more interconnected than ever.
A brief look back over the last few decades showcases how fast integration technologies have changed. If we were to travel back in time to even the most sophisticated organisations of the early 90’s, we would find for the most part a scattered network of point-2-point integrations. Whilst highly customizable, these point-2-point integrations are very cumbersome to maintain and even harder to scale up.
Fast forward to the 2010’s, integration systems have advanced to cloud hosted middleware software platforms like SAP BTP that offer service-based architectures and even API management capabilities.
In retrospect it’s impressive to see the amount of change in such a short time span, but the rate of innovation certainly isn’t slowing. In today’s digital age, there has never been more data available, and organisations are requiring to be faster at responding and managing this data. To achieve this, organisations are now adopting Event Based Architecture (EBA). If you haven’t heard of EBA before, you’ve benefited from its capabilities. Here are just a few EBA use cases that are commonplace now however would have placed an organisation as an industry leader no longer than 10 years ago.
1. Retail Store Tracking: Automatically tack orders, send alerts and update stock levels in real-time.
2. E-Commerce Product Recommendations: Provide immediate, personalized product recommendations based on the customer’s browsing history, purchase behaviour, and real-time actions on the site.
3. Dynamic Pricing: Airlines, hotels, and other service providers use dynamic pricing algorithms that react to events such as demand surges, time of booking, and customer behaviour to offer customised pricing.
In this blog, we’ll delve into the fundamentals of EBA, how it’s managed with SAP Event Mesh and a quick glance to the future of integration technology.
Section 1: What is Event Based Architecture?
EBA is a system design that focuses on detecting and acting upon changes in data within the system (these changes are called “events”). This is a shift away from prior techniques which relied on pre-emptively scheduling actions to be performed. The key benefit of EBA is its ability to have actions automatically triggered as soon as data events occur, allowing for a more responsive and adaptive system.
Section 1.2: Event Based Architecture Components?
At a high level, an EBA is straight forward and consists of three parts.
The process starts with an “event source”, which is the system or component that creates an event that may be of interest to other components of the system. The event source captures the event occurrence and sends a notification to the other parts of the system allowing them to react. Event sources are numerous, but a few common examples are user interactions (button clicks, form submissions, etc.), data base manipulations (inserts, updates, deletes) and financial/ commerce updates (orders, placed, cancelled, shipped, inventory level updates). Common systems that allow for these events can be seen in the above image.
For event sources to send events a middle layer “event infrastructure” or “event broker” system is required to facilitate. These software systems are created to manage and provide the foundational mechanisms required to generate, transmit and process events. One of the most common software systems employed to perform this task is the SAP Event Mesh and Advanced Event Mesh services within SAP Integration Suite. This blog will cover basic features of SAP Event Mesh.
Finally, the process ends with the event handler or consumer. This component is responsible for listening to events and acting upon them. Like event generators this can take many forms, but the a few common examples are data processing (filtering, aggregating/ summarizing), triggering workflows (start a new business process, advance a current workflow) and notifications (email, alerting systems, push). Common systems that allow for these events can be seen in the above image.
Contextualising this into a real-life example. Let’s imagine, we manage a national e-commerce organisation that wishes to implement live inventory tracking. Within an EBA the event source will be triggered by a customer placing an order in the system. This would send a notification through the middleware (event broker) to the inventory system (event consumer) to action the database update.
Section 1.2.1 Event Based Architecture Components? – Scaled Up
The previous scenario is a straightforward example of how EBA can be placed into a single use case. Now what would happen if we scaled this up to an international organisation? Let’s now make our e-commerce organisation cater to customers all over the globe.
With this expanded scope, event sources may also come from: New York, London and Singapore (we now have customers ordering from all over the world). Whilst we can use the set up before, due to the distances between the sources and the consumer we must consider constraints such as latency (the time it takes for data to travel between systems), different region regulations on data (certain data may be required to be stored within a given region), reliability, etc. These challenges if not addressed could result in our system being inconsistent which could impact revenue (items could be sold even though there isn’t any inventory left due to the event consumer not being notified on time).
This challenge could be remedied to an extent by moving the event infrastructure to a centralised location between all parties to treat them all equally.
This can help with uneven latency but not regulation, data, governance or many other of the requirements that are placed on a world-wide software system. Furthermore, what happens when we have additional customers and inventory systems around the world?
At this point we can’t simply move our event broker to a centralised location as it’s now limiting our control on the different event sources and consumers. What we can do instead is identify key event sources and consumers and have several event brokers around the world. The regional event brokers would communicate to the regions event sources and consumers and then have a separate communication channel between other event brokers. The event brokers now form an event mesh. This system has the benefit of reduced latency and now also allows for greater authority rulings to be implemented, allowing greater control on data governance and event filtering.
Along the journey to this point, a formal software solution is required in order manage this Event Mesh. This is where SAP Event Mesh comes in.
Section 2: What is SAP Event Mesh?
SAP Event Mesh is SAP’s event infrastructure solution and is a fully managed cloud service that allows applications to communicate through events. For organisations, it provides an intuitive, unified interface to design, deploy, manage, monitor, and govern your event infrastructure.
Amongst others, SAP Event Mesh offers the following key features:
Publish business events:
Publish business events from SAP and non-SAP sources across hybrid landscapes from the digital core to extension applications through event-driven architecture.
Consume business events:
Consume business events from SAP and non-SAP sources throughout SAP’s event-driven ecosystem including SAP Extension Suite, SAP Integration Suite, and selected inbound enabled SAP back ends.
Connect Seamlessly:
Provides reliable data transmission for extension and integration scenarios through decoupled communication.
For more information and tours on SAP Event Mesh please see: https://help.sap.com/docs/event-mesh/event-mesh/event-mesh-default-plan-concepts?locale=en-US
Section 4: What’s Next? (Potentially Artificial Intelligence)
It’s always a gamble to predict where the future of technology will take us so it’s important note the following paragraph is highly speculative and only time will tell.
As mentioned in the opening sentence of this blog, the battle for organisations to have more scalable, responsive, and resilient systems is never-ending. Integration software in it’s current form has certainly taken some great leaps and is almost unrecognisable from it’s humble beginnings. However, there are still improvements to be made.
Perhaps one of the most interesting areas where innovation could come from is the continual development of artificial intelligence (AI). As it stands, whilst EBA is highly responsive, certain rulings and dataflows can be static and require human input to change, design and implement. This could be seen as a bottleneck due to the fact that humans are not as fast as computers. This human factor is certainly reduced by short cuts and optimisations, but with the ever-increasing demand for speed and responsiveness we could come to the point where even this human input is too slow for what’s required to stay competitive. Through artificial intelligence, integration software could develop the ability to understand, reason, and adapt like never before. Here is a few capabilities that we could see emerge or become more present as this technology advances.
1. Automated Data Mapping and Transformation: AI could automatically understand data fields from different systems and transform them into a compatible format for the target system.
2. Enhanced API Management: AI could optimize API management by understanding usage patterns and predicting API demands. This could enhance load balancing and latency reduction.
3. Context-Aware Integration: AI can make integrations context-aware by understanding the broader business context and operational conditions. This could reduce the project timelines of System Admins and Business Analysts to discover and design new integrations.
4. Natural Language Addition: This will allow for users to interact with integration platforms using natural language queries and commands. Opening integration management to more business users and further increasing the speed humans interact with the system.
Introduction and brief history:Operating in the background, usually unnoticed by end consumers, the battle for organisations to have more scalable, responsive, and resilient systems is never-ending. This has resulted in rapid innovations to integration technologies such as SAP BTP Integration Suite that have allowed companies to be more interconnected than ever.A brief look back over the last few decades showcases how fast integration technologies have changed. If we were to travel back in time to even the most sophisticated organisations of the early 90’s, we would find for the most part a scattered network of point-2-point integrations. Whilst highly customizable, these point-2-point integrations are very cumbersome to maintain and even harder to scale up.Fast forward to the 2010’s, integration systems have advanced to cloud hosted middleware software platforms like SAP BTP that offer service-based architectures and even API management capabilities. In retrospect it’s impressive to see the amount of change in such a short time span, but the rate of innovation certainly isn’t slowing. In today’s digital age, there has never been more data available, and organisations are requiring to be faster at responding and managing this data. To achieve this, organisations are now adopting Event Based Architecture (EBA). If you haven’t heard of EBA before, you’ve benefited from its capabilities. Here are just a few EBA use cases that are commonplace now however would have placed an organisation as an industry leader no longer than 10 years ago.1. Retail Store Tracking: Automatically tack orders, send alerts and update stock levels in real-time.2. E-Commerce Product Recommendations: Provide immediate, personalized product recommendations based on the customer’s browsing history, purchase behaviour, and real-time actions on the site.3. Dynamic Pricing: Airlines, hotels, and other service providers use dynamic pricing algorithms that react to events such as demand surges, time of booking, and customer behaviour to offer customised pricing.In this blog, we’ll delve into the fundamentals of EBA, how it’s managed with SAP Event Mesh and a quick glance to the future of integration technology. Section 1: What is Event Based Architecture?EBA is a system design that focuses on detecting and acting upon changes in data within the system (these changes are called “events”). This is a shift away from prior techniques which relied on pre-emptively scheduling actions to be performed. The key benefit of EBA is its ability to have actions automatically triggered as soon as data events occur, allowing for a more responsive and adaptive system. Section 1.2: Event Based Architecture Components?At a high level, an EBA is straight forward and consists of three parts. The process starts with an “event source”, which is the system or component that creates an event that may be of interest to other components of the system. The event source captures the event occurrence and sends a notification to the other parts of the system allowing them to react. Event sources are numerous, but a few common examples are user interactions (button clicks, form submissions, etc.), data base manipulations (inserts, updates, deletes) and financial/ commerce updates (orders, placed, cancelled, shipped, inventory level updates). Common systems that allow for these events can be seen in the above image.For event sources to send events a middle layer “event infrastructure” or “event broker” system is required to facilitate. These software systems are created to manage and provide the foundational mechanisms required to generate, transmit and process events. One of the most common software systems employed to perform this task is the SAP Event Mesh and Advanced Event Mesh services within SAP Integration Suite. This blog will cover basic features of SAP Event Mesh.Finally, the process ends with the event handler or consumer. This component is responsible for listening to events and acting upon them. Like event generators this can take many forms, but the a few common examples are data processing (filtering, aggregating/ summarizing), triggering workflows (start a new business process, advance a current workflow) and notifications (email, alerting systems, push). Common systems that allow for these events can be seen in the above image.Contextualising this into a real-life example. Let’s imagine, we manage a national e-commerce organisation that wishes to implement live inventory tracking. Within an EBA the event source will be triggered by a customer placing an order in the system. This would send a notification through the middleware (event broker) to the inventory system (event consumer) to action the database update. Section 1.2.1 Event Based Architecture Components? – Scaled UpThe previous scenario is a straightforward example of how EBA can be placed into a single use case. Now what would happen if we scaled this up to an international organisation? Let’s now make our e-commerce organisation cater to customers all over the globe. With this expanded scope, event sources may also come from: New York, London and Singapore (we now have customers ordering from all over the world). Whilst we can use the set up before, due to the distances between the sources and the consumer we must consider constraints such as latency (the time it takes for data to travel between systems), different region regulations on data (certain data may be required to be stored within a given region), reliability, etc. These challenges if not addressed could result in our system being inconsistent which could impact revenue (items could be sold even though there isn’t any inventory left due to the event consumer not being notified on time). This challenge could be remedied to an extent by moving the event infrastructure to a centralised location between all parties to treat them all equally. This can help with uneven latency but not regulation, data, governance or many other of the requirements that are placed on a world-wide software system. Furthermore, what happens when we have additional customers and inventory systems around the world? At this point we can’t simply move our event broker to a centralised location as it’s now limiting our control on the different event sources and consumers. What we can do instead is identify key event sources and consumers and have several event brokers around the world. The regional event brokers would communicate to the regions event sources and consumers and then have a separate communication channel between other event brokers. The event brokers now form an event mesh. This system has the benefit of reduced latency and now also allows for greater authority rulings to be implemented, allowing greater control on data governance and event filtering. Along the journey to this point, a formal software solution is required in order manage this Event Mesh. This is where SAP Event Mesh comes in.Section 2: What is SAP Event Mesh?SAP Event Mesh is SAP’s event infrastructure solution and is a fully managed cloud service that allows applications to communicate through events. For organisations, it provides an intuitive, unified interface to design, deploy, manage, monitor, and govern your event infrastructure.Amongst others, SAP Event Mesh offers the following key features:Publish business events:Publish business events from SAP and non-SAP sources across hybrid landscapes from the digital core to extension applications through event-driven architecture.Consume business events:Consume business events from SAP and non-SAP sources throughout SAP’s event-driven ecosystem including SAP Extension Suite, SAP Integration Suite, and selected inbound enabled SAP back ends.Connect Seamlessly:Provides reliable data transmission for extension and integration scenarios through decoupled communication.For more information and tours on SAP Event Mesh please see: https://help.sap.com/docs/event-mesh/event-mesh/event-mesh-default-plan-concepts?locale=en-US Section 4: What’s Next? (Potentially Artificial Intelligence)It’s always a gamble to predict where the future of technology will take us so it’s important note the following paragraph is highly speculative and only time will tell.As mentioned in the opening sentence of this blog, the battle for organisations to have more scalable, responsive, and resilient systems is never-ending. Integration software in it’s current form has certainly taken some great leaps and is almost unrecognisable from it’s humble beginnings. However, there are still improvements to be made. Perhaps one of the most interesting areas where innovation could come from is the continual development of artificial intelligence (AI). As it stands, whilst EBA is highly responsive, certain rulings and dataflows can be static and require human input to change, design and implement. This could be seen as a bottleneck due to the fact that humans are not as fast as computers. This human factor is certainly reduced by short cuts and optimisations, but with the ever-increasing demand for speed and responsiveness we could come to the point where even this human input is too slow for what’s required to stay competitive. Through artificial intelligence, integration software could develop the ability to understand, reason, and adapt like never before. Here is a few capabilities that we could see emerge or become more present as this technology advances.1. Automated Data Mapping and Transformation: AI could automatically understand data fields from different systems and transform them into a compatible format for the target system.2. Enhanced API Management: AI could optimize API management by understanding usage patterns and predicting API demands. This could enhance load balancing and latency reduction.3. Context-Aware Integration: AI can make integrations context-aware by understanding the broader business context and operational conditions. This could reduce the project timelines of System Admins and Business Analysts to discover and design new integrations.4. Natural Language Addition: This will allow for users to interact with integration platforms using natural language queries and commands. Opening integration management to more business users and further increasing the speed humans interact with the system. Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
