Table of Contents

  1. Table of Contents
  2. Quick Introduction to AEM
  3. AEM Terminology
  4. Components and Assets to work with
  5. Piecing the components together
  6. Understanding the APIs in context of AEM
  7. Why REST? For now…

Quick Introduction to AEM

Based on EDA (Event Driven Architecture), SAP AEM is Advanced event mesh for SAP Integration Suite is a complete event streaming, event management, and monitoring platform that incorporates best practices, expertise, and technology for event-driven architecture (EDA) on a single platform.

Simplest way to visualize AEM is through below exmaple:

Imagine each department in the company has its own messenger. When one department wants to send a message to another, it gives the message to its messenger. This messenger doesn’t go directly to the other department, but instead, they go to a central meeting point where all messengers gather. Here, the messenger finds the messenger from the intended department and passes the message to them. This way, messages are efficiently exchanged between different parts of the company without each department having to directly communicate with every other department. This system keeps communication organized and ensures that messages reach the right place quickly and accurately.

Here each department is a “system” within a company.

A message is, well a message. Or an “Event”

Each messenger is a “broker”.

Central Meeting point is the “Event Mesh”, which will be decide the next rout for this message.

Before we dive in, I have “warm up blog” for “SAP AEM”, do go through it first, here is the link below:

/posts/sap-advanced-event-mesh-aem-the-crux0-initial-set-up/

Objective here…

To get familiar with terms used in terminology so that upcoming texts are easier to navigate and visualize as and when we use it.

AEM Terminology

Broker - A piece of software which connects two applications and paves way to exchange information.

Service - In context of EAM this is an Infrastucture where the broker is hosted.

Message VPN - A message VPN is an object on the broker which you can use to segregate different publishers and subscribers allowed to communicate for the particular event(s).

Mesh - A group of service(s), in turn a group of broker(s).

Event - Any describable change in state or underlying information of a business entity.

Pub - Short for Publish

Sub - Short for Subscribe

Subscription - placeholder to hold a specific category of events described the the underlying path.

Queue - A group of subscription(s).

Client - Any application being used to publish or subscribe an event.

REST Delivery Point (RDP) - An asset in AEM which holds configuration details to connect to a client.

Queue binding - an Asset which connects a queue to its consumer.

Owner - The initiator of action on an RDP i.e publish or subscribe

Components and Assets to work with

In AEM, an overall event lifecycle follows and touches upon certain components.

Whenever an entitiy (in our case we will touch upon Sales Order) gets created or gets changed, an event is created which is published on the broker. On the broker this information is published on a topic or a queue. Depending on what a queue’s subscriptions are, it will be publishing the information to all the consumers who are listening to this queue.

How does a consumer receive this event?

Each consumer application is represented by an RDP which contains the host, port, authorization configuration needed to connect to this application. You maintain a Consumer asset to configure the connection:

This RDP also contains a configuration called “queue binding” which is another asset to map a queue to a consumer. An RDP can have mulitple bindings.

We will use this resource path in our HTTP endpoint, as we will demo in next blog.

So once an event is published to a queue, this travels to this endpoint immediately and is updated on to the downstream applications.

Piecing the components together

Below is a typical lifecycle stages of an event mapped through each component we will work with (as demo’d in next blog).

  1. An entity is created or changed in an application (lets say its an ERP applcation), it triggers an event.
  2. This event is sent to a broker service.
  3. This broker service will look for a topic (here a queue) to publish this event to e.g. Sales Order Creation or Change.
  4. There will be an RDP client pointing to a consumer (in our demo its Integration Suite iFlow) endpoint.
  5. In RDP configuration, the queue is bound to this consumer endpoint.
  6. This way an event makes way from broker to the consumer application.
  7. The consumer application can have an interface or workflow which is triggered as soon as it receives the event.

Here is a general landscape for publishing and subscribing.

Understanding the APIs in context of AEM

APIs are just a point to interface with an application. However, how you get to consume certain objects also depends on the library, language or protocol you might be using to allow the events to get published on your APIs or applications.

You can have a configuration written in Java, python or in Go etc or you might be using a REST architecture, or MQTT protocol or AMQP set up to listen to the queues.

Based on capabilities of your application, AEM provides you documentation and configuration details which you can use in your application to consume an event.

Why REST? For now…

You might get a Solace adapter for integration suite next year which uses Solace Messaging Format on SMF protocol which will contain a lot of available options for you to configure e.g. Host, port, Topic endpoint, queue, dead letter queue configuration, consumer mode (Guranteed/Direct) and few others:

When delivering the events from IS to AEM, you will get below options, where a whole lot of settings are available. You can have dynamcially populate certain parameters based on your design to create a dynamic topic destination.

However, in the interest of universality of implementation of EDM we will use REST architecture for now. With available Adapters in IS I find implementation using REST very simple to understand the workings of AEM, eventually you can use AMQP or MQTT depending the license or the objective you have in mind.

For REST we will use protocol block to select REST configuration which we will use in our REST connection in Integration suite to publish events.

So we will use HTTP adapter to expose our REST endpoints where AEM will publish the events and similarly we will use Solace REST details to publish the event to a non-subscribed queue.

Do share any comment or feedback, if any.

Note: As I have written and explained most of the concept in the way I understand them and worked for me, feel free to builld your own framework of understanding differnt topics.

Thank you and I will see you in next blog.