Concept of Event/Message flow and configuration details of Queue and Webhook in Event Mesh
Introduction: This blog explains the concept of Event and Message flow and how to create a Queue and Webhook in Event Mesh as per your requirement.
Producer or Publisher sends event to Topic
Event or Message will be sent to Topic and then it will be sent to Queue
Producer or Publisher sends event to Queue
Event or Message will be sent to Queue.
From Queue, there are two ways to consume event or message.
- Push Based Model->Event or Message would be pushed to Consumer or Receiver System via webhook.
- Pull based Model->Event or Message would be pulled from queue by Consumer or Receiver System via REST based Api.
If the message client calls with QoS 1, then, the service needs an acknowledgment request from the message client with the message-id. The message is deleted from the queue only after the acknowledgment is consumed. When QoS 0 is used, the message is deleted from the queue without an acknowledgment from the client.
Let’s understand the parameters used to create Queue.
Queue name can be anything as per your naming conventions.
Access Type: Exclusive/ Non-Exclusive
Exclusive: If more then one consumers are connected to the same queue, then message will always go to the first consumer, if first consumer is not available then it will go to next consumer
Non-exclusive: If more then one consumers are connected to the same queue, then messages will be delivered to all consumers in round robin way
Max Queue size and Max Message size comes by default, you can reduce it if required.
Max Unacknowledged Messages per Consumer:
We can set a number for unacknowledged messages due to connectivity issue
If the unacknowledged message limit has reached, then the new messages can only be delivered after the successful delivery of unacknowledged messages.
Set the value 1 to maintain sequence.
Max Redelivery Count:
Default and Min Value is 0 and max value is 255
It is optional but required to set if we are setting dead message queue for the main queue. If the delivery count limit is reached, then message would be considered dead.
Dead Message Queue:
To store dead messages
Respect time to live:
A lifetime can be set for a message, if the message is not delivered with in the defined time, then it would be expired and move to Dead message queue.
If event or message will come from Topic to Queue then after Queue needs to be subscribed to Topic after creation.
A Queue can be subscribed from REST Api as well, click here to know more about APIs
Let’s talk about the Webhook
Webhook subscription can also be done via REST Api, click here to check details.
|Subscription Name||Any name|
|Queue Name||Select any queue name|
|Quality of Service||
0-Ack is not required for delivery
1- Ack is required
Set 1 for retry, in case of delivery failure
|Webhook URL||Only HTTPS|
|Default content type||Optional|
|Authentication||Basic or OAuth or NoAuth|
Click here to enable S/4HANA public cloud events with Event Mesh