You can use ABAP Daemons, to implement event handling in a reliable way. ABAP Daemons are long-living ABAP sessions, which are similar in their capabilities to Linux daemons or Windows services. The application server takes care that once an ABAP Daemon was started, there is no limit for the lifetime of such ABAP session. Even if there is an ABAP runtime error, or a work process in the application server crashes, the ABAP Daemon session gets restarted immediately.
ABAP Daemons have event-driven programming model (similar to ABAP Channels) which contains the typical event handler API for your implementation needs with such methods like on_start, on_message, on_error etc.
You can start an ABAP Daemon and send messages to it. Please consider, that each ABAP Daemon runs under a given user, and therefore the messages to it can be sent only within the same client. If you need to send the system-wide messages to your ABAP Daemon you can use ABAP Messaging Channel (AMC).
ABAP Daemons are available with SAP NetWeaver AS ABAP 7.52. The startup configuration was added to ABAP Daemons in ABAP platform 1809.
New in ABAP Platform 1809: Bootstrapping of ABAP Daemons by application server
The situation with ABAP Daemons has been so far, that though the application server keeps its ABAP Daemons alive, they still must be started by an ABAP application or transaction. The consequence is, that if the ABAP application, which started the ABAP Daemon, goes down, the ABAP Daemon goes down as well, what is actually not expected. To overcome this problem, the new feature was added to ABAP Daemons in ABAP platform 1809, which allows to persist the start-up configuration of ABAP Daemons in the database.
Each start-up configuration entry specifies for a daemon application how many ABAP Daemons instances should be started in the ABAP system and on which application servers and under which user.
In this way an ABAP system takes care of starting of ABAP Daemons. As soon as an application server get started, it checks which ABAP Daemons should run and starts them. If the application server goes down or at its failure, the ABAP system checks if the ABAP Daemons should be started on other application servers and restarts them.
The main use case is handling events. For example, you can use ABAP Daemon as an event scheduler in Industrial IoT (Internet of Things) scenarios. Just imagine if multiple sensors are connected to the ABAP system, the ABAP server receives too many incoming messages. These messages cannot be processed concurrently, but it is possible to queue them by starting an ABAP Daemon session and sending messages to it. This central scheduling ABAP Daemon session will be always available for event processing.
You can also use ABAP Daemons for lightweight background activities like e.g. tracing, logging, clean-up of resources, synchronization of caches. The advantage is, that the logging, tracing etc. messages are sent to the ABAP Daemon without DB commit using ABAP Messaging Channel (AMC), therefore sending event to the ABAP Daemon will not break your LUW (Logical Unit of Work).
You can also use ABAP Daemons for very frequent periodic tasks e.g. like health checks. The advantage is that you do not need to create a new ABAP session for each task execution and no background work process is needed. For heavyweight periodic tasks, that run at most once a day, we recommend using batch jobs.
You can use ABAP Daemon also as a proxy session for external communication like e.g. messaging proxy in MQTT scenarios (see also MQTT client in ABAP Platform 1809 blog). For example, you can connect an ABAP Daemon session to the UI via ABAP Push Channel (WebSocket), and to the MQTT broker via the MQTT connection and exchange messages between UI and MQTT broker.