Understanding Event Meshes and Mesh Manager

With advanced event mesh for SAP Integration Suite, modern enterprises can now embrace event-driven architecture (EDA) as part of their digital transformation. EDA is software pattern where decoupled applications can asynchronously publish and subscribe to events; these events are managed by event broker services. In a good EDA, you want decoupled applications to publish events to any event broker service and are assured that subscribing applications receive those events in reliable and seamless fashion. As a result, every event-driven enterprise needs a central-nervous system to quickly, reliably, and securely move events in real-time from where they are occurring to where they need to go. An event mesh provides this capability.

What's an event mesh?

An event mesh is a configurable and dynamic infrastructure layer for distributing events among decoupled applications, cloud services, and devices. Mesh Manager builds an event mesh by connecting event broker services.

An event mesh permits you to:

  • build a software architecture that ensures that event messages are securely and reliably received by subscribing applications using event broker services that are deployed and connected
  • share information between distributed, decoupled applications, which means that a publishing application can send events and another subscribing application to consume those events without knowing about each other
  •  to connect and easily scale hybrid - or multi-cloud event meshes that span multiple data centers; an event mesh ensures that events are exchanged between distributed, decoupled applications in real-time no matter where they are connected in a reliable manner

To help expand your understanding, let's consider this scenario to see how an event mesh works. Imagine that you have multiple applications connected to event broker services in different geographic regions of the world that want to exchange events. Potentially, those applications are distributed in separate clouds or data centers. If those applications connect to the same event broker service, events are exchanged seamlessly without the applications knowing about each other. However, those event broker services in this case aren't meshed together.

Consider this example where Subscriber A is connected to My-Second-Service (an event broker service), but it is interested in events from both Publisher D, and Publisher E.

  • Because the publishing applications are connected to different event broker services, Subscriber A only receives subscribed events from the publisher connected to My-Second-Service.
  • If Subscriber A wanted to receive events sent by Publisher E, it must be connected to My-First-Service as well.

As you can see in the following illustration below that though Subscriber A is interested in events (blue boxes) from Publisher D and Publisher E (orange triangles). Subscriber A  receives the events from Subscriber D (indicated by the green check box), but the event from Publisher E never arrives to Subscriber A. In this scenario, for a subscribing application to receive topics from a publisher, it must be connected to the same event broker service.

Animation that shows when event broker services aren't connected via an event mesh. Only events from Publisher D are received by Subscriber A, BUT events from Publisher E are not.

In comparison to the illustration below, if the applications were connected to event broker services that were configured as an event mesh, Subscriber A could connect to one event broker service, and can receive all subscribed events from the publishing applications that are connected to any event broker service. In this configuration, the event broker services are configured as an event mesh (line between the event broker services). As a result, subscribed events from both Publisher D and Publisher E are received by Subscriber A in a seamless manner.

Animation that shows when event broker services are connected via an event mesh. Events from both Publisher D and Publisher E are now received by Subscriber A.

As you can see in this simple scenario, an event mesh is useful and invaluable to ensure that distributed applications receive events no matter where they are connected. An event mesh takes care of ensuring that the correct events are routed to the event broker services so that they are received by the subscribing applications interested in those events.

For more information about how event meshes work advanced event mesh, see Diving into an Event Mesh and Considerations for Working with Event Meshes .

When you're ready to start using Mesh Manager to create event meshes, see the following sections:

Diving into an Event Mesh

Architecturally, an event mesh is a logical layer that runs on your network to enhance its capabilities to allow distributed applications, microservices, and IoT devices to communicate via the publish/subscribe (pub/sub) communication pattern. This allows for decoupled, dynamic communication in real-time.

At the core of an event mesh is Dynamic Message Routing (DMR) technology. To better understand how event meshes work you should familiarize yourself with DMR terminology and concepts. For more information, see Dynamic Message Routing and DMR Terminology:

  • To create an event mesh using Mesh Manager, you can connect one DMR cluster to another DMR cluster. Mesh Manager creates a full mesh using Dynamic Message Routing (DMR). A full-mesh means that there are DMR external links that span between each DMR cluster in the event mesh. This permits for multi-site scaling. For more information, see Multi-Site Scaling.
  • A DMR cluster can contain one or more event broker services. By default, each event broker service you create in advanced event mesh is its own DMR cluster, but optionally you can configure multiple event broker services to be part of the same DMR cluster by setting the cluster name. For more information, see Setting the Cluster Name.
  • Within a DMR cluster, each event broker service is referred to as a node. If you have multiple event broker services in a DMR cluster, the nodes are connected together via DMR internal links - which is useful for horizontal scaling and best used for event broker services in the same geographical regions. These nodes are interconnected in a full mesh (where each node is connected all other nodes in the cluster). Currently, internal DMR links are configured with the help of SAP and aren't yet configured in Mesh Manager. For more information about horizontal scaling, see Horizontal Scaling.
  • In a DMR cluster, one event broker service (or node), is the gateway node that connects to other gateway nodes in other DMR clusters. These connections are referred to as external DMR links, which is what Mesh Manager automatically configures for you.
  • External DMR links take care of propagating events between DMR clusters, while internal links within the DMR cluster take care of propagating messages between the nodes. For more information, see DMR Subscription Propagation and Data Forwarding.

After an event mesh is created, it takes care of routing events from publishing applications (publishers)  to subscribing applications (consumers) connected to other event broker services in each of the DMR clusters. Whenever a publishing application sends events (or data) to an event broker service, the subscribing applications receive the events based on the matching subscriptions as long as the publishing and subscribing applications are connected to any event broker service on the same event mesh - in other words, they don't need to be the same event broker service. Furthermore, only events (or topics) that are subscribed to are sent to other nodes in the event mesh.

In the following illustration, we have four event broker services, where each is in its own DMR cluster - or a one node DMR cluster. For simplicity, we'll refer to the event broker service names. The single node in the cluster also acts as the gateway node to connect to other DMR clusters. In the example below, the event mesh is a mix of cloud providers including an on-premises Kubernetes deployment and it is configured as a full-mesh.

The event mesh supports the following event- driven architecture:

  • Subscriber A is subscribed to events from Publisher C and Publisher E and connected to My-Second-Service.
    • Because Publisher C is connected to the same event broker service as Subscriber A, events are automatically available to Subscriber A.
    • Because Subscriber A is only connected to My-Second-Service, the event mesh ensures that events from Publisher E ( which is connected to My-First-Service) are propagated to My-Second-Service.
  • Subscriber A is not subscribed for events from Publisher D, therefore no events from My-Fourth-Service are routed to My-Second-Service.
  • Subscriber B is subscribed to events from Publisher C, D, and E, but because none of those publishers are connected to the same event broker service, the event mesh ensures that the events that are sent from My-First-Service, My-Second-Service and My-Fourth-Service to My-Third-Service so that the events are received.

Brief video illustrating the completion of the surrounding steps.

Note that if there was no event mesh (no connections between the event broker services ), then Subscriber A could not get any subscribed events from Publisher C and Subscriber B would not receive subscribed events from Publisher C, E, or D because they are connected to different event broker services.

Event meshes support geographically distributed use cases. If you have event broker services in London, UK and New York, USA, an event mesh would be an easy way to bridge data between to ensure events that are published are received by subscribers no matter where they are connected. For example, when an application in London subscribes to events, that data would automatically start to flow across the event mesh (WAN). Because data is only sent when it's requested or subscribed to, the event mesh uses bandwidth efficiantly. No matter how many consumers in London request the data, that data is sent between event broker services only once.

You can interconnect on-premises and different cloud vendors which gives you a uniform data fabric without having to rely on cloud native services like Google Pub/Sub, or SQS or SNS and AWS. This allows you flexibility to write applications that are agnostic to whether they are on-premises or off-premises.

Considerations for Working with Event Meshes

The following are considerations when you create an event mesh using Mesh Manager in advanced event mesh:

  • You require the following roles assigned to your user account, depending on the tasks you need to do:

    • To view and run Health Checks on an event mesh, your user profile requires the Mission Control Viewer role
    • To view and run Health Checks, and to create, modify, or delete an event mesh, you require the Mission Control Manager role
    • To create, modify, or delete event broker services as part of modifying or creating event meshes, you also require the Mission Control Manager role

    If you require a role assigned to you, contact your advanced event mesh administrator. For more information about the roles, see Roles and Permissions.

  • Mesh Manager always creates a full-mesh of DMR external links between the event broker services in your event mesh. If, at any time, there are less than two event broker service in an event mesh, the event mesh is deleted.

  • An event broker service can be part of only one event mesh. Any event broker services that are part of an event mesh must be Enterprise services; the use of Standard services in an event mesh is not supported in production, but can be used for testing purposes. Event broker services within an event mesh can be mix of broker versions that are supported. If you are using DMR clusters, each node in the DMR cluster can belong to only one mesh. For example, you cannot have one event broker service in the DMR cluster belong to one event mesh and a different event broker service in the DMR cluster belong to another event mesh.

  • Topic subscriptions are securely propagated only to event broker service that have subscribers (consumers) that are interested in the topic to minimize network traffic.

  • You can connect one event broker service that has a private endpoint (private IP addresses) to another event broker service that is configured with public endpoint (public Internet) provided that the initiator is the service with the private endpoint.
  • You can also connect two event broker services using private endpoints (private IP addresses) if the regions have IP connectivity with each other. For Dedicated Region regions, this is performed using VPC peering on GCP, Vnet peering on Azure, and VPC peering or Transit Gateway (controlled availability) on AWS. In Customer-Controlled Region regions, you can do this using any configurations you require, as it is ultimately the responsibility of your organization to configure and maintain the infrastructure.
  • In Mesh Manager, event broker services manually configured using the Broker Manager (legacy mechanism) are not visible in Mesh Manager unless you scan for them. To see them, you must discover the event meshes.

    The use of Broker Manager is for non-typical use cases to configure other type of meshes or advanced settings. This requires in-depth knowledge of the software event brokers. SAP doesn't recommend that you use Broker Manager to modify event meshes created using Mesh Manager. If you require advanced configuration, contact SAP.

    For more information, see Discover New Event Meshes.

Understanding Event Mesh Health

In Mesh Manager, you can validate the health of an event mesh using the Event Mesh Health Check. The status of the event mesh is most useful for people who are administering connectivity between multiple event broker services, because these are often located in different geographical regions. For a Health Check to run, the operational status of a link must be Up. The Health Check uses a customized, secure probe to check the integrity of the links in an event mesh. The probe is an enhanced ping that performs an in-band validation and integrity test to verify that test events and messaging can be exchanged between event broker services; if the operational status of a link isn't up, the Health Check cannot run.

A Health Check validates the following in an event mesh using one secure Solace Message Format (SMF) connection on each event broker service:

  • Link status—To validate connectivity, Health Check pings each direction of the link between two event broker services, and records the time of the probe.
  • Event status—To verify that topics can be subscribed and published to, Health Check uses the Request-Reply pattern and a reserved topic called #insights/pinger/ping. It creates (and later deletes) a temporary client username called mesh-validation-<session-id>, where <session-id> is a string value representing the Health Check session.
  • Connectivity to the Management Port—Connectivity between the Mission Control Agent and each endpoint that has the Management port enabled is validated.

An event mesh is considered unhealthy (or invalid) when at least one link is down or doesn't pass a Health Check. This can occur for a number of reasons that include:

  • at the time, there were no SMF connections available for the test to runs
  • the tests between mesh nodes in either direction failed; tests for both directions must pass for a link to be considered healthys
  • connectivity between the management port and the Mission Control Agent could not be established

After a Health Check completes, you can see the status when you view the details of the event mesh. For more information, see Viewing Information and Details of an Event Mesh.

For information about how to run a Health Check on an event mesh, see Running Event Mesh Health Checks.