Event Driven Architecture
As an ABAP developer you know this architecture model since decades: a business object raises an event (CREATED, STATUS_CHANGED,…) and (maybe) one or more workflows are listening to this event and will do what they are proposed to do, hopefully.
But: this is only possible within the same system. If you want the same scenario across system borders, you have to implement a message broker / message queue which will handle the events.
Event Mesh
In the SAP world this is called “SAP Event Mesh” (formerly known as “SAP Cloud Platform Enterprise Messaging”).
- Event Mesh community
- How to leverage the SAP Event Mesh from SAP BTP, ABAP Environment
- Event-driven architecture – now available for SAP ECC users
Unfortunately, but not surprisingly, you need the additional “Enterprise Messaging License” and you have to be an SAP Business Technology Platform customer. Not every customer has done this step yet.
ActiveMQ
If you look at the market, there are plenty of other message brokers available. One of the most popular ones is the open source solution “Apache ActiveMQ” wich is also used for example by “Amazon MQ”
The target scenario for a cross border event driven scenario would look like this:
You can use “ActiveMQ” either as a standalone solution, use “Amazon MQ” or install the software in a Docker container which is perfect also for testing.
abapMQ Daemons
On the listener side you need a component which can subscribe to an event at ActiveMQ and can process the incoming messages. For this usage I’ve written the open source software “abapMQ Daemons” which now has reached alpha state and can be tested. The package is using “abapMQ” , the ABAP MQTT client by Lars Hvam Petersen.
Setup
In this demo scenario I’ve installed ActiveMQ as Docker container with no further customizing (just install from Docker hub and run the image with open ports 8161 [Admin Interface and REST API] and 1883 [MQTT], ). For abapMQ and abapMQ Daemons I’m using the SAP ABAP Platform 1909, Developer Edition but you can use every system based on >= NW 7.50.
abapMQ Monitor
The definition of brokers and daemons are made in the abapMQ Monitor (Transaction ZAMQ_DAEMON_MONITOR)
Broker
Create new broker, use the IP of the “ActiveMQ” docker container, and the port of the MQTT listener, usually port 1883.
Customer Handler Class
The final message processing will take place in your customer handler class. For a first test you can copy the delivered class ZCL_AMQ_DAEMON_DEMO, adjust it if you like and activate the class. If you create new handler classes in the future, you have to implement the interface ZIF_AMQ_DAEMON.
Daemon
In the Daemon Monitor you can now define a first daemon. Enter the earlier created broker (use value help <F4>), a proper daemon name, one or more events (topics) you want to listen to (separated by comma) and your handler class name (use value help <F4>). Leave the stop message at the default value ‘STOP’.
Select the new created deamon and press the “Toggle” button. You will be asked for the “ActiveMQ” user and password (admin/admin by default). The indicator should turn green now.
In your browser call the ActiceMQ Admin Interface http://<IP of your Docker host>:8161/admin/ and choose “topics”
For each of the entered daemon topics you should see an entry with an active consumer.
Sending a message
For simulating an event we are using the REST interface of ActiveMQ. I’m using Postman here but you can use your tool of choice.
POST http://<IP of your Docker host>:8161/api/message/abap.mq?type=topic
Basic auth with User/Password (admin/admin by default)
Enter a message you want to send and press “Send”
Refresh your ActiveMQ Admin Interface. You should see a new message enqueued (message received from postman) and a message dequeued (received by the consumer).
Really? Let’s check:
In the demo handler class we simply have placed a message in the application log to see whether the message is properly received and processed. Call transaction SLG1 and check:
Looks good 
Deactivating the daemon
In the Daemon Monitor, deactivate the running daemon by toggling the state. The Monitor will send the “STOP” message to the broker, the daemon will receive this message and will cancel the subscription to the topics.
The enqueued and dequeued message count increased by one (the “STOP” message) and the number of consumers is now zero.
What happens inside the “abapMQ Daemon” components?
Currently this project is a proof of concept and in alpha state. It needs testing and enhancements. I’ve already opened some “to-do” issues in the repository, feel free to assign yourself 
Summary of used components
EDIT
abapMQ Daemons are also working with Eclipse Mosquitto as Broker
Hint for the Docker container: the config file “/mosquitto/config/mosquitto.conf” has to contain the following lines to accept inbound MQTT calls on port 1883 and test without user configuration:
listener 1883
allow_anonymous true
