Click on Actions for additional details for your Queue created
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.
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 3
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.
Queues
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
- SAP Managed Tags:
3 Comments
