Kontakt

Ansicht
Dokumentation

ABENABAP_DAEMON - ABAP DAEMON

ABENABAP_DAEMON - ABAP DAEMON

Vendor Master (General Section)   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

ABAP Daemon Framework ()

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 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 der 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 seiner kann ein Daemon auf eine andere 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 das ABAP-Laufzeit-Framework 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.

Hinweise

  • 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 instanziierbar 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 des 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 Instanziierung des Daemons ausgeführt. In ihrer Implementierung können Initialisierungen des Daemons vorgenommen werden, wie z.B.:

  • 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 die aktuelle heruntergefahren wird. In der Implementierung der Methode kann versucht werden, den Daemon auf eine andere freien 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-Behandler 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 gilt:

  • 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.

  • Eine als hostname_sysid_instnr angegebene 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 vom Verwender programmiert werden.
  • In der Regel muss ein Verwender die interne Kennung eines ABAP-Daemon nicht kennen. Falls die Methodenaufrufe des ABAP-Daemon-Behandlers 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.
  • 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 eine andere muss der Verwender selbst dafür sorgen, die nötigen Einstellungen rechtzeitig zu übernehmen.

ABAP Daemons verwalten

Die Transaktion SMDAEMON zeigt die ABAP-Daemons der aktuellen 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.

ABAP-Daemon-Beispiele

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.






General Material Data   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 27736 Date: 20240523 Time: 175014     sap01-206 ( 371 ms )