ABAP are you listening? Apache ActiveMQ is calling
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.
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.
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.
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.
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.
The definition of brokers and daemons are made in the abapMQ Monitor (Transaction ZAMQ_DAEMON_MONITOR)
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.
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
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:
Thanks for the blog Uwe Fetzer ! Perhaps a good idea to also refer to the SAP standard MQTT and AMQP clients, seems that these are available as of the higher releases.
Without having tested the solution, I was wondering the following:
- Would SAP standard clients be an alternative to Lars his custom clients, for using your solution? Which do you advise, any difference in functionality?
- How do ABAP Daemons relate to your ABAPMQDaemon?
that's exactly the problem. The standard MQTT client and the ABAP Daemon Framework are availably only with releases >= 7.52 and we will not have S/4 in the near future.
But I'm already thinking of a version 2.0 of my abapMQ Daemon components with basis 7.54 with the help of the ABAP Developer Edition 1909. Needs time though, not in the next months.
The ABAP Daemon Framework (ADF) I just discovered yesterday (with a hint on Twitter) and haven't time to play around yet.
great blog, I learnt quite a lot from it and also by looking through the git repo's!
One question I am stumbling upon quite often in the last months is how authentication from cloud is done properly with ECC or HANA.
Is it actually allowed to use a system user for that (what if a SAP document is created / changed from event)? I always get told that this is "indirect use" and forbidden by SAP. Do you have any experience regarding that?
good news for you: in this scenario "the cloud" doesn't know and doesn't need any SAP user data, it isn't calling SAP but just raising an event on which SAP is listening and reacting. If SAP now is creating a document because of the event, it is direct usage and can/must be licensed accordingly.
In the new version of the abapMQ Daemons the user who will process the message will be entered on the Deamon data screen (below the handler class) so every Daemon can use a separate (System) user if you want.