Develop Advanced Extensions with SAP Cloud SDK

SAP S/4HANA Cloud Event-driven Extension Apps

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Describe SAP S/4HANA Cloud event-driven extension apps

Event-Driven Architectures and Events in SAP S/4HANA

Different approaches exist for how systems communicate with each other. In previous lessons, we mostly considered direct communication using API calls. In some scenarios, direct communication could lead to tight coupling and unwanted dependencies at runtime. Therefore, communicating through messages or events can be desirable in some contexts. We also learned about Hystrix commands in previous lessons, which in addition to improving resilience can also serve to achieve asynchronous and reactive programming by wrapping API calls accordingly. However, we will now learn the theory and concepts behind message-based interaction and get to know how to achieve event-based integration between SAP S/4HANA Cloud and applications on the SAP Business Technology Platform (BTP).

Event-based integration expands the set of approaches available to us for designing a modern application architecture.

Challenges in Developing Extensions

Side-by-side extensions run in highly distributed and heterogenic environments as they interact with SAP S/4HANA systems and possibly other dependencies that run in different environments. This situation results in new challenges for the development of the extensions. As such, an extension is a system of distributed components. If an extension app can react immediately to the user requests, it would become more meaningful and appealing. To keep the extension responsive, we must cater to all situations, especially situations when any component might fail. Therefore, we need all components to be responsive when they run into errors and when they run under high loads.

Messaging Between Reactive Systems

Reactive systems are defined as responsive, resilient, elastic, and message-driven. Under the hood, a reactive system relies on interactions using asynchronous message-passing that establishes boundaries among individual components. Reactive systems require a different approach to the architecture of distributed systems and offer distinct benefits to make systems responsive.

The key element of reactive systems is the asynchronous message-driven communication between systems, as shown in figure, Messaging Between Reactive Systems. Regardless of their location, reactive systems communicate in the same way with each other - using messaging, which allows loose coupling, efficient resource usage, and isolation between systems. Using messaging, reactive systems notify supervisor components about failures without blocking the process so that another component can take over the role of a failed system.

The advantage that we get from such reactive systems is that we can avoid too many API calls to the system that owns the data. The system that runs the core business applications actively informs the potentially interested consuming applications on the SAP BTP when changes happen. Knowing that a change happened, the consumer application can use the relevant API to fetch the new or changed business data.

Key Building Blocks of Messaging in SAP BTP

Now, let us explore the core components of SAP BTP and SAP S/4HANA that make the described architecture possible.

On the left-hand-side of the following figure, Key Building Blocks of Messaging in SAP S/4HANA and SAP BTP, we see the components of SAP S/4HANA that enable message-based communication. In SAP S/4HANA, business objects (BOs) are the basis for Event Enablement. BOs are well-defined in the context of the SAP Business Suite and in SAP S/4HANA Cloud. A BO is a piece of business functionality that can be instantiated on its own, for example, sales order, business partner, or cost center, just to name a few.

In SAP S/4HANA, an event can be raised when a certain action is executed for the BO, or when a certain state of the BO has been reached. The event is propagated from the application to the Enterprise Event Enablement component of SAP S/4HANA that communicates directly with the responsible components in SAP BTP. On the right-hand side of the high-level component diagram in this figure, we see SAP BTP components that allow consumption of messages. The SAP BTP Enterprise Messaging service facilitates messaging capabilities in a robust, efficient, and scalable broker architecture.

It includes an out-of-the-box integration with SAP applications such as SAP S/4HANA Cloud to propagate events and enable reactive business processes across enterprise landscapes. With the first version of the SAP BTP Enterprise Messaging service, SAP S/4HANA Cloud and the SAP BTP can act both as event sources to the SAP BTP Enterprise Messaging service. Applications built on the SAP BTP can act as consumers.

Finally, let us consider how the connection between the described SAP S/4HANA and SAP BTP components works. SAP Event Enablement communicates directly with the respective instance of the SAP BTP Enterprise Messaging service on the SAP BTP using a WebSocket connection.

Events are transported as the payload of Message Queue Telemetry Transport (MQTT) messages, and is a standardized protocol widely used in the Internet of Things.

Note
Each connection between an SAP S/4HANA and an SAP BTP component is represented by a channel, which defines the types of messages that will be sent for this connection, for example, only changes in business partner master data, creation of products, or changes in all BOs in SAP S/4HANA.

Topic and Channel

In the high-level diagram in the previous figure, Key Building Blocks of Messaging in SAP S/4HANA and SAP BTP, we have seen communication between SAP S/4HANA and SAP BTP components through messages that happens using channels. Now, we define the concept of channels using the concept of events.

The receiver shall be enabled to recognize the semantic and the relevance of a specific event by looking at the metadata of an event. Therefore, it is beneficial to use a unified and well-defined hierarchy for event types as well as for the payload of events.

The events that are sent from SAP S/4HANA are grouped into topics. Topics identify event types. Topics organize event messages on the messaging infrastructure and are used for dispatching messages at runtime.

In the customizing, you can bind topics to channels to identify which messages should be received by a concrete instance of SAP BTP Enterprise Messaging.

A channel is a single connection for events between an SAP S/4HANA Cloud system and a service instance of the SAP BTP Enterprise Messaging service on an SAP BTP account.

Channel Attributes

Let us now examine the channel attributes.

The various channel attributes are as follows:

  • Channel Name: Identifier that identifies the name of the channel.
  • Indicator for Activation: Identifies if the channel is active. It is important to note that an event can be sent using an active channel.
  • Channel Destination: The name of the destination that is targeting the messaging endpoint of the SAP BTP Enterprise Messaging service.
  • Channel Protocol: The messaging protocol, as we saw previously, the channel protocol we use is MQTT.
  • Channel Topic Space: Identifies the source system of an event type.

Event Topics in SAP S/4HANA: Structure and Examples

To allow a stable configuration of business applications, SAP BTP Enterprise Messaging service and Enterprise Event Enablement in SAP S/4HANA Cloud use a unified topic syntax for the transmission of events. Each event is assigned to exactly one topic. Topics form a logical tree to organize messages, like a folder hierarchy in a file system. Topics are technically represented as strings, consisting of multiple segments, separated by one defined delimiter, like file paths. In SAP S/4HANA Cloud, event topics are composed in the format, channel topic space/service topic space/specific topic.

The individual parts are defined as follows:

  • As we discussed previously, the channel topic space identifies the source system of an event type, for example S4H would represent an SAP S/4HANA Cloud system with the system ID S4H.

  • The service topic space identifies the provider implementation inside an event source system. For example, a provider for business events in SAP S/4HANA could use the value BOs to represent the BO events. A provider for technical events inside SAP S/4HANA Cloud could choose the value TECH.

  • The specific topic identifies the event type. In in SAP S/4HANA Cloud, the event type mostly contains the respective object type to which the event belongs. For example, the object SalesOrder can raise the Created Event type, which would be expressed as SalesOrder Created in the last part of the topic.

Some more examples of the channel bindings that can be possible with BO events include the following:

  • All Sales Order events are bound to the channel and a specific business partner type
    • /BO/BusinessPartner/Created
    • /BO/SalesOrder/*
  • All events are bound to the channel
    • /BO/*

Save progress to your learning plan by logging in or creating an account