Das ABAP Daemon Framework (ADF) ist eine auf Interfaces und Klassen basierende Programmierschnittstelle (API) zur Erzeugung und Behandlung von
ABAP Daemons. Ein ABAP Daemon ist eine Instanz einer
ABAP-Daemon-Klasse, die in einer speziellen
ABAP-Daemon-Sitzung
lebt. Alle Applikationsserver eines AS ABAP haben gemeinsamen Zugriff auf dessen Daemons. Der Zugriff auf einen ABAP Daemon aus einem ABAP-Programm erfolgt über den
ABAP Daemon Manager.
Die Lebenszeit eines ABAP Daemons, der nicht durch Methoden des ADF explizit angehalten wird, ist nur
durch die Lebenszeit des Applikationsservers begrenzt, in dem er ausgeführt wird. Ein ABAP Daemon wird automatisch neu erzeugt, wenn es in ihm zu einem Programmabbruch durch einen
Laufzeitfehler oder durch eine
Nachricht vom Typ E,
A oder X kommt. Beim Herunterfahren seines
Applikationsservers kann ein Daemon auf einen anderen Applikationsserver verlagert werden, in dem ein
neuer Daemon erzeugt wird, der die Kontextinformationen des vorhergehenden Daemons und damit dessen Rolle übernimmt.
Die Verarbeitung eines ABAP Daemons, bzw. die
ABAP-Daemon-Verarbeitung findet im Hintergrund statt und wird über Ereignisse gesteuert. Ein Verwender eines Daemons oder die ABAP-Laufzeitumgebung können
ABAP-Daemon-Ereignisse
auslösen, auf die der Daemon mit vorgegebenen Interfacemethoden reagiert. Damit eine Daemon immer für hereinkommende Ereignisse zur Verfügung steht, findet die ABAP-Daemon-Verarbeitung in einem
Non-Blocking-Modus statt.
ABAP Daemons können als langlebige Ereignisbehandler verwendet werden, um beispielsweise auf Änderungen an gemeinsamen internen oder externen Ressourcen eines AS ABAP zu reagieren.
Für ausführliche Informationen zum ABAP Daemon Framework siehe ABAP Daemons.
ABAP-Daemon-Klassen
Eine ABAP-Daemon-Klasse
ist eine globale Klasse, welche von der abstrakten Systemklasse CL_ABAP_DAEMON_EXT_BASE
erbt und öffentlich instanzierbar sein muss. Eine ABAP-Daemon-Klasse erbt von der Oberklasse die Methoden des Interface IF_ABAP_DAEMON_EXTENSION, mit denen sie auf
ABAP-Daemon-Ereignisse reagiert, falls sie in der ABAP-Daemon-Klasse implementiert sind.
ON_ACCEPT
Diese Methode wird vor dem eigentlichen Start eines Daemons ausgeführt. Der Rückgabewert
der Methode ist vom Typ ABAP_DAEMON_SETUP_MODE aus dem ABAP Dictionary und muss auf einen Wert gesetzt
werden, der durch die Komponenten der konstanten Struktur CO_SETUP_MODE des Interface IF_ABAP_DAEMON_EXTENSION
vorgegeben ist. Mit diesen Werten wird der Start des Daemons akzeptiert oder zurückgewiesen.
In der Implementierung der Methode kann entschieden werden, ob der Start akzeptiert werden soll oder
nicht. Es können beispielsweise Benutzerabhängige Berechtigungen ausgewertet werden und
der Start des Daemons kann auf bestimmte Programme eingeschränkt werden. Hierfür kann
das im Eingabeparameter I_CONTEXT_BASE vom statischen Typ IF_ABAP_DAEMON_CONTEXT_BASE
übergebene Objekt ausgewertet werden. Dessen Methoden GET_START_PARAMETER und GET_START_CALLER_INFO
geben entsprechende Informationen zurück. Sie verhalten sich wie die gleichnamigen Methoden eines Kontextobjekts.
ON_START
Diese Methode wird während des Starts eines Daemons über die Methode START des
ABAP Daemon Managers
direkt nach der Instanzierung des Daemons ausgeführt. In ihrer Implementierung können Initialisierungen des Daemons vorgenommen werden, wie z.B.:
Ablage von Kontextinformationen im ABAP Daemon Memory oder anderen geeigneten Speicherbereichen wie
Shared Memory oder Datenbanktabellen.
Erzeugen eines ABAP Timers, um falls gewünscht die Lebensdauer des Daemons einzuschränken.
ON_MESSAGE
Diese Methode wird ausgeführt, wenn der Daemon eine über die Methode SEND eines
ABAP Daemon Handles gesendete
PCP-Nachricht empfängt. Die Methode ATTACH des
ABAP Daemon Managers
gibt hierfür eine Referenz auf einen Daemon Handle zurück. In der Implementierung der Methode ON_MESSAGE können die Nachrichten im Eingabeparameter I_MESSAGE ausgewertet werden.
ON_ERROR
Diese Methode wird ausgeführt, nachdem der Daemon wegen einer
Nachricht vom Typ E, A oder X oder wegen eines
Laufzeitfehlers automatisch neu gestartet wurde. Ein Laufzeitfehler beendet die
interne Sitzung des Daemons, löscht das zugehörige
ABAP Memory und führt zu einem
Kurzdump. Der automatische
Neustart öffnet eine neue interne Sitzung. In der Implementierung der Methode kann der Kontext des Daemons durch Zugriff auf vorher im
ABAP Daemon Memory
oder anderen Ablagen gespeicherten Kontextinformationen wiederhergestellt werden. Der Eingabeparameter
I_CODE enthält Informationen zur Ursache des Laufzeitfehlers. In der Methode ON_ERROR selbst
sollten Laufzeitfehler vermieden werden. Wenn es dort dennoch zu einem Laufzeitfehler kommt, wird die darauf folgende Ausführung der Methode um 30 Sekunden verzögert.
ON_RESTART
Diese Methode wird ausgeführt, wenn der Daemon über sein Kontextobjekt oder nach dem Ereignis
ON_BEFORE_RESTART_BY_SYSTEM (siehe unten) neu gestartet wurde. In der Implementierung der Methode kann der Kontext des Daemons durch Zugriff auf vorher im
ABAP Daemon Memory oder anderen Ablagen gespeicherten Kontextinformationen wiederhergestellt werden.
ON_SERVER_SHUTDOWN
Diese Methode wird ausgeführt, wenn der aktuelle Applikationsserver heruntergefahren wird. In
der Implementierung der Methode kann versucht werden, den Daemon auf einen anderen freien Applikationsserver
zu verlagern, indem dort ein neuer Daemon mit den gleichen Kontextinformationen gestartet wird. Nach Ausführung der Methode wird der Daemon automatisch angehalten.
ON_SYSTEM_SHUTDOWN
Diese Methode wird ausgeführt, wenn der aktuelle AS ABAP heruntergefahren wird. In der Implementierung
der Methode können Aufräumarbeiten vorgenommen werden, wie z.B. das Löschen temporärer
Daten des Daemons in persistenten Ablagen. Nach Ausführung der Methode wird der Daemon automatisch angehalten.
ON_BEFORE_RESTART_BY_SYSTEM
Diese Methode wird ausgeführt, wenn für den Daemon ein inkonsistenter Zustand festgestellt
wird. Dies kann der Fall sein, wenn vom Daemon verwendete Programme zwischenzeitlich geändert
wurden und neu geladen werden müssen. In der Implementierung der Methode können falls
notwendig entsprechende Arbeiten ausgeführt werden, wie beispielsweise eine Aktualisierung der
gespeicherten Kontextinformationen. Nach Ausführung der Methode wird automatisch ein Neustart ausgeführt und danach die Methode ON_RESTART ausgeführt.
ON_STOP
Diese Methode wird ausgeführt, wenn der Daemon über die Methode STOP des
ABAP Daemon Managers
oder über sein Kontextobjekt (siehe unten) angehalten wird. In der Implementierung der Methode
können Aufräumarbeiten vorgenommen werden, wie z.B. das Löschen temporärer Daten des Daemons in den verwendeten Speicherbereichen. Die Methode erhält im Eingabeparameter I_MESSAGE die
PCP-Nachricht, die beim Anhalten des Daemons optional übergeben werden kann.
Jede dieser Methoden außer ON_ACCEPT hat einen Eingabeparameter I_CONTEXT vom statischen Typ
IF_ABAP_DAEMON_CONTEXT, der auf ein Kontextobjekt zeigt. Das Kontextobjekt hat Interfacemethoden, die Kontextinformationen zum aktuellen Daemon behandeln oder ihn neu starten oder anhalten:
GET_START_PARAMETER
Diese Methode gibt die PCP-Nachricht zurück, die dem
ABAP Daemon Manager beim Start des Daemons übergeben wurde.
GET_START_CALLER_INFO
Diese Methode gibt Informationen zum Kontext des Verwenders des Daemons wie Mandant, Benutzername, ABAP-Programm in einer Struktur vom Typ ABAP_DAEMON_START_CALLER_INFO zurück.
GET_INSTANCE_ID
Diese Methode gibt die interne eindeutige Kennung des aktuellen Daemon zurück.
SET_APPLICATION_PARAMETER
Diese Methode schreibt Daten im PCP-Format in das
ABAP Daemon Memory.
Diese Daten sind dort dem aktuellen Daemon zugeordnet. Sie bleiben dort während dessen gesamter
Lebenszeit und auch über Neustarts hinweg erhalten. Eine wiederholte Verwendung von SET_APPLICATION_PARAMETER überschreibt die vorhandenen Daten vollständig.
GET_APPLICATION_PARAMETER
Diese Methode liest die zuletzt mit SET_APPLICATION_PARAMETER geschriebenen Daten aus dem ABAP Daemon Memory.
RESTART
Diese Methode führt einen Neustart des aktuellen Daemons mit der gleichen internen Kennung aus. Dabei wird die interne Sitzung des Daemons mit allen zugehörigen Speichern, wie dem
ABAP Memory gelöscht und eine neue interne Sitzung geöffnet. Nach dem Neustart wird das Ereignis ON_RESTART ausgelöst.
STOP
Diese Methode hält den aktuellen Daemon an, wobei das Ereignis ON_STOP ausgelöst wird.
Eine ABAP-Daemon-Klasse kann weitere Hilfsmethoden haben und in ihren Methoden beliebige andere Prozeduren aufrufen. Die Implementierung einer ABAP-Daemon-Klasse und der von ihr aufgerufenen Prozeduren muss im
Non-Blocking-Modus ausführbar sein, sonst kommt es während der
ABAP-Daemon-Verarbeitung zum Laufzeitfehler DAEMON_ILLEGAL_STATEMENT und der Daemon wird neu gestartet.
Hinweise
Es empfiehlt sich, für das Schreiben von Kontextinformationen eine zentrale Hilfsmethode
anzulegen, die von den Methoden ON_START, ON_ERROR und ON_RESTART aufgerufen wird. Neben Ablagen wie dem Shared Memory oder Datenbanktabellen ist besonders das dem Daemon zugeordnete
ABAP Daemon Memory für solche Informationen geeignet.
Eine ABAP-Daemon-Klasse kann durch Implementierung des Interfaces IF_ABAP_TIMER_HANDLER gleichzeitig auch ein
ABAP Timer Handler sein, um auf Ereignisse eines
ABAP Timers zu reagieren. Dies erlaubt es beispielsweise, gewisse Zeiten zu warten oder den Daemon nach einer bestimmten Zeit anzuhalten.
ABAP Daemons erzeugen und verwenden
Erzeugung und Verwendung von ABAP Daemons erfolgen über den
ABAP Daemon Manager,
d.h. die statischen Methoden der Klasse CL_ABAP_DAEMON_CLIENT_MANAGER. Dabei gelten folgende Regeln:
Ein ABAP Daemon kann aus jedem ABAP-Programm erzeugt und verwendet werden.
Ein ABAP Daemon kann nur im gleichen AS ABAP wie das erzeugende Programm verwendet werden und die
ABAP-Daemon-Sitzung hat immer die gleiche
Mandantenkennung wie die aktuelle
Benutzersitzung. Für den Benutzer, der das erzeugende Programm verwendet, bestehen keine vordefinierten Einschränkungen.
Nur das Programm, das einen ABAP Daemon über den ABAP Daemon Manager erzeugt hat, kann den
Daemon über den ABAP Daemon Manager verwenden. Bei allen anderen Programmen führt der
Versuch der Verwendung zu einer Ausnahme. Auch ein Daemon kann nicht über den ABAP Daemon Manager
auf sich selbst zugreifen. Wenn aus mehreren Programmen auf eine Daemon zugegriffen werden soll, empfiehlt
sich die Verschalung der Zugriffe über den ABAP Daemon Manager in einer Klasse, deren Class-Pool dann als einziges Programm auf den Daemon zugreifen kann.
Der ABAP Daemon Manager, bzw. die Klasse CL_ABAP_DAEMON_CLIENT_MANAGER hat folgende Methoden:
START
Die Methode startet einen ABAP Daemon einer an den Eingabeparameter I_CLASS_NAME zu übergebenden
ABAP-Daemon-Klasse unter einem an den Eingabeparameter I_NAME zu übergebenden Namen. Der Daemon wird nur gestartet, wenn die Interfacemethode ON_ACCEPT der ABAP-Daemon-Klasse dies erlaubt. Beim Start des Daemons wird eine neue
ABAP-Daemon-Sitzung geöffnet, deren
Mandantenkennung von der aktuellen Benutzersitzung übernommen wird und deren
Benutzername und
Anmeldesprache optional über eine an den Eingabeparameter I_DESTINATION übergebbare
RFC-Destination bestimmt
wird. Der Standardwert ist die vordefinierte RFC-Destination NONE. Eine explizit angegebene RFC-Destination muss folgende Voraussetzungen erfüllen:
Es muss eine interne Verbindung auf den gleichen AS ABAP sein.
Es muss eine ABAP-Verbindung mit oder ohne Lastverteilung sein.
Eine in der RFC-Destination verwendete Mandantenkennung muss die gleiche wie in der aktuellen Benutzersitzung sein.
Ein als hostname_sysid_sysnr angegebener Applikationsserver muss zum aktuellen AS ABAP gehören.
Über den Eingabeparameter I_PRIORITY kann eine Priorität angegeben werden, mit welcher der Daemon auf
ABAP-Daemon-Ereignisse reagiert. Über den Eingabeparameter I_PARAMETER kann eine
PCP-Nachricht als Startparameter an den Daemon übergeben werden, auf die dieser über sein Kontextobjekt Zugriff hat.
Der Ausgabeparameter E_SETUP_MODE liefert den Rückgabewert der Interfacemethode ON_ACCEPT der
ABAP-Daemon-Klasse. Der Ausgabeparameter E_INSTANCE_ID liefert die interne Kennung des gestarteten Daemons, über die der ABAP Daemon Manager auf ihn zugreifen kann.
ATTACH
Die Methode gibt in ihrem Rückgabewert vom statischen Typ IF_ABAP_DAEMON_HANDLE eine Referenz auf ein
ABAP Daemon Handle
für den Daemon zurück, dessen interne Kennung an den Eingabeparameter I_INSTANCE_ID übergeben wurde. Mit der Methode SEND des Daemon Handles kann der Verwender
PCP-Nachrichten an den Daemon senden, die dieser in seiner Interfacemethode ON_MESSAGE behandeln kann.
STOP
Die Methode hält den Daemon an, dessen interne Kennung an den Eingabeparameter I_INSTANCE_ID übergeben wurde. Vorher wird das
ABAP-Daemon-Ereignis
ON_STOP ausgelöst. Der Daemon kann in der zugehörigen Methode die an den optionalen Eingabeparameter I_PARAMETER übergebene
PCP-Nachricht auswerten.
GET_DAEMON_INFO
Gibt eine interne Tabelle mit Informationen aller ABAP Daemons des aktuellen AS ABAP zur im Eingabeparameter I_CLASS_NAME übergebenen ABAP-Daemon-Klasse zurück.
Hinweise
Es wird empfohlen, für ABAP Daemons eigene RFC-Destinationen mit passendem Benutzer anzulegen:
Da ABAP Daemons im Hintergrund verarbeitet werden, sollte der Benutzer kein Dialogbenutzer sein.
Der Benutzer sollte genau die passenden Berechtigungen haben, die für die Daemon-Verarbeitung notwendig sind.
Ein Verwender kann mehrere ABAP Daemons einer ABAP-Daemon-Klasse erzeugen, die dann durch die Vergabe
verschiedener Namen unterschieden werden können. Es kann aber auch sinnvoll sein, nur einen einzigen
Daemon einer ABAP-Daemon-Klasse als Singleton in einem AS ABAP zu erlauben. Die entsprechenden Überprüfungen müssen selbst programmiert werden.
In der Regel muss ein Verwender die interne Kennung eines ABAP Daemon nicht kennen. Falls die Methodenaufrufe
des ABAP Daemon Handlers wie empfohlen in einer Klasse verschalt sind, kann diese die Kennung in einem privaten Attribut kapseln.
Ein Verwender kann nur über PCP-Nachrichten mit einem ABAP Daemon kommunizieren.
Die Methode GET_DAEMON_INFO des ABAP Daemon Managers ist nicht ausreichend, um einen ABAP Daemon
als systemweiten Singleton zu erzeugen. Durch parallele Zugriffe können mehrere Daemons der gleichen ABAP-Daemon-Klasse gestartet werden, bevor sie von GET_DAEMON_INFO zurückgegeben werden.
ABAP Daemons werden intern über die RFC-Schnittstelle behandelt. Dementsprechend muss ein Verwender von Daemons auch die zugehörigen
RFC-Berechtigungen haben.
Der Class-Pool eines ABAP Daemons, bzw. der Instanz einer ABAP-Daemon-Klasse, ist in seiner
ABAP-Daemon-Sitzung immer das einzige Programm einer
ABAP-Sitzung, da im zugehörigen
Non-Blocking-Modus keine Programmaufrufe möglich sind.
Wenn ein ABAP Daemon angehalten oder wegen eines Fehlers neu gestartet wird, wird sein gesamter Kontext entfernt. Die zugehörige
ABAP-Daemon-Sitzung wird ebenfalls beendet und bei einem Neustart eine neue Sitzung gestartet. Dies betrifft Kontextinformationen im
ABAP Daemon Memory, eventuell gestartete
ABAP Timer und alle nicht persistenten Daten in den Speicherbereichen der zugehörigen
ABAP-Sitzung. Insbesondere werden auch eventuell gesetzte
SAP-Sperren aufgehoben.
Um das Löschen Daemon-spezifischer Daten im Shared Memory oder in persistenten Ablagen muss sich ein Verwender selbst kümmern.
Bei der Verlagerung eines Daemons auf einen anderen Applikationsserver muss der Verwender selbst dafür sorgen, die nötigen Einstellungen rechtzeitig zu übernehmen.
ABAP Daemons verwalten
Die Transaktion SMDAEMON zeigt die ABAP Daemons des aktuellen Applikationsservers an und erlaubt auch diese neu zu starten oder anzuhalten.
Hinweis
Während der Verarbeitung eines ABAP Daemons, d.h. während der Ausführung der Methoden der ABAP-Daemon-Klasse und der dort aufgerufenen Prozeduren, können benutzerspezifische
Breakpoints gesetzt werden, um den Daemon zu debuggen.
Siehe auch die Klasse CL_AD_EXT_SIMPLE_DAEMON, die vom Programm RS_ABAP_DAEMON_TEST
verwendet werden kann. Dort wird im Gegensatz zu den vorhergehenden vereinfachenden Beispielen besser abgesichert, dass der ABAP Daemon ein systemweiter Singleton ist.