Das ABAP-Kochbuch

22 Pages·2016·0.36 MB·German

Kapitel 7 Protokolle und Meldungen strukturiert aufzubewahren ist
eine Herausforderung. Wie Sie diese mit dem Applikationslog
bewältigen können, zeigen wir Ihnen in diesem Kapitel.
7 Mit dem Applikationslog arbeiten
Vielleicht kommen Ihnen eine oder mehrere der folgenden Situatio-
nen bekannt vor:
(cid:2) Job-Protokolle werden nie kontrolliert. Wenn man ein Job-Proto-
koll doch einmal benötigt, ist es bereits gelöscht.
(cid:2) Sollten die Job-Protokolle doch vorhanden sein, sind es so viele
und so umfangreiche Protokolle, dass die Suche nach einer Infor-
mation der Suche nach der viel zitierten Nadel im Heuhaufen
gleichkommt.
(cid:2) Ein Anwender bekommt im Zuge einer von ihm durchgeführten
Aktion routinemäßig mehrere Meldungen und drückt diese
ebenso routiniert mit einem beherzten Klick auf OK weg. Später
stellt er fest, dass etwas Unvorhergesehenes passiert ist.
Diesen und diversen weiteren Situationen können Sie durch die Nut-
zung des Applikationslogs entgegentreten. Das Applikationslog ist ein
Framework, bestehend aus mehreren Tabellen, einem Application
Programming Interface (API) in Form diverser Funktionsbausteine und
einigen Transaktionen. Dieses Framework kann genutzt werden, um
sowohl transiente (also nur im Hauptspeicher gehaltene) als auch per-
sistente (in der Datenbank speicherbare) Protokolle anzulegen. Diese
können einfach gehalten (reine Ablage von Meldungen), aber auch
sehr komplex gestaltet sein (interaktives Protokoll).
7.1 Schnittstelle
Die API-Bausteine, mit denen wir in den folgenden Abschnitten Schnittstellen-
arbeiten werden, finden Sie in folgenden Funktionsgruppen: bausteine
249
7 7.3
Mit dem Applikationslog arbeiten Transiente Protokolle
(cid:2) SBAL: Zugriffsbausteine für Meldungen und Protokollkopfdaten Die Problemklasse (Datenelement BALPROBCL) dient der Klassifizie- Problemklasse
(cid:2) SBAL_DB: Datenbankzugriffe (Protokolle speichern, lesen, rung der Wichtigkeit eines Protokolleintrags:
löschen etc.) (cid:2) 1 sehr wichtig
(cid:2) SBAL_DISPLAY: Protokolle anzeigen (cid:2) 2 wichtig
Darüber hinaus gibt es weitere Funktionsgruppen, deren Bausteine (cid:2) 3 mittel
einen erweiterten Zugriff auf Applikationslogs ermöglichen. Für den (cid:2) 4 Zusatzinformationen (Default)
alltäglichen Bedarf sollten die hier genannten Funktionsgruppen
Die Problemklasse erhält ihre besondere Bedeutung bei persistenten
jedoch vorerst ausreichen. Für die Bedienung der API werden Daten-
Protokollen, da im Einstiegsbild der Auswertungstransaktion bereits
elemente, Strukturen und Tabellentypen ausgeliefert. Diese sind an
nach der Wichtigkeit des Protokolls eingeschränkt werden kann;
dem Präfix BAL bzw. BAL_S (Strukturen) und BAL_T (Tabellentypen)
diese wiederum ergibt sich aus der höchsten Problemklasse der im
zu erkennen.
Protokoll erfassten Nachrichten.
7.2 Begriffsklärung
7.3 Transiente Protokolle
Da die Begriffe rund um das Applikationslog teilweise sehr verwir-
Als erstes einfaches Beispiel werden wir ein Protokoll lediglich im Protokoll im
rend sein können, wollen wir an dieser Stelle etwas Klarheit schaffen.
Hauptspeicher halten. Die gezeigte Variante können Sie wählen, um Hauptspeicher
Objekt/ Anhand von Objekten und Unterobjekten werden Protokolle kategori- einem Anwender das Ergebnis eines von ihm ausgelösten, komple-
Unterobjekt siert. Protokolle, die auf der Datenbank gespeichert werden sollen, xen automatisierten Vorgangs in ansprechender Form zu präsen-
müssen einem Objekt sowie einem Unterobjekt zugeordnet werden. tieren.
Ein Protokoll ist genau einem Objekt und Unterobjekt zugeordnet;
1. Legen Sie ein Testprogramm mit Transaktion SE38 bzw. SE80 an.
über diese Informationen ist das Protokoll in der Auswertungstrans-
aktion SLG1 leicht aufzufinden. Objekte und Unterobjekte werden 2. Fügen Sie die folgenden Datendeklarationen ein:
im Customizing (Transaktion SLG0; siehe unten) gepflegt.
DATA gs_log TYPE bal_s_log.
DATA gv_log_handle TYPE balloghndl.
Externe Die externe Identifikation ist ein 100-stelliges Textfeld, das mit belie-
DATA gs_msg TYPE bal_s_msg.
Identifikation bigen Werten gefüllt werden darf. In der Praxis hat es sich bewährt,
dieses mit sprechenden Wertbezeichnungen zu belegen, um abge- 3. Legen Sie mit dem Coding aus Listing 7.1 ein neues Applikations-
legte Protokolle leichter finden zu können. Wenn ein Protokoll nicht log an.
auf der Datenbank abgelegt werden soll, ist die Angabe einer exter-
gs_log-extnumber = 'AppLog-Test'.
nen Identifikation bei der Anlage des Protokolls ausreichend. CALL FUNCTION 'BAL_LOG_CREATE'
EXPORTING
Protokoll-Handle Das Protokoll-Handle (Datenelement BALLLOGHNDL) wird benötigt, um
i_s_log = gs_log
ein Protokoll innerhalb eines Programms zu manipulieren, also um IMPORTING
Nachrichten hinzuzufügen, zu löschen etc. Es wird von dem jeweils e_log_handle = gv_log_handle.
verwendeten API-Baustein erstellt.
Listing 7.1 Applikationslog anlegen
Protokollnummer Die Protokollnummer (Datenelement BALOGNR) identifiziert das Proto-
koll auf der Datenbank. Sie wird dementsprechend auch benötigt, In den Kopfdaten wird lediglich die externe ID versorgt. Das vom
um ein bereits abgelegtes Protokoll erneut zu lesen. Funktionsbaustein BAL_LOG_CREATE an das Programm zurückgelie-
250 251
7 7.4
Mit dem Applikationslog arbeiten Persistente Protokolle
ferte Protokoll-Handle wird für die weitere Verarbeitung von dies ist am Icon in der Spalte Ltxt erkennbar. Der Langtext wird
Applikationsprotokollen im Hauptspeicher benötigt. angezeigt, sobald Sie auf das Icon klicken.
4.Fügen Sie dem Protokoll eine T100-Nachricht hinzu, wie in Listing
7.2 zu sehen.
gs_msg-msgty = 'S'.
gs_msg-msgid = '00'.
gs_msg-msgno = '002'.
gs_msg-probclass = '3'.
CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
i_log_handle = gv_log_handle
i_s_msg = gs_msg.
Listing 7.2 T100-Nachricht dem Applikationslog hinzufügen
Die Nachrichtenfelder der Struktur BAL_S_MSG entsprechen den Abbildung 7.1 Protokollanzeige
Namen der Struktur SYST, sodass eine zuvor via MESSAGE ausge-
löste Nachricht durch eine einfache MOVE-CORRESPONDING-Anwei-
7.4 Persistente Protokolle
sung in die Struktur übernommen werden kann. Dem Protokoll
können jedoch nicht nur T100-Nachrichten hinzugefügt werden,
Wir werden für jedes Ticket, das in unserem Ticketsystem erfasst Protokoll für
sondern auch Freitextmeldungen. Dies zeigt Listing 7.3. wird, ein Applikationsprotokoll anlegen. Ändert sich das Ticket (z.B. Tickets
CALL FUNCTION 'BAL_LOG_MSG_ADD_FREE_TEXT' der Status), wird dies im zugehörigen Protokoll festgehalten. Da
EXPORTING
Nachrichten, die in ein Protokoll geschrieben werden, automatisch
i_log_handle = gv_log_handle
das aktuelle Datum und die Uhrzeit sowie den ausführenden Benut-
i_msgty = 'S'
zer enthalten, erhalten wir ein aussagekräftiges Protokoll zum Ticket.
i_text = 'Frei hinzugefügter Text'.
Listing 7.3 Freitextnachricht dem Applikationslog hinzufügen In diesem Abschnitt werden wir außerdem den Zugriff auf das Appli-
kationslog in Klassen kapseln, die uns den Umgang mit dem Proto-
5.Abschließend lassen Sie sich das Protokoll anzeigen: koll erleichtern.
CALL FUNCTION 'BAL_DSP_LOG_DISPLAY'.
Wozu dient die Kapselung in Klassen?
Ergebnis des Der DISPLAY-Baustein wird hier in der einfachsten Form aufgerufen. In der Praxis gehen die zu protokollierenden Nachrichten in unterschied-
Testprogramms Über die Parametrisierung und Filterkriterien können Sie die lichsten Formaten ein, z.B.:
Anzeige auf bestimmte Protokolle bzw. Meldungen einschränken (cid:2) mittels MESSAGE-Anweisung erzeugte T100-Nachrichten
(z.B. bei Verwendung mehrerer Protokolle gleichzeitig), worauf wir (cid:2) über Exception-Objekte (klassenbasierte Ausnahmen), die das Inter-
in Abschnitt 7.7, »Protokollausgabe anpassen«, noch genauer einge- face IF_T100_MESSAGE implementieren
hen. Lassen Sie das Testprogramm laufen. Die Anzeige sollte der in (cid:2) über herkömmliche Ausnahmen, die mit einer T100-Nachricht ausge-
Abbildung 7.1 entsprechen. Im oberen Teil des Bildes sehen Sie die löst werden
Protokollkopfdaten sowie eine Zusammenfassung auf Basis der Pro- (cid:2) als Rückgaben von Business Application Programming Interfaces
blemklassen. Der untere Teil zeigt die im Protokoll enthaltenen (BAPIs) in verschiedenen Formaten (BAPIRET1, BAPIRET2,
Nachrichten. Die erste protokollierte Nachricht hat einen Langtext, BAPIRETURN etc.)
252 253
7 7.4
Mit dem Applikationslog arbeiten Persistente Protokolle
3. Stellen Sie sicher, dass im Navigationsbaum auf der linken Seite
Um diese Meldungen in einem Applikationslog speichern zu können,
der Eintrag Objekte markiert ist.
müssen sie zunächst in das Format BAL_S_LOG konvertiert und dann dem
Protokoll hinzugefügt werden. Diese Konvertierungen machen das 4. Klicken Sie auf Neue Einträge, und Sie gelangen zur Anlage neuer
Coding schnell unübersichtlich und damit schwer zu pflegen. Die Idee ist
Applikationslog-Objekte.
daher, die Konvertierung in Methoden zu kapseln und den entstehenden
Overhead dadurch auf ein Minimum zu begrenzen. Mit den in der Folge 5. Legen Sie das Objekt ZBOOK mit dem Objekttext »Protokolle zum
vorgestellten Klassen ist es möglich, Konvertierung und Logging in nur Buch« an (siehe Abbildung 7.3).
zwei Codezeilen zu realisieren, ab SAP-NetWeaver-Release 7.02 sogar in
nur einer Zeile.
7.4.1 Objekt und Unterobjekt anlegen
Protokolle, die in der Datenbank abgelegt werden sollen, müssen
einem Objekt und Unterobjekt zugeordnet werden. Über diese Kom-
bination können die abgelegten Protokolle später leicht gefunden
und analysiert werden.
Transaktion SLG0: Sie sind dabei nicht auf die im Standardsystem ausgelieferten
Objektpflege Objekte und Unterobjekte festgelegt, sondern können diese beliebig
selbst anlegen:
1.Starten Sie Transaktion SLG0.
2.Sie werden darauf hingewiesen, dass die zu pflegende Tabelle Abbildung 7.3 Objekt hinzufügen
mandantenunabhängig ist. Bestätigen Sie den Hinweis. Sie befin-
den sich nun im Startbild der Objektpflege (siehe Abbildung 7.2). 6. Drücken Sie (¢), und gehen Sie mit (F3) zurück in die Übersicht.
Positionieren Sie den Cursor auf dem neu hinzugefügten Objekt,
und markieren Sie den Eintrag. Klicken Sie dann doppelt auf
Unterobjekte auf der linken Seite.
7. Klicken Sie hier wieder auf Neue Einträge, und legen Sie das
Unterobjekt ZTICKET mit dem Unterobjekttext »Protokolle des
Ticketsystems« an.
8. Bestätigen Sie mit (¢), und gehen Sie mit (F3) zurück zur Über-
sicht.
9. Speichern Sie Ihre Eingaben (Sie benötigen einen transportierba-
ren Workbench-Auftrag), und verlassen Sie die Transaktion.
Die Ticketnummer wird immer als externe Identifikation zum Proto- Verbindung zum
koll genutzt. Damit ist das Protokoll zum Ticket eindeutig identifi- Ticket herstellen
zierbar, und es besteht keine Notwendigkeit, die Datenbanktabelle
um ein weiteres Feld (nämlich die Protokollnummer) zu erweitern,
Abbildung 7.2 Transaktion SLG0 – Einstiegsbild um eine Verbindung zum Ticket herzustellen.
254 255
7 7.4
Mit dem Applikationslog arbeiten Persistente Protokolle
7.4.2 Zugriffsklassen anlegen
Der Zugriff auf das Anwendungsprotokoll wird über zwei Klassen
hergestellt – Nachrichten- und Protokollklasse –, die zum einen den
Zugriff auf das Protokoll steuern und es andererseits erlauben, Mel-
Abbildung 7.5 Attribute der Nachrichtenklasse
dungen einfach hinzuzufügen.
5. Legen Sie die Konstruktormethode CONSTRUCTOR an. Übergeben Sie
dieser einen Import-Parameter IV_TIKNR, wie in Abbildung 7.6
Nachrichtenklasse
dargestellt.
Nachrichten- Jede Instanz der Nachrichtenklasse entspricht einer Nachricht. Sie
instanzen dient dazu, die auflaufenden Nachrichten zu »normalisieren«, sodass
sie in einem Programm wie dem Ticketsystem einfacher gesammelt
werden können. Diese Klasse implementieren Sie wie folgt:
1.Starten Sie Transaktion SE24.
2.Geben Sie im Feld Objekttyp »ZCL_BOOK_TICKET_LOG_MSG« Abbildung 7.6 Parameter des Konstruktors
ein, und drücken Sie (F5).
6.Implementieren Sie den Konstruktor mit dem Coding aus Lis-
3.Füllen Sie den Dialog Anlegen Klasse mit den Werten aus Abbil-
ting 7.4.
dung 7.4, und drücken Sie (¢). Achten Sie darauf, dass die Instanz-
erzeugung auf 0 Private gestellt ist. Dadurch ist es nur der Klasse METHOD constructor.
me->gs_msg = is_msg.
selbst möglich, Instanzen von sich zu erzeugen.
get_probclass( ).
ENDMETHOD.
Listing 7.4 Coding des Konstruktors der Nachrichtenklasse
Die übergebene Meldung wird damit in das dafür vorgesehene
Instanzattribut übernommen, anschließend wird die Problem-
klasse per Aufruf einer Methode ermittelt, die wir im nächsten
Schritt anlegen.
7. Legen Sie die private Instanzmethode GET_PROBCLASS an, die keine
Parameter benötigt. Implementieren Sie die Methode wie in Lis-
ting 7.5.
METHOD get_probclass.
CASE me->gs_msg-msgty.
WHEN 'S'.
me->gs_msg-probclass = '4'. " Zusatzinfo
Abbildung 7.4 Eigenschaften der Nachrichtenklasse WHEN 'I'.
me->gs_msg-probclass = '3'. " Mittel
WHEN 'W'.
4.Legen Sie das Attribut GS_MSG mit den Feldwerten aus Abbil-
me->gs_msg-probclass = '2'. " Wichtig
dung 7.5 an. In diesem Attribut werden die Nachrichtendaten
WHEN 'E' OR 'A' OR 'X'.
gespeichert. me->gs_msg-probclass = '1'. " Sehr wichtig
256 257
7 7.4
Mit dem Applikationslog arbeiten Persistente Protokolle
ENDCASE. häufig als Struktur des Typs BAPIRET2 zurück, den wir für unser Bei-
ENDMETHOD.
spiel verwenden.
Listing 7.5 Methode GET_PROBCLASS implementieren
1. Legen Sie die öffentliche statische Methode CREATE_BAPIRET2 an.
Die Parametrisierung entnehmen Sie Abbildung 7.8.
Die Problemklasse der Nachricht wird abhängig vom Nachrichtentyp
gesetzt, wobei Fehler- und Abbruchnachrichten als sehr wichtige
Nachrichten behandelt werden; andere Nachrichten haben hingegen
geringere Priorität.
Zugriffsmethoden Um Instanzen der Klasse außerhalb der Klasse nutzen zu können, benö-
definieren tigen wir Zugriffsmethoden. Wir werden nun zwei statische Methoden
Abbildung 7.8 Parameter CREATE_BAPIRET2
erzeugen, die zu unterschiedlichen Arten von zu sammelnden Nach-
richten jeweils eine Instanz erzeugen und an den Aufrufer zurücklie-
2. Implementieren Sie die Methode mit dem Coding aus Listing 7.7.
fern. Die erste Methode wird dazu eine zuvor über einen MESSAGE-
Befehl erzeugte Nachricht aus den Feldern von SYST bzw. SY lesen: METHOD create_bapiret2.
DATA ls_msg TYPE bal_s_msg.
1.Legen Sie die öffentliche statische Methode CREATE_SYMSG an. Die ls_msg-msgty = is_msg-type.
Parametrisierung entnehmen Sie Abbildung 7.7. ls_msg-msgid = is_msg-id.
ls_msg-msgno = is_msg-number.
ls_msg-msgv1 = is_msg-message_v1.
ls_msg-msgv2 = is_msg-message_v2.
ls_msg-msgv3 = is_msg-message_v3.
ls_msg-msgv4 = is_msg-message_v4.
CREATE OBJECT rr_msg
EXPORTING
Abbildung 7.7 Parameter CREATE_SYMSG
is_msg = ls_msg.
ENDMETHOD.
2.Implementieren Sie die Methode, wie in Listing 7.6 gezeigt.
Listing 7.7 Methode CREATE_BAPIRET2 implementieren
METHOD create_symsg.
DATA ls_msg TYPE bal_s_msg.
Die Nachrichtendaten werden aus der BAPIRET2-Struktur in die
MOVE-CORRESPONDING sy TO ls_msg.
CREATE OBJECT rr_msg Applikationslog-Struktur übernommen, die Instanz wird erzeugt
EXPORTING is_msg = ls_msg. und an den Aufrufer zurückgegeben.
ENDMETHOD.
Abschließend benötigen wir eine Methode zum Auslesen der Nach- Nachricht auslesen
Listing 7.6 Coding der Methode CREATE_SYMSG
richt. Legen Sie die öffentliche Instanzmethode GET_MSG an. Die Para-
meter entnehmen Sie Abbildung 7.9, die Implementierung Listing 7.8.
Die zuvor über den MESSAGE-Befehl erzeugte Nachricht wird aus
den Feldern der Struktur SY in die Nachrichtenstruktur übertra-
gen. Mit der Nachrichtenstruktur erzeugen Sie dann die Instanz
und geben diese an den Aufrufer zurück.
Methode Die zweite Zugriffsmethode nimmt das Ergebnis eines BAPI-Aufrufs
CREATE_BAPIRET2 entgegen und erzeugt dazu eine Instanz. BAPIs geben ihr Ergebnis Abbildung 7.9 Parameter GET_MSG
258 259
7 7.4
Mit dem Applikationslog arbeiten Persistente Protokolle
METHOD get_msg. TYPES
rs_msg = me->gs_msg. : BEGIN OF gys_inst,
ENDMETHOD. tiknr TYPE zbook_ticket_nr,
o_inst TYPE REF TO zcl_book_ticket_log,
Listing 7.8 Methode GET_MSG implementieren
END OF gys_inst,
gyt_inst TYPE HASHED TABLE OF gys_inst
Sie haben nun eine Klasse angelegt, deren Instanzen jeweils eine WITH UNIQUE KEY tiknr.
Nachricht speichern. Die Instanzerzeugung erfolgt über zwei Zugriffs-
Listing 7.9 Lokale Typdefinitionen der Protokollklasse
methoden, die die Nachricht aus unterschiedlichen Quellen lesen.
Sie legen damit einen Tabellentyp an, auf den im nächsten Schritt
Protokollklasse ein statisches Attribut als Instanzenpuffer typisiert wird.
Klasse anlegen Die Protokollklasse bildet das Applikationsprotokoll ab. Sie müssen 4. Legen Sie die Attribute der Klasse gemäß Abbildung 7.11 an:
dazu eine Instanz zu jedem Ticket erzeugen, was wiederum nur aus – TIKNR: Dieses Attribut enthält die Nummer des Tickets, zu dem
der Klasse selbst möglich ist. das Protokoll angelegt wurde.
1.Starten Sie Transaktion SE24. Geben Sie im Feld Objekttyp – LOGNR: Dies ist die Nummer, unter der das Protokoll auf der
»ZCL_BOOK_TICKET_LOG« ein, und drücken Sie (F5). Datenbank abgespeichert wurde.
2.Sie gelangen in den Dialog Anlegen Klasse, in dem Sie die Einstel- – LOG_HANDLE: Mit diesem Handle können die API-Bausteine auf
das Protokoll zugreifen.
lungen aus Abbildung 7.10 vornehmen und mit (¢) bestätigen.
Achten Sie auch hier darauf, dass die Instanzerzeugung auf 0 Pri- – T_INST: Tabelle der bereits erzeugten Protokollinstanzen. Die
vate gestellt ist. Auf diese Weise ist es nur der Klasse selbst mög- Factory-Methode wird diese Tabelle nutzen, um festzustellen,
lich, Instanzen von sich zu erzeugen. ob bereits eine Instanz zu einem gegebenen Ticket vorhanden
ist, und diese zurückgeben bzw. eine neue Instanz anlegen und
in dieser Tabelle eintragen.
– CONTROL_HANDLE: Die Ausgabe der Nachrichten wird in diesem
Beispiel über einen neuen Funktionsbaustein gesteuert, der
eine Ausgabe in einem beliebigen GUI-Container gestattet. Um
diese Ausgabe zu steuern, benötigen wir dieses weitere Handle.
– R_CONTAINER: Dieses Attribut ist die Referenz auf den GUI-Con-
tainer, in dem die Ausgabe erfolgen soll.
– STATUS: Dieses Attribut speichert den Status der zum Protokoll
gehörenden Tickets. Es wird erst später benötigt, kann aber hier
bereits angelegt werden.
Abbildung 7.10 Eigenschaften der Protokollklasse
3.Klicken Sie auf Lokale Typen, bzw. drücken Sie (Strg)+(F5), um
die Tabellentypen der Protokollklasse lokal zu definieren. Fügen
Sie das Coding aus Listing 7.9 ein:
Abbildung 7.11 Attribute der Protokollklasse
260 261
7 7.4
Mit dem Applikationslog arbeiten Persistente Protokolle
5.Legen Sie einen Konstruktor an, und parametrisieren Sie diesen READ TABLE lt_logheader INTO ls_logheader
wie in Abbildung 7.12. INDEX 1.
APPEND ls_logheader-lognumber TO lt_lognumber.
CALL FUNCTION 'BAL_DB_LOAD'
EXPORTING
i_t_lognumber = lt_lognumber
IMPORTING
e_t_log_handle = lt_log_handle.
Abbildung 7.12 Parameter des Konstruktors READ TABLE lt_log_handle INTO me->log_handle INDEX 1.
ELSE.
6.Implementieren Sie den Konstruktor, wie in Listing 7.10 gezeigt. CALL FUNCTION 'BAL_LOG_CREATE'
EXPORTING
METHOD constructor.
i_s_log = ls_log
DATA lt_lognumber TYPE bal_t_logn.
IMPORTING
DATA lt_log_handle TYPE bal_t_logh.
e_log_handle = me->log_handle.
DATA ls_lfil TYPE bal_s_lfil.
ENDIF.
DATA ls_extn TYPE bal_s_extn.
DATA ls_obj TYPE bal_s_obj.
SELECT SINGLE status
DATA ls_sub TYPE bal_s_sub.
FROM zbook_ticket
DATA lt_logheader TYPE balhdr_t.
INTO me->status
DATA ls_logheader TYPE balhdr.
WHERE tiknr = me->tiknr.
DATA ls_log TYPE bal_s_log.
ENDMETHOD.
me->tiknr = iv_tiknr.
Listing 7.10 Konstruktor der Protokollklasse implementieren
ls_log-object = 'ZBOOK'.
ls_log-subobject = 'ZTICKET'.
Um das Protokoll zum Ticket zu finden, wird der Funktionsbaustein
ls_log-extnumber = me->tiknr.
BAL_DB_SEARCH benutzt. (Nähere Informationen zur Verwendung die-
ls_extn-sign = ls_obj-sign
ses Bausteins finden Sie in Abschnitt 7.8, »Erweiterte Möglichkeiten
= ls_sub-sign = 'I'.
ls_extn-option = ls_obj-option des Applikationslogs«.) Wurde bereits ein Protokoll zum Ticket er-
= ls_sub-option = 'EQ'. zeugt (d.h., der Baustein liefert ein Protokoll zurück), kann dieses
ls_extn-low = ls_log-extnumber. direkt mit dem API-Baustein BAL_DB_LOAD geöffnet werden. Ansons-
ls_obj-low = ls_log-object.
ten wird das Protokoll mit dem API-Baustein BAL_LOG_CREATE neu
ls_sub-low = ls_log-subobject.
erzeugt. Diesen Baustein kennen Sie bereits aus dem ersten einfachen
APPEND
Beispiel. An dieser Stelle werden dem Baustein jedoch nicht nur eine
: ls_extn TO ls_lfil-extnumber
, ls_obj TO ls_lfil-object externe Identifikation, sondern zusätzlich auch das in Abschnitt
, ls_sub TO ls_lfil-subobject 7.4.1, »Objekt und Unterobjekt anlegen«, angelegte Objekt und Un-
. terobjekt übergeben. Dies bewirkt, dass das Protokoll in der Daten-
CALL FUNCTION 'BAL_DB_SEARCH'
bank abgelegt werden kann.
EXPORTING
i_s_log_filter = ls_lfil Das vom jeweiligen Baustein zurückgelieferte Protokoll-Handle wird
IMPORTING in beiden Fällen in das Instanzattribut LOG_HANDLE übernommen. Als
e_t_log_header = lt_logheader.
Resultat befinden sich alle für den Zugriff auf das Protokoll benötig-
ten Daten in den Attributen der Instanz.
IF NOT lt_logheader IS INITIAL.
262 263
7 7.4
Mit dem Applikationslog arbeiten Persistente Protokolle
Methode Legen Sie anschließend die öffentliche statische Methode GET_
GET_INSTANCE INSTANCE an. Diese wird als Factory-Methode der Klasse dienen und
damit in der Lage sein, Instanzen der Klasse anzulegen und an den
Aufrufer zu liefern. Parametrisieren Sie die Methode wie in Abbil-
dung 7.13.
Abbildung 7.14 Parameter ADD_MSG
Implementieren Sie die Methode, wie in Listing 7.12 gezeigt.
METHOD add_msg.
DATA ls_msg TYPE bal_s_msg.
ls_msg = ir_msg->get_msg( ).
CALL FUNCTION 'BAL_LOG_MSG_ADD'
Abbildung 7.13 Parameter der Methode GET_INSTANCE
EXPORTING
i_log_handle = me->log_handle
Implementieren Sie die Methode GET_INSTANCE, wie in Listing 7.11 i_s_msg = ls_msg.
gezeigt. ENDMETHOD.
Listing 7.12 Methode ADD_MSG implementieren
METHOD get_instance.
DATA ls_inst TYPE gys_inst.
READ TABLE t_inst INTO ls_inst Die Methode liest die Nachricht aus der übergebenen Nachrich-
WITH TABLE KEY teninstanz und fügt sie mit dem API-Baustein BAL_LOG_MSG_ADD dem
tiknr = iv_tiknr. Protokoll hinzu.
IF sy-subrc <> 0.
CREATE OBJECT ls_inst-o_inst Legen Sie die öffentliche Instanzmethode SAVE an, die es ermögli- Methode
EXPORTING chen wird, das Protokoll zu speichern. Die Methode benötigt keine SAVE anlegen
iv_tiknr = iv_tiknr. Parameter. Implementieren Sie die Methode wie in Listing 7.13.
ls_inst-tiknr = iv_tiknr.
INSERT ls_inst INTO TABLE t_inst. METHOD save.
DATA lt_log_handle TYPE bal_t_logh.
ENDIF.
DATA lt_log_nrs TYPE bal_t_lgnm.
ro_log = ls_inst-o_inst.
DATA ls_log_nrs TYPE bal_s_lgnm.
ENDMETHOD.
Listing 7.11 Methode GET_INSTANCE der Protokollklasse implementieren APPEND me->log_handle TO lt_log_handle.
CALL FUNCTION 'BAL_DB_SAVE'
Die Methode versucht, die benötigte Instanz zunächst in der Instan- EXPORTING
i_t_log_handle = lt_log_handle
zentabelle zu finden. War die Suche nicht erfolgreich, wird die In-
IMPORTING
stanz angelegt und in der Instanzentabelle eingetragen. Die Referenz
e_new_lognumbers = lt_log_nrs.
auf die gewünschte Instanz wird dann an den Aufrufer zurückge- IF me->lognr IS INITIAL.
geben. READ TABLE lt_log_nrs INTO ls_log_nrs
INDEX 1.
Methode Legen Sie außerdem die öffentliche Instanzmethode ADD_MSG an.
me->lognr = ls_log_nrs-lognumber.
ADD_MSG anlegen Diese Methode wird eine Nachricht entgegennehmen und dem Pro- ENDIF.
tokoll hinzufügen. Parametrisieren Sie die Methode wie in Abbil- ENDMETHOD.
dung 7.14.
Listing 7.13 Methode SAVE implementieren
264 265
7 7.4
Mit dem Applikationslog arbeiten Persistente Protokolle
An dieser Stelle wird der API-Baustein BAL_DB_SAVE verwendet. Die- ENDIF.
ENDMETHOD.
ser nimmt eine Tabelle mit Protokoll-Handles entgegen und spei-
chert die zugehörigen Protokolle in der Datenbank. Wurde das Pro- Listing 7.14 Methode DISPLAY implementieren
tokoll neu erzeugt, wird die neu vergebene Protokollnummer in dem
entsprechenden Instanzattribut und in der Tickettabelle abgelegt. Für die erste Ausgabe (CONTROL_HANDLE ist noch nicht gesetzt) wird Methode aufrufen
hier der Funktionsbaustein BAL_CNTL_CREATE verwendet, dem der
Methode SET_ Legen Sie als Nächstes die öffentliche statische Methode SET_
zuvor mittels SET_CONTAINER übergebene GUI-Container sowie das
CONTAINER CONTAINER an. Über diese Methode wird der GUI-Container gesetzt,
Nachrichten-Handle übergeben werden. Der Baustein gibt das Con-
in dem die Ausgabe erfolgen soll. Parametrisieren Sie die Methode
trol-Handle zurück, das im entsprechenden statischen Attribut
wie in Abbildung 7.15.
gespeichert wird. Bei jedem weiteren Aufruf der Methode (CONTROL_
HANDLE ist gesetzt) wird die Ausgabe mit dem Baustein BAL_CNTL_
REFRESH mit den Nachrichten der jeweiligen Instanz aufgefrischt.
Der Quellcode-Ausschnitt in Listing 7.15 demonstriert die Ausfüh- Zugriffsklassen
rung der Nachrichten und der Kontrollklasse. ausführen
Abbildung 7.15 Parameter SET_CONTAINER DATA gr_log TYPE REF TO zcl_book_ticket_log.
DATA gr_msg TYPE REF TO zcl_book_ticket_log_msg.
Implementieren Sie die Methode wie folgt: DATA gv_status TYPE zbook_ticket_status.
DATA gv_msg TYPE string.
METHOD set_container. DATA gr_cont TYPE REF TO cl_gui_custom_container.
r_container = ir_container.
ENDMETHOD. PARAMETERS:
p_tiknr TYPE zbook_ticket_nr OBLIGATORY,
Methode DISPLAY Legen Sie die öffentliche Instanzmethode DISPLAY an, die keine Para-
p_status TYPE zbook_ticket_status OBLIGATORY.
meter benötigt. Bei Aufruf der Methode wird das Protokoll in dem
[...]
zuvor mittels SET_CONTAINER gesetzten GUI-Container angezeigt. Lis- gr_log = zcl_book_ticket_log=>get_instance(
ting 7.14 zeigt die Implementierung der Methode. iv_tiknr = p_tiknr).
MESSAGE i000 WITH p_tiknr gv_status p_status
METHOD display. INTO gv_msg.
DATA lt_log_handle TYPE bal_t_logh. gr_msg = zcl_book_ticket_log_msg=>create_symsg( ).
gr_log->add_msg( ir_msg = gr_msg).
APPEND me->log_handle TO lt_log_handle. gr_log->save( ).
IF control_handle IS INITIAL. COMMIT WORK.
CALL FUNCTION 'BAL_CNTL_CREATE' gr_log->set_container( gr_cont ).
EXPORTING gr_log->display().
i_container = me->r_container
Listing 7.15 Einsatz der Applikationslog-Klassen
i_t_log_handle = lt_log_handle
IMPORTING
e_control_handle = control_handle.
Command Chaining ab SAP NetWeaver 7.02
ELSE.
CALL FUNCTION 'BAL_CNTL_REFRESH' In Listing 7.15 wird zunächst eine Instanz der Nachrichtenklasse erzeugt
EXPORTING und die Referenz in einem zweiten Schritt an das Protokoll übergeben.
i_control_handle = control_handle Mit dem ab SAP-NetWeaver-Release 7.02 verfügbaren Command Chai-
i_t_log_handle = lt_log_handle. ning (Verkettung von Programmierbefehlen) kann auf die Referenzvaria-
ble GR_MSG verzichtet werden.
266 267