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 application server 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 application server 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 application server of a daemon is shut down, the daemon can be moved to another application
server 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
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.
This method is executed before the daemon is actually started. The return value of the method has the
type ABAP_DAEMON_SETUP_MODE from ABAP Dictionary and must be set to a value dictated by the components
of the constant structure CO_SETUP_MODE of the interface IF_ABAP_DAEMON_EXTENSION.
The daemon start is accepted or rejected using these values. The method can be implemented to decide
whether the start is accepted or not. For example, user-dependent authorizations can be evaluated and
the start of the daemon can be limited to specific programs. To do this, the object passed in the input
parameter I_CONTEXT_BASE of the static type IF_ABAP_DAEMON_CONTEXT_BASE
can be evaluated. Its methods, GET_START_PARAMETER and GET_START_CALLER_INFO, return the required information. They behave in the same way as the identically named methods of a context object.
This method is executed when a daemon is started using the method START in
ABAP Daemon Managers
and directly after an instance of the daemon is executed. The daemon can be initialized in its implementation in the following ways:
Whether an ABAP Timer is created to limit the lifetime of the daemon if required.
This method is executed when the daemon receives a
PCP message sent using the method SEND of an
ABAP Daemon handle. To do this, the method ATTACH in
ABAP Daemon Manager
returns a reference to a daemon handle. The messages in the the input parameter I_MESSAGE can be evaluated in the implementation of the method ON_MESSAGE.
This method is executed after the daemon is restarted automatically due to a
message of the type E, A, or X or because of a
runtime error. A runtime error closes the
internal session of the daemon, deletes the associated
ABAP memory, and produces a
short dump. The automatic
restart opens a new internal session. The context of the daemon can be restored in the implementation of the method by accessing context information preserved in the
ABAP Daemon memory
or in another repository, The input parameter I_CODE contains information about the source of the runtime
error. Runtime errors should be avoided in the method ON_ERROR itself If a runtime error does occur here, the execution of the next method is delayed by 30 seconds.
This method is executed when the daemon is restarted using its context object or after the event ON_BEFORE_RESTART_BY_SYSTEM
(see below). The context of the daemon can be restored in the implementation of the method by accessing context information preserved in the
ABAP Daemon memory or in another repository,
This method is executed when the current application server is shut down. This method can be implemented
so that the daemon is moved to another free application server (if available) by starting a new daemon here with the same context information. The daemon is stopped automatically after this method is executed.
This method is executed when the current AS ABAP is shut down. This method can be implemented to include
cleanup activities, such as deleting temporary daemon data in persistent repositories. The daemon is stopped automatically after this method is executed.
This method is executed when an inconsistent state is detected in the daemon. This can occur when programs
used by a daemon are modified and need to be reloaded. If necessary, this method can be implemented
to perform appropriate tasks, such as updating the saved context information. After this method is executed, a restart is performed automatically and the method ON_RESTART runs.
This method is executed when the daemon is stopped using the method STOP in
ABAP Daemon Manager
or using its context object (see below). This method can be implemented to include cleanup activities, such as deleting temporary daemon data in the relevant memory ares. In the input parameter I_MESSAGE, the method is sent the
PCP message, which can be passed when the daemon is stopped (this is optional).
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:
This method returns information about the context of the consumer of the daemon, such as the client, user name, or ABAP program in a structure of the type ABAP_DAEMON_START_CALLER_INFO.
This method returns the unique internal ID of the current daemon.
This method writes data to the ABAP Daemon memory in
PCP format. Here, this data is
assigned to the current daemon. Here, they are preserved for the full lifetime of the daemon (including any restarts). If SET_APPLICATION_PARAMETER is repeated, all existing data is overwritten.
This method reads the latest data written using SET_APPLICATION_PARAMETER from the ABAP Daemon memory.
This method restarts the current daemon with the same internal ID. This deletes the internal session of the daemon with all associated memories, such as the
ABAP memory, and opens a new internal session. The restart raises the event ON_RESTART.
This method stops the current daemon and raises the event ON_STOP at the same time.
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 DAEMON_ILLEGAL_STATEMENT in
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:
This method starts an ABAP Daemon of an ABAP Daemon class passed to the input parameter I_CLASS_NAME
under a name passed to the input parameter I_NAME. This daemon is started only when permitted by the interface method ON_ACCEPT of the ABAP Daemon class. When the daemon is started, a new
ABAP Daemon session is opened whose
client ID is adopted by the current user session and whose
user name and
logon language are determined using an
RFC destination that can
be passed to the input parameter I_DESTINATION (this is optional). The default value is the predefined
RFC destination NONE. An explicitly specified RFC destination must meet the following prerequisites:
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 application server specified as hostname_sysid_sysnr must be part of the current AS ABAP.
The input parameter I_PRIORITY can be used to specify a priority for the response of the daemon to
ABAP Daemon events. The input parameter I_PARAMETER can be used to pass a
PCP message to the daemon as a start parameter and the daemon can access this message using its context object.
The output parameter E_SETUP_MODE gets the return value of the interface method ON_ACCEPT of the ABAP
Daemon class. The output parameter E_INSTANCE_ID gets the internal ID of the started daemon, which is used by ABAP Daemon Manager to access this daemon.
In its return value with the static type IF_ABAP_DAEMON_HANDLE, this method returns a reference to an
ABAP Daemon handle
for the daemon whose internal ID was passed to the input parameter I_INSTANCE_ID. The method SEND of the daemon handle can be used by the consumer to send
PCP messages to the daemon and the daemon can handle these messages in its interface method ON_MESSAGE.
This method stops the daemon whose internal ID was passed to the input parameter I_INSTANCE_ID. The
ABAP Daemon event ON_STOP is raised first. In the associated method, the daemon can evaluate the
PCP passed to the input parameter I_PARAMETER.
Returns an internal table containing information about all ABAP Daemons in the current AS ABAP for the ABAP Daemon class that is passed to the input parameter I_CLASS_NAME.
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.
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 application server, 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 application server 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.
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.