ADF - ABAP Daemon Framework
ABAP Daemon Framework (ADF for short) is an application programming interface (or API) used to create and handle ABAP Daemons. An ABAP Daemon is an instance of an ABAP Daemon class that is persisted in a special ABAP Daemon session. Every AS Instance in an AS ABAP has access to any of the daemons in this AS ABAP. ABAP programs themselves use ABAP Daemon Manager to access ABAP Daemons.
The only limit on the lifetime of an ABAP Daemon not stopped explicitly using ADF methods is the lifetime of the AS Instance where it is running. An ABAP Daemon is created again automatically every time a runtime error or a message of type E, A, or X causes it to terminate a program. When the AS Instance of a daemon is shut down, the daemon can be moved to another AS Instance by creating a new daemon containing the same context information as the preceding daemon. This enables the new daemon to do the same job.
The processing of an ABAP Daemon takes place in the background and is event-driven. Both the consumer of a daemon and the ABAP runtime environment can raise ABAP Daemon events and the daemon can respond to these events using predefined interface methods. A daemon must always be ready to respond to inbound events and this is ensured by running ABAP Daemon processing in a non-blocking mode.
7.31 | 7.40 | 7.54
- ABAP Daemons can be used as event handlers with long lifetimes, for example to respond to changes in shared internal or external AS ABAP resources.
- More details about ABAP Daemon Framework can be found under ABAP Daemons.
ABAP Daemon Classes
An ABAP Daemon class is a global class that inherits from the abstract system class CL_ABAP_DAEMON_EXT_BASE and it must also be possible to create public instances of this daemon class. From the superclass, an ABAP Daemon class inherits the methods of the interface IF_ABAP_DAEMON_EXTENSION that it uses to respond to ABAP Daemon events if they are implemented in the ABAP Daemon class.
- How context information is saved in ABAP Daemon Memory or to other suitable memory areas, such as shared memory or database tables.
- How ABAP Messaging Channels are bound for communication with consumers.
- Whether an ABAP Timer is created to limit the lifetime of the daemon if required.
Except for ON_ACCEPT, each of these methods has an input parameter I_CONTEXT with the static type IF_ABAP_DAEMON_CONTEXT that points to a context object. The context object has interface methods that handle context information about the current daemon or that stop or restart it:
An ABAP Daemon class can contain further helper methods and can call any number of other procedures in its methods. The implementation of an ABAP Daemon class and the procedures it calls must be executable in
non-blocking mode to prevent the runtime error
ABAP Daemon processing and a subsequent restart of the daemon.
- To write context information, it is advisable to create a central helper method that is called by the methods ON_START, ON_ERROR, and ON_RESTART. The ABAP Daemon memory associated with the daemon is particularly well suited for this task, although other repositories can also be used, such as the shared memory or database tables.
- The interface IF_ABAP_TIMER_HANDLER can be implemented to turn an ABAP Daemon class into an ABAP Timer handler too and hence make it able to respond to ABAP Timer events. This makes it possible, for example, to wait for certain events or to stop the daemon after a defined period of time.
Creating and Using ABAP Daemons
ABAP Daemons are created and consumed using the static methods of the class CL_ABAP_DAEMON_CLIENT_MANAGER in ABAP Daemon Manager. The following rules apply here:
- An ABAP Daemon can be created and used from any ABAP program.
- An ABAP Daemon can only be used in the same AS ABAP as the program it was created by and the ABAP Daemon session always has the same client ID as the current user session. No predefined restrictions exist for the user who is using the program in question.
- Only the program that created an ABAP Daemon using ABAP Daemon Manager can use this daemon in ABAP Daemon Manager. If any other programs attempt this, an exception is raised. It is also not possible for a daemon to access itself using ABAP Daemon Manager. If multiple programs need to access the same daemon, it is best to wrap these ABAP Daemon Manager reads in a class whose class pool is the only program that can access this daemon.
ABAP Daemon Manager (or the class CL_ABAP_DAEMON_CLIENT_MANAGER) has the following methods:
- It must be an internal connection to the same AS ABAP.
- It must be an ABAP connection (with or without load distribution).
- A client ID used in the RFC destination must be the same ID as used in the current user session.
- An AS Instance specified as hostname_sysid_instnr must belong to the current AS ABAP.
- It is advisable to create dedicated RFC destinations for ABAP Daemons with a suitable user:
- ABAP Daemons run in the background, which means that dialog users should not be used.
- The user in question should have precisely those authorizations required for daemon processing.
- One consumer can create multiple ABAP Daemons of an ABAP Daemon class, which can then be distinguished by using different names. It can also be useful, however, to permit just one daemon from an ABAP Daemon class as a singleton in a single AS ABAP. The checks needed here must be provided by the consumer.
- In most cases, a consumer does not need to know the internal ID of an ABAP Daemon. If the method calls of the ABAP Daemon handler are wrapped in a class, as recommended, this class can encapsulate them in a private attribute.
- A consumer can communicate with an ABAP Daemon only by using PCP messages.
- On its own, the method GET_DAEMON_INFO in ABAP Daemon Manager is not enough to create an ABAP Daemon as a system-wide singleton. Parallel reads can be used to start multiple daemons in the same ABAP Daemon class before they are returned by GET_DAEMON_INFO.
- Internally, ABAP Daemons are handled using the RFC interface. Accordingly, a consumer of daemons must also have the associated RFC authorizations.
- The class pool of an ABAP Daemon (or the instance of an ABAP Daemon class) is always the only ABAP session program in its ABAP Daemon session, since no program calls are possible in the associated non-blocking mode.
- When an ABAP Daemon is stopped or restarted due to an error, its entire context is removed. The associated ABAP Daemon session is also ended and, if the daemon is restarted, a new session is started, This affects any context information in the ABAP Daemon memory, any ABAP Timers that were started, and all non-persistent data in the associated ABAP session. More specifically, any SAP locks that were set are released.
- It is the task of the consumer to delete any daemon-specific data in the shared memory or other persistent repositories.
- In cases where a daemon is moved to a different AS Instance, the consumer must also ensure that the settings in question are transferred at the same time.
Managing ABAP Daemons
The transaction SMDAEMON displays the ABAP Daemons on the current AS Instance and they can also be restarted or stopped here.
User-specific breakpoints can be set when an ABAP Daemon is being processed (namely when the methods of the ABAP Daemon class and the procedures called here are executed) to debug the daemon.
ABAP Daemon Examples
See also the class CL_AD_EXT_SIMPLE_DAEMON, which can be used by the program RS_ABAP_DAEMON_TEST. Unlike in the preceding simple examples, this example is more reliable in producing a system-wide singleton ABAP Daemon.