Which Data Can Be Collected?
Use
The application log logs message data as described below. This section describes what data can be collected by the application log.
|
Function Module |
Use |
|---|---|
| BAL_LOG_CREATE |
Create log with header data |
| BAL_LOG_MSG_ADD |
Put message in log |
| BAL_LOG_EXCEPTION_ADD |
Put exception in log |
|
Types |
Use |
|---|---|
| BAL_S_LOG |
Contains log header data |
| BAL_S_MSG |
Contains message data |
| BAL_S_EXC |
Contains exception data |
| BAL_S_CONT BAL_S_CONT |
Message/log header context |
| BAL_S_PARM BAL_S_PARM |
Message/log header parameter |
Procedure
Log Header
The application log opens a log with the function module BAL_LOG_CREATE. The header data is passed in the structure BAL_S_LOG.
The data in this structure is:
| BAL_S_LOG structure data |
Use |
|---|---|
|
The application log is used by various applications. Every log has the attributes OBJECT and SUBOBJECT to help applications to find their logs efficiently. These attributes (CHAR20) identify the application and subapplication. They can be defined in transaction SLG0. |
| EXTNUMBER |
External ID in the log header (CHAR100), defined by the application. It identifies a log. An external ID can also combine several logs into one logical log (logical logs can be displayed like one log). The database contains an index on the fields OBJECT/SUBOBJECT/EXTNUMBER. If these fields are specified, a log can be read from the database efficiently (no "Full Table Scan"). |
|
Other log header data that specifies how the log was created. These are date, time and user (ALDATE, ALTIME, ALUSER) and the transaction or program that created the log (ALTCODE, ALPROG). The processing mode in which the log was created is in ALMODE (online, background, and so on). |
|
If an existing log in the database is changed later, the user, date and time are recorded in fields
|
| DATE_DEL, DEL_BEFORE |
Logs have an expiry date (DATE_DEL) after which they can be deleted, and a flag (DEL_BEFORE) which explicitly forbids deletion before this date. For more information, see the BAL_DB_DELETE function module documentation. |
| ALSTATE |
A log has a status specifying whether the log is finished. It is only for information and is not used anywhere. |
CONTEXT:
|
Log header context |
PARAMS:
|
Log header parameters |
Message
A message that can be collected by the application log with function module BAL_LOG_MSG_ADD is represented by the structure BAL_S_MSG. This can have various versions as described below:
| BAL_S_MSG structure data |
Use |
|---|---|
|
T100 message data. The following fields must be filled:
|
|
Attributes of T100 message, such as
|
| MSG_COUNT |
If a message is cumulated, the cumulation value can be put in MSG_COUNT. The value is incremented when more of these messages occur with the function module BAL_LOG_MSG_CUMULATE. |
CONTEXT:
|
Message context |
PARAMS:
|
Message parameters |
Context
A message or log header is often only meaningful in context. This is the application log context.
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.
Parameter
Parameters can be stored in the application log for a log header and a message. This information can be called in the Application Log display, in the log header or message details. You can use these parameters in two ways:
-
Extended long text If the long text of a T100 message is not sufficient, because you need more information than the 4 message variables, you can enter a transaction SE61 'Text in dialog' in the PARAMS-ALTEXT field. This text can contain any number of placeholders, which you pass in the tablePARAMS-T_PAR. An example is in the form routine MSG_ADD_WITH_EXTENDED_LONGTEXT in the program SBAL_DEMO_02.
-
Callback routine If you specify a callback routine in PARAMS-CALLBACK, the specified routine, in which you can display your own detail information, is called in the detail display. A callback routine can be used whether the Application Log is a FORM routine or a function module. The following fields must be specified to setup a callback routine:
- USEREXITT: Type of routine (' ' = FORM, 'F' = function module)
- USEREXITP: Program in which it is found (only for FORM)
- USEREXITF: Name of routine (name of form routine or function module)
Exception
An exception that can be collected by the application log with the function module BAL_LOG_EXCEPTION_ADD is represented by the structure BAL_S_EXC. This can have various versions as described below:
|
Data of BAL_S_EXC |
Use |
|---|---|
| EXCEPTION |
Exception class from which an exception text is added to the log. This field must be filled. |
| MSGTY |
Message type (MSGTY ) of a T100 message. This field must also be filled for exceptions |
|
Attributes of the message or exception, such as
|
| MSG_COUNT |
This attribute is not used for exceptions. |