Skip to Content
Technical Articles
Author's profile photo Yogananda Muthaiah

SAP Event Mesh – What Is Publish-Consume Messaging Queue Pattern?


In this blog, we’ll look at the use of message queues and publish/consume. These are common patterns used in distributed applications how services communicate with one another.

What Is Publish-consume?

Publish-consume is a communication pattern that is defined by the decoupling of applications, where applications publish messages to an intermediary broker rather than communicating directly with consumers (as in point-to-point).

In this sense, publishers and consumers have no knowledge of each other; they simply produce or receive the events. The event broker (in the form of middle-ware like CAP/RAP, Integration Suite, or S/4 – deployed in any and all environments) is a product that facilitates and distributes events as they occur, pushing them to consumers which can be located in a variety of environments (on-premises, public/private clouds, etc.).

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

Achieve reliable data transmission for extension and integration scenarios through decoupled communication.

What Are Message Queues?

Let’s start by looking at message queues. Message queues consist of a publishing service and multiple consumer services that communicate via a queue. This communication is typically one way where the publisher will issue commands to the consumers. The publishing service will typically put a message on a queue or exchange and a single consumer service will consume this message and perform an action based on this.1-1

From this, we can see a Publisher service that is putting a message ‘m n+1′ onto the queue. In addition, we can also see multiple messages already in existence on the queue waiting to be consumed. On the right-hand side, we have 2 consuming services ‘A’ and ‘B’ that is listening to the queue for messages.

m1 = message 1 , m2 = message 2, m3 = message 32-1

First, we can see that the Publisher’s message has been pushed to the tail of the queue. Next, the important part to consider is the right-hand side of the image. We can see that consumer ‘A’ has read the message ‘m 1′ and, as such, it is no longer available in the queue for the other service ‘B’ to consume.

It works like FIFO (First-In-First-Out)

Examples of situations where you might use FIFO queues include the following:

  • E-commerce order management system where order is critical
  • Integrating with a third-party systems where events need to be processed in order
  • Processing user-entered inputs in the order entered
  • Communications and networking – Sending and receiving data and information in the same order
  • Computer systems – Making sure that user-entered commands are run in the right order
  • Educational institutes – Preventing a student from enrolling in a course before registering for an account
  • Online ticketing system – Where tickets are distributed on a first come first serve basis

Let’s experiment a little to have a better understanding.


Go to Event Mesh Dashboard, Create your own Queue name
Click on Actions for additional details for your Queue created

View Queue Details shows required information for messaging

Test Publishing or Consuming Messages

If you want to publish a messages to a queue or consume messages from a queue.

  • Choose the queue and then the required message client.
  • Choose Publish Message or Consume Message and then choose OK.

A confirmation is shown when you publish a message.

The message data and message properties are shown when you consume a message.


Watch out for step by step sending message from Queue

Let’s do it through REST APIs for Messaging

The service supports the use of REST APIs for publishing and consuming messages. Message client applications with REST-based messaging can implement the messaging functionality using a REST client tool.

Quality of Service (QoS)

The allowed values for specifying QoS are 0 and 1. The API for publishing messages requires a mandatory header x-qos.

Time to Live

With every publish request, the message client can set a time to live for the message in milliseconds. If the API is called without this header, the default value of 2592000000 (30 days) is used.

Technical Constraints

SAP Event Mesh Default Plan Technical Constraints

Event Mesh API Documentation

Specification for messaging REST APIs

Syntax for Naming Queues, Topics, and Topic Patterns

Assigned Tags

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

      Thanks for posting this document with a very detailed explanation and examples.

      Author's profile photo Yogananda Muthaiah
      Yogananda Muthaiah
      Blog Post Author

      Thank youSatheesh Gopalsamy !

      Author's profile photo ebsor ---
      ebsor ---

      Thanks for post, what is difference between queue and topic . Here you are showing queue can have multiple consumers is it not only topics can have multiple consumer? what is difference between these two in context of event mesh/Advance event mesh?