Skip to Content
Technical Articles

ABAP Daemon – ABAP Session with unlimited lifetime

Overview:

ABAP Daemon – A long lasting ABAP session !

Have you ever feel the need of session which has unlimited lifespan for event handling?

Recently I came across new features available in SAP HANA called ABAP Daemon. It is available from system SAP HANA 1709(AS ABAP 7.52) . Further modification was added in 1809 i.e. Start-up configuration.

In SAP, most applications use either batch jobs or session-based polling techniques to detect an event in the system (e.g. create/update/delete), and then apply the next required steps. These techniques are not completely reliable, can sometime fails due to error/short dumps/ outage. Daemon provide much reliable way of event handling.

Lets suppose you want to perform some activities after some events or documents created in the system. In this case the next activities required to be performed, can be passed to daemon by sending message to daemon instance.

An example with business case is explained in my next blog Implement ADF: ABAP Daemon Framework

For now, lets go in details of ABAP Daemon.

What is ABAP Daemon?

  • ABAP Daemon is an ABAP session which can be used for event handling in much reliable way and keep a state in between. It is a concept based on Linux daemon or window services.
  • It can also be called long-lasting ABAP session, as once it is started, there is no limit for the lifetime of such ABAP sessions contrary to other session types like RFC, HTTP, GUI etc.
  • ABAP Daemon sessions are robust against errors, i.e. a daemon session immediately restart automatically every time a runtime error or a message of type EA, 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.
  • An ABAP Daemon is an instance of an ABAP Daemon class that is persisted in a special ABAP Daemon session.

SAP provide it as a ABAP Daemon framework(ADF), which contains event handler API methods described below. The class CL_ABAP_DAEMON_EXT_BASE has to be inherited in order to implement ADF.

These ADF method get invoked by the methods of Daemon Manager class CL_ABAP_DAEMON_CLIENT_MANAGER.

The details of both class are described below:

Lets see what are method available in the API:

  • Method ON_ACCEPT:  This is the first method which gets executed to allow the application to accept or reject the instantiation of the ABAP Daemon application. By setting the export parameter e_setup_mode(1=accept, 2=reject, 3= server shutdown, 4=system shutdown 5 = max daemon reached, 1000=reject offset), the creation can be accepted or rejected.This method gets invoked by Daemon Manager class CL_ABAP_DAEMON_CLIENT_MANAGER method START.
  • Method ON_START: executed only once just after the daemon start has been accepted (ON_ACCEPT).
  • Method ON_MESSAGE: executed every time the daemon receives a message that has been sent by a client application via the associated Daemon Instance ID. This method invoked by method ATTACH & SEND (of interface IF_ABAP_DAEMON_HANDLE) in Daemon Manager class.
  • Method ON_STOP: executed when the daemon is stopped using the method STOP in ABAP Daemon Manager class.
  • Method ON_ERROR: executed if the daemon has been restarted because of an error (e.g. an message of type E/A/X). If an error occurs during the execution of the ON_ERROR method, the subsequent ON_ERROR execution will be delayed for approx. 30 seconds to avoid a busy loop of ON_ERROR processing.The delay value is not configurable.
  • Method ON_RESTART: a daemon application can recreate its daemon context (similar to the methods ON_START and ON_ERROR).
  • Method ON_BEFORE_RESTART_BY_SYSTEM: 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.
  • Method ON_SERVER_SHUTDOWN: 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.
  • Method ON_SYSTEM_SHUTDOWN: executed when the current AS ABAP is shut down. The daemon is stopped immediately after processing this method.

Restrictions:

As some ABAP statements would cause the daemon to block the execution of arrived events, ABAP Daemons use an adapted non-blocking programming mode. In this programming model, most of these blocking ABAP statements, e.g. SUBMIT, CALL TRANSACTION, WAIT, CALL SCREEN, etc. are not allowed and usage will result runtime error ABAP_DAEMON_ILLEGAL_STATEMENT. An exception is the synchronous Remote Function Call (sRFC): ABAP Daemons are permitted to use synchronous RFC (CALL FUNCTION <func> DESTINATION <dest>) and asynchronous (CALL FUNCTION <func> STARTING NEW TASK <task>).

Daemon Context Information

Beside method ON_ACCEPT, all the methods contain parameter referencing interface IF_ABAP_DAEMON_CONTEXT which can be used to get the context information & also save/restoring context data into ABAP Daemon memory area up to 1 MB.

Note: The ABAP Daemon memory is a subarea of the user memory in which ABAP Daemon can save context information in PCP(Push Channel Protocol) format.

References: Sessions and Memory Areas(AS ABAP 752)

  • Method: GET_START_PARAMETER: provides the Push Channel Protocol (PCP) message, that was specified by the client during the start-up of the ABAP Daemon. You can use this method also in the ON_ACCEPT method using the I_CONTEXT_BASE parameter.
  • Method GET_START_CALLER_INFO: provides information about the caller context, e.g. client, user name, or program. For example, you can use this information in the ON_ACCEPT method using the I_CONTEXT_BASE parameter to check the access rights.
  • Method: SET_APPLICATION_PARAMETER and GET_APPLICATION_PARAMETER: provide the possibility to save and retrieve a very limited size of approx. 1 megabyte of information in the ABAP Daemon session memory. This information is kept for the entire lifetime of the ABAP Daemon instance, even after a restart and error situations.
  • Method: GET_INSTANCE_ID: provides the instance ID that is used to send messages to this daemon (using class CL_ABAP_DAEMON_CLIENT_MANAGER).
  • Method RESTART: leads to a restart of the ABAP Daemon. This includes, Freeing the ABAP memory and processing of method ON_RESTART
  • Method STOP: terminates the ABAP Daemon instance. This will trigger method ON_STOP.

Interaction with an Daemon using ABAP Daemon Manager 

Application can interact with daemon using class CL_ABAP_DAEMON_CLIENT_MANAGER.

  • Method START: ABAP Daemon application can be started using this method. 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).
  • Method STOP: Daemon application can be stopped using this method.
  • Method ATTACH: Send messages to an Daemon application instance using the Send method of an Daemon handle. The ABAP Daemon handle is an object that implements the interface IF_ABAP_DAEMON_HANDLE. It is obtained from the Daemon instance ID using method ATTACH.
  • Note: Daemon uses PCP (Push channel Protocol) format to transfer the message between the sessions & keep the state.
  • Method GET_DAEMON_INFO: Returns an information about all Daemons in the current AS-ABAP server for the Daemon class that is passed to the input parameter I_CLASS_NAME.

T-code: SMDAEMON – Daemon monitoring: 

ABAP Daemon Class Name: It tells the name of implementing class (CL_ABAP_DAEMON_EXT_BASE)  of the ABAP Daemon.

ABAP Daemon session ID: Unique key of the ABAP Daemon session.

ABAP Daemon Name: It has a non-unique, technical name, which is set by the application that has started the daemon. The name is used to identify the ABAP Daemon or a group of multiple ABAP Daemons.

ABAP Daemon State: State in which a running ABAP Daemon currently is.

The states can be the following:

  • Initializing: An ABAP Daemon has been created and is going to start.
  • Starting: First start of the ABAP Daemon. The daemon is processing the “ON_START” event.
  • Processing: The ABAP Daemon is processing an event. The addition “restart imminent” indicates that the daemon is processing the “ON_BEFORE_RESTART_BY_SYSTEM” event, and will be restarted after it has processed this event.
  • Restarting: Restart of the ABAP Daemon. After restart the daemon will process the “ON_RESTART” event. The addition “after error” indicates that an error occurred and the daemon needs to be restarted. After restart the daemon will process the “ON_ERROR” event.
  • Stopping: The ABAP Daemon will be stopped after it has processed the current event.
  • Waiting during <STATE>: While processing an ABAP daemon event, the daemon is waiting. The ABAP Daemon session is currently not running in any work process. <STATE> displays the state of the daemon before it has been changed to the waiting state.
  • Idle: The ABAP Daemon is not processing any event and the ABAP Daemon session is currently not running in any work process. The daemon is ready to receive the next ABAP Daemon event or is waiting during a non-daemon event.
  • Died: An ABAP Daemon session ended unexpectedly.

Client: Client in which the daemons is running.

User: Name of the user who is running the ABAP Daemon session.

Creation Time: Date and time when the ABAP Daemon was created.

Autostart: Indicates whether the ABAP Daemon has been automatically started by the system or not.

Events: Number of daemon-specific events which were processed by the ABAP Daemon.

Error: Number of ABAP Daemon errors.

Code of Last error: Error code of the last ABAP Daemon error.The following error codes can be displayed:

  • 100: Other error
  • 101: E message (program error occurred)
  • 102: A message (program was terminated)
  • 103: X message (ABAP runtime error occurred and the program was terminated)
  • 104: Session canceled

Reason of Last Error: Reason why the last recognized ABAP Daemon error occurred.

Error Time: Date and time of the last ABAP Daemon error occurred.

Click of ABAP Daemon session ID hyperlink, you will get further more details of each daemon instance:

Note: Using Restart Daemon soft,  method ON_BEFORE_RESTART_BY_SYSTEM and ON_RESTART methods of the daemon instance can be triggered using transaction SMDAEMON.

To understand better, I implemented a prototype. The complete implementation is described in next blog with an example.It shows the integration with Interfacing technologies: AIF(Application Interfacing Framework ), IDOC, ABAP Daemon, email etc.

Please check  blog: Implement ADF: ABAP Daemon Framework 

Advantages:

Daemon is very useful & reliable for event handling as:

  • There is no limit of lifetime of ABAP Daemon session.
  • An ABAP Daemon is recreated automatically every time a runtime or a message of type EA, 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.
  • With the commencement of ABAP Channels, more and more polling techniques are replaced by near real-time events. To subscribe to those events, a long-lived session is required that is mostly resilient against any kind of errors. ABAP Daemons provide this foundation.

 

 

References:

1 Comment
You must be Logged on to comment or reply to a post.