Skip to Content
Product Information
Author's profile photo Karsten Strothmann

SAP Event Mesh: Event Connector to Microsoft Azure to go Beta

Event-Driven Architecture

Event-driven architectures are one of the hottest trends these days. EDAs offer so many advantages over synchronous, more traditional approaches that lots of customers have started looking into how they can put these architectures to use.

Most customers look for the real time benefits first – an event occurring in an SAP backend system and consumers across the customer landscape getting notified of this significant change in real time. There are more advantages though that are often overlooked: loose coupling, incremental development, handling of peak loads to name a few. And easily and efficiently crossing vendor boundaries using events – we will get back to this major advantage later.

Just a beginning

Overall, I strongly believe that we are just at the beginning of the rise of Event-Driven Architectures. What you see below is my favourite analogy these days: a lodge, a village and a bigger city.

Most customers currently look at event-driven scenarios that resemble the lodge on the left. Their events aren’t too many and the scenarios are very specific to individual use cases. What significant changes could occur for this small building? The lights getting switched on or off. The Jacuzzi being ready for you to get in.

Few customers have made it to the next level: they have already reached the village level. A lot more events occur and get distributed, connecting different and more sophisticated buildings in that village. Transferring this to the SAP world, these customers already use a lot of different event sources (like SAP backends) and event consumers (like extension applications on the SAP BTP) that are connected in more sophisticated ways. You need more advanced operations and you specifically need a well planned and scalable infrastructure connecting your event sources and your consumers.

What lies ahead of us is the equivalent of the big city on the right. Think of all the potential events that can occur in a single one of these high rise buildings. How many lights can get switched on or off? Think of the peak load in the morning when everybody comes into office or in the evening when everybody leaves. Think about the number of events all the buildings in this city would fire every day. And then consider that the city in the picture is just Frankfurt, a city of 764104 people. Now think of New York, think of Shanghai or think of Tokyo.


Large Scale Eventing Infrastructure

When you think about large scale eventing infrastructures – and you might even still do this in the context of the big city example above because the conclusions would be the same – a few things are obvious:

  • do it yourself solutions won’t work on this scale
  • infrastructure has to be highly professional and reliable
  • open standards are key to make things work
  • at the same time you want focused sub-meshes that support your business best
  • you need the right mix of openness and control (monitoring and tracing that is) to allow for a separation of concerns and efficient operations

Microsoft’s and SAP’s joint vision

EDAs are an open approach across vendor boundaries to bring IT worlds together. These event meshes will bring eventing infrastructure, software and services from a lot of vendors together, not only SAP and Microsoft. The CloudEvents initiative already addresses the topic of a common format to describe events, and both SAP and Microsoft take part in this initiative.

The situation for SAP and Microsoft is even more special though: the two companies have a great working relationship and a lot of SAP’s customers are as well Microsoft customers.

Our joint vision is that our customers can consume SAP (backend) events on Azure, and that they can consume Microsoft events on the SAP Business Technology Platform or directly in an SAP backend. This is where we want to go.

And we want to go there in a way that will allow to support the future large scale event-driven architectures of our customers.

New event connector from SAP Event Mesh to Azure Event Grid

With the new connector from SAP Event Mesh to Azure Event Grid, SAP and Microsoft will offer a real time, event-driven integration between the SAP and the Microsoft world. This will allow for a worry free event exposure in respect to standard event sources and data security

Important for enterprise customers: the connector is implemented and supported jointly by both SAP and Microsoft, avoiding the pitfalls of DIY or non-standard solutions.

It offers a clearly defined handover point allowing for:

  • Event handover between SAP and Microsoft sub-meshes allowing for separation of concerns and improved monitoring and tracing
  • Openness and Control over events at the same time by connecting structured meshes using an event gateway concept
  • Opinionated, vendor-optimized sub-meshes offering additional technical and business value

From a business perspective, this new connector allows for a tighter coupling of SAP and Microsoft business applications and technology based on loose, event-driven coupling. This will allow for new real time end-to-end business scenarios in numerous areas.


Vision of SAP to Azure Event Connector


From a technical perspective, this connector is aimed at allowing to:

  • Send events from Event Mesh to a partner topic in Azure Event Grid. Other applications can subscribe to and consume those events from Azure Event Grid.
  • Send events from Azure Event Grid to a destination topic in SAP Even Mesh. Applications connected to Event Mesh can access these events.

SAP Event Mesh Connector for Azure Beta

Starting from October 11th 2022, the new SAP Event Mesh Connector for Azure will be available as part of an SAP Beta program. This connector will allow to flow SAP events to Azure Event Grid. Registration will be open until November 30th and the Beta us currently planned to be ongoing until January 31st.

Please note: this Beta program is an invitation only program on the SAP side – you will have to apply to participate.

If you participate you can test the new product with your own data and landscape before the official release. On top, this provides you with an opportunity to provide early feedback.

SAP Beta programs provide you with early access to SAP software to test and see how it fits your business requirements. Beta shipments are provided under a Test and Evaluation Agreement (TEA) and can be used for testing purposes only.

Productive usage is not allowed and is not supported under the maintenance and support agreement.

Scope and supported backends

The scope of the Beta program obviously includes the SAP Event Mesh to Azure connectivity on both the SAP and Microsoft side. The event flow as part of the Beta program is currently limited to SAP S/4HANA via SAP Event Mesh to Azure Event Grid. The other direction is not supported yet, might get added to the Beta program while it is ongoing.

From an event source perspective, you do require an SAP S/4HANA system (release 2020 or newer) as an event source, if you would like to try out the end to end flow. Around 220 events from SAP S/4 have currently been tested and can be used during the Beta.

Events supported include events related to:

  • Allergen
  • Batch
  • BillOfMaterial
  • BusinessPartner
  • SalesOrder
  • BillingDocument
  • BillingDocumentRequest
  • BusinessSituation
  • CostCenter
  • Equipment
  • Product
  • ProductionOrder
  • SupplierInvoice

and many more.

Event details for SAP S/4HANA events supported as part of the Beta program can be found on the API Business Hub following this direct link.

How to participate in the Beta program

In case that you are interested in participating in the Beta program, please follow this link.

Additional Blog by Microsoft

Microsoft has published a blog as well. Find it here.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Saurabh Kabra
      Saurabh Kabra

      Hi Karsten Strothmann ,

      While I really see the benefit of having this connector in the landscape when a customer uses both SAP and Microsoft application to support their business process. However, what is not clear to me is, why do we need this connector at all? Why can't SAP Event Mesh process the events that trigger from MS applications OR why can't MS Azure Event Grid process the events that trigger from SAP applications? This question becomes more relevant when we say both SAP and MS are part of the CloudEvent Initiative/specification and I would assume that this initiative should have brought together all the companies(including SAP and MS) on the same standards so that events are cross-platform compliant/consumable.

      Sorry if this is a very lame question!



      Author's profile photo Karsten Strothmann
      Karsten Strothmann
      Blog Post Author

      Hi Saurabh,

      not a lame question, a very good question. I will try to answer on different levels, because in the end you can see this from different perspectives.

      1. The backend perspective: some SAP - and third party - backends are very protective / careful in respect to event exposure and event consumption. SAP S/4HANA Cloud, for example, currently exposes and consumes SAP standard events only via SAP Event Mesh. They are reluctant to directly support any other event broker. This is the choice of the backends and there are in the end two main reasons for this: quality assurance and performance/business impact. Both reasons are closely correlated, and the background is that the number of events a backend can expose and consume can be huge. So you want to play this safely.
      2. Structure: I like my real world comparisons. Look at the mobile phone networks around the planet. I could call your mobile phone probably from most countries in the world. Still, if you look at the underlying structure you will see sub-networks. These sub-networks typically span a country. And there are "bridges" between the networks. The background here is separation of concerns and modularization. We do see this pattern at a number of customers that use different, connected sub-meshes.
      3. Efficiency / scale: another real world comparison. Look at airlines and airports and how they handle air traffic. Typically, for longer flights, there are hub airports. Smaller planes collect passengers at smaller airports which then transfer into bigger planes at these hub airports. The bigger planes are then used for intercontinental flights. If I transfer this concept into the IT / EDA world, I see sub-meshes with "bridges" between them again.
      4. Gatekeeper / Traceability: you want to be able to control which events flow in and out of your sub-mesh. Not every event is supposed to go out of your ecosystem. This holds specifically true for your SAP sub-mesh which is likely very business focused. On top, you might want to be able to trace events which is another thing a gatekeeper will allow you to do.

      So, in the end there are a few reasons for this approach. Some of these reasons are based on the current situation, some more on future developments. And given, some are more important than others. Overall I believe that this approach is a natural pattern.

      Hope this helps,




      Author's profile photo Saurabh Kabra
      Saurabh Kabra

      Hi Karsten Strothmann: Thanks for explaining it in the detail. And I think, now, it makes more sense to me after I imagine the Point 1(the backend perspective) as well as Point 3(Efficiency/Scale) analogy shared by you.

      Author's profile photo Saurabh Kumbhare
      Saurabh Kumbhare

      I love this. I had this vision and I proposed solution at my client exactly with this vision. I knew Msft and SAP will work on this. Luckily, all my proposed designs will be simplified with this bridge.

      Reach out to me on if you want to work closely with me/ my client or if you would like to involve us as part of the beta program.


      You made my day!!!



      Author's profile photo Pradeep Panda
      Pradeep Panda

      Hi Saurabh,

      Nice to know that you liked the vision and concept. We have shared the details of the BETA program to your mail id.

      Thanks for showing interest. Looking forward to your active participation and feedback.




      Author's profile photo Srinivasa Ravva
      Srinivasa Ravva



      Its a great concept, and love to work on beta programs.

      Please share the details on



      Author's profile photo Pradeep Panda
      Pradeep Panda

      Hey Srinivasa,

      We have send you a mail with details.

      Appreciate your participation.




      Author's profile photo David Pierre
      David Pierre

      Dear Karsten,

      Our customer is interested in the beta.  Could you contact me at


      Best regards, David

      Author's profile photo Karsten Strothmann
      Karsten Strothmann
      Blog Post Author

      Hi David,

      good to hear this. Pradeep, who drives the Beta, will get in touch with you.



      Author's profile photo Pradeep Panda
      Pradeep Panda

      Hey David,

      Have sent you the details to your mail id.

      Do not hesitate to get back to us, should you have any query.




      Author's profile photo Jonathan Prow
      Jonathan Prow

      Hi Karsten,

      Since Netweaver Addon uses the same event schema as S/4 and EM is decoupled from the backend. Would the beta consider customers using ECC and CRM with SAP NetWeaver Add-On for Event enablement 1.0 in place of S/4?

      Align Notification Events to S/4 | SAP Help Portal




      Author's profile photo Karsten Strothmann
      Karsten Strothmann
      Blog Post Author

      Hi Jon,

      In scope for the Beta are only newer S/4HANA on premise backends. I understand that this is currently the biggest challenge for participation, unfortunately this is the way it is at this point in time.



      Author's profile photo David Maughan
      David Maughan


      Is there any update when when the "event mesh > Azure Event Grid" connector will come out of BETA ?


      Thanks David