SAP : let the daemons in

A frequent need for our customers is to be able to trigger processing when creating or modifying database or transactional data.
 

A classic solution is to activate the "change pointers" and then either consume them in a standard way via IDOCs or via specific programs. The latter must then be planned at a more or less frequent frequency with the consequence of consuming background processes and being asynchronous.

ABAP Daemon Framework

Among the new features in SAP Netweaver 7.52 is the ABAP Daemon Framework or ADF. The ADF is an API that allows you to create and manage daemons in ABAP.
 

An ABAP daemon is a class that will be able to run in a special "ABAP Daemon" session on the application server. Access to the daemons of an application server is to be done via the ABAP Daemon manager.
 

The ABAP daemon runs on event and therefore must always be able to respond and therefore run in'non-blocking mode'. This will have an impact on the processing you want the daemon to perform, forget about CALL TRANSACTION and other SUBMIT.
 

How does it work?
 

The creation of a daemon consists in the creation of a class that will inherit the abstract class CL_ABAP_DAEMON_EXT_BASE.

From this super class, our daemon will inherit different methods from the IF_ABAP_DAEMON_EXTENSION interface that will allow us to respond to different events.

We will not go into the details of the events here, they are clearly explained in the standard documentation on ABAP daemons.
 

For this simple example, we will only implement the methods ON_ACCEPT and ON_MESSAGE.
 

The first one will allow us to allow the daemon to be created on the system and the second one to process the messages that we will send to the daemon.

It is a simplified implementation of singleton to avoid running the same daemon several times.
 

Before setting up the processing of messages sent to the daemon, we must take into account the fact that only the program that runs the daemon can then use this daemon via the manager daemon. The idea is to have the daemon created via the daemon class itself.
 

We will therefore create 3 methods in the class: START, SEND and STOP to manage the daemon.
 

We can now launch our daemon via a second program by running:
 

zmydaemon=>start( iv_daemon_name = "my_first_daemon').
 

The tracking of daemons is done via the SMDAEMON transaction.
 

Our daemon runs on the application server and waits to receive events.
 

To test this daemon, we implemented a BADI to backup the creation of PM equipment to notify a user of this creation.
 

We have created a specific function that sends an email with the created equipment number.
 

Then, we implement the ON_MESSAGE method to receive the equipment number and switch it to the mail sending function.

An update of the BADI is required to call the SEND method defined above:
 

DATA: lv_text TYPE string.

lv_text = i_data_equi-itob-equnr .

zmydaemon=>send( iv_daemon_name = 'my_first_daemon' iv_text = lv_text ).

When the equipment is created, the email is generated and sent to the user.
 

To go further

These ABAP daemons offer new possibilities to the SAP S4/HANA backend.
 

There is a lot of talk about Enterprise 4.0 and Smart Enterprise, this new technical brick proposed by SAP, combined with ABAP Push Channel, allows any kind of Machine-to-Machine communication:
 

• sensor feedback directly into the ERP

• connection to MTTQ brokers

• connection to web sockets
   

It also allows, as we have seen, the implementation of real-time processing in the ERP.