Advanced Event Mesh as a very capable event broker, has many features that are mentioned in various articles and blogs. One of these features that Advanced Event Mesh offers is various connectivity options for messaging, including APIs for Java, C, .NET, iOS, node.js, Python, and support for protocols such as AMQP, JMS, MQTT, REST, and WebSocket.

This gives you the flexibility to connect-publish/consume from almost any environment that your developers / applications are capable of.

Figure 1- Some of Advanced Event Mesh Connectivity Options

As being widely used and easily implemented, REST is an architectural style that uses standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources via client server model. (API based approach for instance)

On the other hand Advanced EventMesh also enables you for the pub-sub pattern where publishers send messages to a centralized message broker and in the end to a set of subscribers which are loosely coupled.  This enables you for the opportunities where you can combine sync and async scenarios.

In theory, once you receive the message to the Advanced EventMesh with various ways, you can process it in the broker and publish to diffent consumers with various options very flexibly.

In this blog post, I will demonstrate with a scenario how “easily” you can publish and receive events (messages) through REST and use the advantages of event driven architecture to get rid of some “disadvantages” of sync scenarios.

Imagine that you have procure to pay scenarios in your system (SAP/other ERP System, or 3rd party purchasing application) where you want to publish purchase order requests to the systems very flexibly. As the subscribers (in this case suppliers) these systems are only interested in certain categories, or they are from different countries therefore want to be notified about the purchase orders from their region.

We will be having two suppliers:

• Supplier 1 will be a worldwide supplier who is interested in only certain categories of purchase requisitons (in this case office equipment and electronics)
• Supplier 2 is our supplier for only German and Turkish region but interested in purchase requisitons in any category.

• They have applications with REST endpoints and wanted to be notified whenever a purchase requisiton is generated in our system(if they are interested).

In our purchasing system, we also want to be flexible, therefore we want to publish this information via REST.

Figure 2- High Level System Design

Let’s make the configurations

• Create queues for 2 suppliers so that they receive the messages.(purchase requisiton data). The queues will also be a temporary storage for the messages if the message cannot be delivered to the consumer applications for some reason. (application down, network issue)
• Configure subscriptions for the queues (consumers) so that they only get the messages (requisitions) that they are interested.
• Configure REST Delivery Points so that Advanced Event Mesh pushes the message to the consumer application once it’s received.

Imagine that I will need a copy of each purchase requisition for audit purposes, therefore I will also configure a queue for this purpose receiving all messages, holding information about each purchase req. that my purchasing application publishes.

Figure 3- Queues created

Audit queue will receive every purchase requisition, first application will receive electronics and officeequipment categories, second application will receive messages for DE and TR countries.

Figure 4,5,6- subscriptions for the queues

Now our queues are ready to be filled with the specific messages that we publish. How do we do that? Publishing to certain topics and dynamically. So how?

With the REST based endpoints that Advanced Event Mesh provides, it’s as easy as to make an http call. I will demostrate it from Postman.

I design my topic structure very simply as below (like I used in queue subscriptions above)

po/{{category}}/{{country}}

I want to publish my first po to

po/officeequipment/tr topic

so the first message will go to both supplier1 and supplier 2 queues based on our subscriptions. (and also to the audit queue which is interested in everything)

So what would be my request and the Http/REST Endpoint.

Where do you get this information from?

Navigate to the main page of your event broker service via Cluster Manager > <YOUR SERVICE>

Under the Connect tab you have the information for various connectivity options with the users.

Figure 7- REST Messaging URL / User-Password

Just add your topic at the end of the Secured REST Host, use the username and password provided(Basic Authentication).

Publishing first message to AEM via REST

And that’s it, you have published the event/message to the broker. The “rest” is handled by “Advanced Event Mesh” and now you have one message in each queue ready for consumption.

Figure 8- The message is received by all queues

Lets publish another one, in this case for only TR region, but with an unknown category, and expect our first supplier not to receive this event as it’s not interested.

The topic we’ll publish would be in this case po/uncategorized/tr

Figure 9- Queues after the second message

Voila! It’s in our audit queue and also supplier 2 has received the information because of the subscription.

Alternatively we can even do these requests via CURL just replace the URL and AUTH_STRING below.

curl --location '<URL_AND_PORT_OF_AEM>/po/uncategorized/tr' 
--header 'Content-Type: application/json' 
--header 'Authorization: Basic <AUTH_STRING>' 
--data '{
"MaterialCode": "50003",
"MatName": "Fax Machine New",
"Quantity": "1"
}'

Now that we have received multiple messages, let’s notify the consumers. In our simple example, our subscribers are also providing us REST based end-point to be called one the event broker receives the message. (Webhook).

For this we need to configure a RDP (Rest Delivery Point)

Then bind it to a queue with queue binding

And finally create a Rest consumer as shown in the following images.

Figure 10,11- Rest Delivery Point(RDP)Definition

Figure 12,13- Queue Binding

Figure 14- REST Consumer

For simplicity, I have mocked supplier 1 with an endpoint from https://webhook.site web site.

Figure 15-The message in the Webhook.site

I also have an REST API for simulating Supplier 2. Therefore doing the similar steps for second RDP.

And the final result for RDP 2 is like below.

Figure 16-RDP for Supplier 2

After creation of the queues and assigning queue subscriptions, what I did was simply assigning REST based consumers for my queues so that the messages are pushed to these endpoints if they are active.

For demonstration, I have a created an application UI to show the received messages (purchase order requests) as supplier 2.

Figure 17- Application waiting for new messages

I published two more requests to Advanced Event Mesh REST API and through the queues subscribed to these topics, my application(consumer) received these last two messages.

Figure 18- Application received the last two messages

Until that point our use-case worked like a synchronous scenario.

Let’s create some complications in the scenario:

What if my second supplier’s consumer application is down for some reason for some time and I publish new purchase requisitions that they are interested just at this time.

In a regular (sync) API based scenario, they lose the opportunity to receive the messages/data because they are not available there at the time. With the help of Advanced Event Mesh, without even doing much, they will  get the message once they are up-and-running.

This is because the message will be retried (configurable) within intervals, and once the application is up, it will receive the message and the message will be acknowledged, deleted from the queue after that.

This is a way of guaranteed delivery. Of course it shouldn’t be tried forever therefore Advanced Event Mesh Event Broker has also other capabilities like “Dead Message Queue”ing with other features on top, usable depending on your scenario & design. (Which I might mention in the following blogs)

For a period of time, supplier 2 application was down and 2 messages are published, and the application receives and consumes the messages once it’s up again.

Figure 19-App Down

Figure 20– Queues when the application is still down

Figure21- Received and consumed the messages from the queue once it is up and running

This is a very simple demonstration of how to combine the usage of REST-Advanced Event Mesh’s capabilities for Pub-Sub and Async Approach.

And a little bonus: 

Imagine that we also want to publish the purchase requisitions to a supplier marketplace application that we register later on. They do not provide the REST APIs but they have a Java based application to pull the messages from us whenever it is published. What do we need to do for enabling this use-case?

Two things (except the authentication&authorization)

• Create a queue for them
• Create a subscription for the queue as po/> indicating that they are interested in everything.

That’s all you need to do from Advanced Event Mesh side.

• Then ask them to use their application to consume the messages (may be this time through) AMQP Protocol.

And you are now publishing the messages to your supplier marketplace as well providing the flexibility to connect via multiple options of their choice.. That easy as like this !!

Advanced Event Mesh is also utilizing REST APIs for management, configuration as well, which I will write about in the following posts..