Welche Daten können gesammelt werden?

Das Application Log sammelt Meldungen und faßt diese zu Protokollen zusammen. Im folgenden wird erläutert, welche Daten vom Application Log gesammelt werden können.

Funktionsbaustein	Verwendung
BAL_LOG_CREATE	Protokoll anlegen mit Kopfdaten
BAL_LOG_MSG_ADD	Eine Meldung dem Protokoll hinzufügen
BAL_LOG_EXCEPTION_ADD	Eine Ausnahme dem Protokoll hinzufügen

Typen	Verwendung
BAL_S_LOG	Enthält die Protokollkopfdaten
BAL_S_MSG	Enthält die Daten einer Meldung
BAL_S_EXC	Enthält die Daten einer Ausnahme
BAL_S_CONT BAL_S_CONT	Kontext zur Meldung/Protokollkopf
BAL_S_PARM BAL_S_PARM	Parameter zur Meldung/zum Protokollkopf

Beispiel

Das Programm SBAL_DEMO_02 simuliert die Überprüfung eines Fluges. Im ausgegebenen Protokoll wird das Ergebnis der Prüfung angezeigt.

Ende des Beispiels.

Vorgehensweise

Protokollkopf

Ein Protokoll im Application Log wird mit dem Funktionsbaustein BAL_LOG_CREATE eröffnet, wobei die Kopfdaten in der Struktur BAL_S_LOG mitgegeben werden.

Die Daten dieser Struktur sehen wie folgt aus:

Daten der Struktur BAL_S_LOG	Verwendung
OBJECT, SUBOBJECT	Das Application Log wird von den unterschiedlichsten Applikationen genutzt. Damit eine Anwendung die von ihr geschriebenen Protokolle effizient wiederfinden kann, besitzt jedes Protokoll im Protokollkopf die Attribute OBJECT und SUBOBJECT. Diese Attribute (CHAR20) charakterisieren die jeweilige Applikation bzw. Unter-Applikation. Sie können mit der Transaktion SLG0 eingerichtet werden. Beispiel OBJECT = "FREIGHT_COSTS" (Frachtkosten), SUBOBJECT = "SETTLEMENT" (Abrechnung) Ende des Beispiels. Achtung Diese Angaben sind zur Laufzeit zunächst optional, beim Sichern (mit dem Funktionsbaustein BAL_DB_SAVE) hingegen müssen OBJECT (und ggf. SUBOBJECT) vorhanden sein. Ende der Warnung.
EXTNUMBER	Externe Identifikation im Protokollkopf (CHAR100), die von der Applikation frei definierbar ist. Sie charakterisiert ein Protokoll. Beispiel Sie kann dazu genutzt werden, eine Verbindung zwischen einem Anwendungs-Objekt und einem Protokoll herzustellen. Hierbei stellen Sie die Belegnummer des Anwendungsobjektes in die externe Identifikation des Protokolls. Ende des Beispiels. Es ist auch möglich, über eine externe Identifikation mehrere Protokolle zu einem logischen Protokoll zusammenzufassen (die Anzeige von Protokollen kann protokollübergreifend arbeiten). Auf der Datenbank liegt ein Index auf den Feldern OBJECT/SUBOBJECT/EXTNUMBER, so daß bei Angabe dieser Felder ein Protokoll effizient von der Datenbank gelesen werden kann (d.h. kein Full Table Scan).
ALDATE, ALTIME, ALUSER , ALTCODE, ALPROG, ALMODE	Weitere Daten des Protokollkopfes, die Informationen geben, wie das Protokoll angelegt wurde. Dies sind Datum, Uhrzeit und Benutzer (ALDATE, ALTIME, ALUSER) sowie Transaktion bzw. Programm, mit der das Protokoll erzeugt wurde (ALTCODE, ALPROG). Auch der Betriebsmodus, in dem das Protokoll erzeugt wurde, wird in ALMODE festgehalten (also Online, Hintergrund, etc.).
ALCHDATE, ALCHTIME, ALCHUSER	Falls ein bereits auf der Datenbank existierendes Protokoll später noch verändert wird, wird Benutzer, Datum und Uhrzeit in den Feldern ALCHDATE, ALCHTIME und ALCHUSER festgehalten.
DATE_DEL, DEL_BEFORE	Ein Protokoll besitzt ein Verfalldatum (DATE_DEL), nach dem es gelöscht werden darf und ein Flag (DEL_BEFORE), daß ein Löschen vor diesem Datum explizit verbietet. Weitere Informationen finden Sie unter der Funktionsbausteindokumentation BAL_DB_DELETE.
ALSTATE	Ein Protokoll besitzt einen Status, der beschreibt, ob ein Protokoll erledigt ist oder nicht. Dieses Flag hat nur Dokumentationscharakter, es wird nirgends ausgewertet.
CONTEXT: CONTEXT-TABNAME, CONTEXT-VALUE	Kontext zu einem Protokollkopf
PARAMS: PARAMS-T_PAR, PARAMS-ALTEXT, PARAMS-CALLBACK	Parameter zu einem Protokollkopf

Hinweis Hinweis

Beim Lesen eines Protokollkopfes mit dem Funktionsbaustein BAL_LOG_HDR_READ erhalten Sie noch weitere Informationen, die nicht in BAL_S_LOG stehen, da diese Daten nicht von außen vorgebbar sind. Dies sind z.B. die interne LOGNUMBER, die Anzahl von Meldung, von A-, E. W, I- und S-Meldungen sowie die höchste aufgetretene Problemklasse.

Ende des Hinweises

Meldung

Eine Meldung, die vom Application Log mit dem Funktionsbaustein BAL_LOG_MSG_ADD gesammelt werden kann, wird durch die Struktur BAL_S_MSG repräsentiert. Diese kann in verschiedenen Ausprägungen genutzt werden, die im folgenden erläutert werden:

Daten der Struktur BAL_S_MSG	Verwendung
MSGTY, MSGID, MSGNO, MSGV1, MSGV2, MSGV3, MSGV4	Klassischen Daten einer T100-Meldung. Die Felder Message-Typ (MSGTY), Arbeitsgebiet (MSGID), Fehlernummer (MSGNO) müssen gefüllt werden, optional die Felder für die vier Message-Variablen MSGV1 bis MSGV4.
PROBCLASS, DETLEVEL, ALSORT, TIME_STMP	Attribute zur T100-Meldung wie die Problemklasse (PROBCLASS, z.B. "sehr wichtig"), Detaillierungslevel (DETLEVEL, Werte von 1 bis 9), Sortierkriterium (ALSORT, beliebig nutzbar) und Zeitstempel (TIME_STMP). Diese Felder können in der Protokollanzeige genutzt werden (bis auf TIME_STMP).
MSG_COUNT	Ist eine Meldung kumuliert worden, dann kann dieser Kumulationswert in MSG_COUNT hinterlegt werden. Dieser Wert wird weiter erhöht, wenn mit dem Funktionsbaustein BAL_LOG_MSG_CUMULATE weitere Meldungen zu dieser hinzugefügt werden.
CONTEXT: CONTEXT-TABNAME, CONTEXT-VALUE	Kontext zu einer Meldung
PARAMS: PARAMS-T_PAR, PARAMS-ALTEXT, PARAMS-CALLBACK	Parameter zu einer Meldung

Kontext

Eine Meldung oder ein Protokollkopf ist oftmals nur aussagekräftig, wenn einige zusätzliche Informationen mitgegeben werden. Dazu benutzen Sie im Application Log den sogenannten Kontext.

Beispiel

Die Meldung 'Für Kunde ABC wird das Kreditlimit überschritten' ist im Dialog aussagekräftig, da man sich ja in der Bearbeitung eines bestimmten Beleges befindet. Im Protokoll hingegen sollte die Belegnummer auch ersichtlich sein. Diese Information können Sie zwar in die Message-Variablen stecken, diese führt aber bei detaillierteren Umfeld-Informationen zu Problemen (z.B. Auftragsnummer, Positionsnummer, Einteilungsnummer, etc.).

Diese Kontext-Informationen können daher bei einer Meldung (oder einem Protokollkopf) im Application Log mitgegeben werden. Zu diesem Zweck müssen Sie eine DDIC-Struktur definieren, die die gewünschten Kontext-Informationen enthält (maximale Länge 256 Byte). Im Feld CONTEXT geben Sie den Namen der DDIC-Struktur in CONTEXT-TABNAME mit, den Inhalt der Struktur hingegen in CONTEXT-VALUE. Die Daten des Kontextes können später problemlos zur Anzeige gebracht werden.

Ende des Beispiels.

Syntax Syntax

DATA:
l_s_msg TYPE bal_s_msg,
l_s_my_context type my_ddic_structure.

* Meldung 123(XY): 'Kreditlimit für Kunde &1 ist überschritten'. 
l_s_msg-msgty = 'E'.
l_s_msg-msgid = 'XY'.
l_s_msg-msgno = '123'.
l_s_msg-msgv1 = 'ABC'.

* Belegnummer als Kontext an die Meldung hängen:
l_s_my_context-document = '3000012345'.
l_s_msg-context-tabname = 'MY_DDIC_STRUCTURE'.
l_s_msg-context-value   = l_s_my_context.

* Meldung dem Protokoll hinzufügen
CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
i_s_msg   = l_s_msg
EXCEPTIONS
others    = 1.

Ende des Codes

Hinweis Hinweis

Die Zeile

l_s_msg-context-value = l_s_my_context.

führt unter Unicode zu einem Syntaxfehler, wenn der Kontext Felder enthält, die nicht character-artig sind (z.B. INTEGER). Es wird daher empfohlen, im Kontext nur characterartige Felder zu verwenden (auch eine nachträgliche Umstellung ist möglich, alte Kontextinformationen auf der Datenbank werden beim Lesen automatisch konvertiert).

Falls im Kontext unbedingt nicht-character-artige Felder verwendet werden müssen, kann die obige Zeile ersetzt werden durch:

FIELD-SYMBOLS:

<l_s_my_context> TYPE c.

ASSIGN l_s_my_context TO <l_s_my_context> CASTING.

l_s_msg-context-value = <l_s_my_context>.

Ende des Hinweises

Parameter

Zu einem Protokollkopf und zu einer Meldung können im Application Log noch sogenannte Parameter abgelegt werden. Diese Informationen können in der Protokollanzeige des Application Logs abgerufen werden, in dem man sich das Detail zum Protokollkopf bzw. zu einer Meldung ansieht. Diese Parameter können auf zwei verschiedene Arten genutzt werden:

Erweiterter Langtext Reicht z.B. bei einer T100-Meldung der Langtext nicht aus, weil mehr Informationen als die 4 Message-Variablen zur Erklärung benötigt werden, dann können Sie zusätzlich im Feld PARAMS-ALTEXT einen mit der Transaktion SE61 erfaßten 'Text im Dialog' angeben. Dieser Text kann beliebig viele Platzhalter enthalten, die Sie in der Tabelle PARAMS-T_PAR mitgeben. Ein Beispiel ist in der Form-Routine MSG_ADD_WITH_EXTENDED_LONGTEXT im Programm SBAL_DEMO_02 zu finden.
Callback-Routine Durch Angabe einer Callback-Routine in PARAMS-CALLBACK wird bei der Detailanzeige die vorgegeben Routine angesprungen, in der man seine eigenen Detailinformationen zur Anzeige bringen kann. Eine Callback-Routine kann bei Nutzung des Application Logs als FORM-Routine oder als Funktionsbaustein realisiert sein. Das Setzen einer Callback-Routine umfaßt daher die Angabe der folgenden Felder: USEREXITT: Art der Routine (' ' = FORM, 'F' = Funktionsbaustein) USEREXITP: Programm, in dem sie sich befindet (nur bei FORM) USEREXITF: Name der Routinen (Name der Formroutinen bzw. Funktionsbaustein)

Ausnahme

Eine Ausnahme, die vom Application Log mit dem Funktionsbaustein BAL_LOG_EXCEPTION_ADD gesammelt werden kann, wird durch die Struktur BAL_S_EXC repräsentiert. Diese kann in verschiedenen Ausprägungen genutzt werden, die im Folgenden erläutert werden:

Daten der Struktur BAL_S_EXC	Verwendung
EXCEPTION	Ausnahmeklasse, aus der dem Protokoll ein Ausnahmetext zugefügt werden soll. Dieses Feld muss gefüllt werden.
MSGTY	Message-Typ (MSGTY ) einer klassischen T100-Meldung. Dieses Feld sollte auch für Ausnahmen gefüllt werden.
PROBCLASS, DETLEVEL, ALSORT, TIME_STMP	Attribute zur Meldung bzw. Ausnahme wie die Problemklasse (PROBCLASS, z.B. "sehr wichtig"), Detaillierungslevel (DETLEVEL, Werte von 1 bis 9), Sortierkriterium (ALSORT, beliebig nutzbar) und Zeitstempel (TIME_STMP). Diese Felder können in der Protokollanzeige genutzt werden (bis auf TIME_STMP).
MSG_COUNT	Dieses Attribut wird für Ausnahmen nicht genutzt.