Kontakt

Ansicht
Dokumentation

BAL_CH_DATA -

BAL_CH_DATA -

BAL Application Log Documentation   BAL Application Log Documentation  
This documentation is copyright by SAP AG.
SAP E-Book

|-----------------------------------------------------------------------

---------------|
| Which data can be logged? |
|--------------------------------------------------------------------------------------|

Overview
======================================================================

The Application Log logs message data as described below.

Function modules
BAL_LOG_CREATE Create log with header data
BAL_LOG_MSG_ADD Log a message
BAL_LOG_EXCEPTION_ADD Add an exception to the log

Types:
BAL_S_LOG Log header data
BAL_S_MSG Message data
BAL_S_EXC Contains the data for an exception
BAL_S_CONT Message/log header context
BAL_S_PARM Message/log header parameters

Example program
Report SBAL_DEMO_02 simulates a flight check and outputs a result log.
==>SBAL_DEMO_02 ==>SBAL_DEMO_02 coding

Log header
=======================================================================

Application Log opens a log with BAL_LOG_CREATE. The header data is in the structure BAL_S_LOG as follows:

  • OBJECT, SUBOBJECT

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 are normed (CHAR20) application or subapplication codes which you can set with the transaction SLG0 (example: OBJECT = "FREIGHT_COSTS" (freight costs), SUBOBJECT = "SETTLEMENT" (settlement)).
These are optional in the log header at runtime, but they must be present when you save (with the function module BAL_DB_SAVE).

  • EXTNUMBER

The external ID in the log header (CHAR100) is a free text description of the log by the application.
It could be used to link an application object to a log, by putting the application object document number in the external log ID.
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").

  • ALDATE, ALTIME, ALUSER , ALTCODE, ALPROG, ALMODE
    Further log header log creation information: date, time, user (ALDATE, ALTIME, ALUSER), the transaction or program which created the log (ALTCODE, ALPROG), and the processing mode in which the log was created (online, background, etc.)(ALMODE).
  • ALCHDATE, ALCHTIME, ALCHUSER
    If an existing log in the database is changed later, the user, date and time are recorded in ALCHDATE, ALCHTIME and ALCHUSER.
  • 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. See here for more about deleting logs.
  • ALSTATE
    Logs also have a status which specifies whether a log is finished or not. It is only for information and is not used.
  • PARAMS: PARAMS-T_PAR, PARAMS-ALTEXT, PARAMS-CALLBACK
    Log header parameters

==>Note 1
When you read a log header with BAL_LOG_HDR_READ, you get additional information which is not in BAL_S_LOG, because it is generated internally, e.g. the internal LOGNUMBER, the number of A, E, W, I and S messages, and the highest problem class which occurred.

==>Note 2
Application Log used to open logs at runtime by specifying the Application Log object and subobject, so logs were identified at runtime by OBJECT/SUBOBJECT and there could only be one log for one OBJECT/SUBOBJECT.
This restriction no longer applies. A log is identified by a handle and OBJECT/SUBOBJECT are only log attributes.

Message
=======================================================================

Messages which Application Log can log with the function module BAL_LOG_MSG_ADD have the structure BAL_S_MSG, which has the following forms:

  • MSGTY, MSGID, MSGNO, MSGV1, MSGV2, MSGV3, MSGV4
    T100 message data.
    The fields message type (MSGTY), work area ( MSGID), and error number (MSGNO) are required, the fields for the four message variables MSGV1 to MSGV4 are optional.
  • PROBCLASS, DETLEVEL, ALSORT, TIME_STMP
    These are T100 message attributes such as problem class (PROBCLASS, "very serious", for example), level of detail (DETLEVEL, between 1 and 9), sort criterion (ALSORT, any) and time stamp (TIME_STMP). These fields (except TIME_STMP) can be used in the log display.
  • MSG_COUNT
    If a message is cumulated, the cumulation value can be put in MSG_COUNT, which is incremented when BAL_LOG_MSG_CUMULATE adds more messages to it.
  • PARAMS: PARAMS-T_PAR, PARAMS-ALTEXT, PARAMS-CALLBACK
    Message parameters

Context
=======================================================================


A message or log header is often only meaningful in context.
The Aplication Log provides a context.

Example:
The message 'Credit limit exceeded for customer ABC' is meaningful in dialog because it appears while a particular document is being processed, but the log should also contain the document number. This information may be in the message variables, but this can cause problems in detailed context information (e.g. order number, item number, schedule line number, etc.).

This context information can be passed with a message (or log header) to the Application Log in a DDIC structure (maximum length 256 bytes). You pass the name of the DDIC structure in CONTEXT-TABNAME and its contents in CONTEXT-VALUE for later display.

Example:
====================================================================
DATA:
l_s_msg TYPE bal_s_msg,
l_s_my_context type my_ddic_structure.

* Message 123(XY): 'Credit limit exceeded for customer &1'.
l_s_msg-msgty = 'E'.
l_s_msg-msgid = 'XY'.
l_s_msg-msgno = '123'.
l_s_msg-msgv1 = 'ABC'.
* Add document number to message as context:
l_s_my_context-document = '3000012345'.
l_s_msg-context-tabname = 'MY_DDIC_STRUCTURE'.
l_s_msg-context-value = l_s_my_context.
* Log message
CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
i_s_msg = l_s_msg
EXCEPTIONS
others = 1.
====================================================================

Note:
The line
l_s_msg-context-value = l_s_my_context.
causes a syntax error in unicode if the context contains fields that are not of character type (for example, INTEGER).
It is therefore recommended that in this context you only use fields of character type (subsequent conversion is possible, old context information on the database is converted automatically when it is read).
If fields that are not of character type must be used in this context,
the line above can be replaced by:
FIELD-SYMBOLS:
TYPE c.
ASSIGN l_s_my_context TO CASTING.
l_s_msg-context-value = .

Parameters
=======================================================================


The Application Log can contain message header and message detail display parameter information, which can be used in two ways:

  • As "extended long text"
    If the T100 message long text is not sufficient because more than the 4 message variables are needed, you can enter an additional 'Text in Dialog' containing any number of place holders, which are passed in the table PARAMS-T_PAR, in the field PARAMS-ALTEXT, with transaction SE61.
    The form routine MSG_ADD_WITH_EXTENDED_LONGTEXT in the program SBAL_DEMO_02 contains an example.
  • As callback routine
    If you specify a callback routine to display your own detail information, in PARAMS-CALLBACK, it is called in the detail display.

An Application Log callback routine can be realized in two ways:
as a FORM routine or as a function module
The following fields must be specified to setup a callback routine:
USEREXITT: Routine type (' ' = FORM, 'F' = function module)
USEREXITP: Program containing the routine (only for FORM)
USEREXITF: Routine name (form routine or function module name)
A function module must be parameterized like a form routine (USING is replaced by IMPORTING). The same parameter names must be used.

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:

  • EXCEPTION

The exception class from which an exception text is to be added to the log is specified in the Exception field. This field has to be filled when an exception is added to the log.

When exception data is read with BAL_LOG_EXCEPTION_READ, the exception data is returned in the parameter E_S_EXC with the structure BAL_S_EXCR.

  • MSGTY

The Message Type field refers to the classic data of a T100 message (MSGTY). It should also be filled for exceptions.

  • PROBCLASS, DETLEVEL, ALSORT, TIME_STMP

Relates to the attributes of a message or exception, such as the problem class (PROBCLASS, for example, "Very important "), detail level (DETLEVEL, values from 1 to 9), sort criterion (ALSORT, any can be used) and time stamp (TIME_STMP). These fields can be used in the log display (apart from TIME_STMP).

  • MSG_COUNT

This attribute is not used for exceptions.

No context information or parameters can be stored for an exception.






Vendor Master (General Section)   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

Length: 13640 Date: 20240510 Time: 025621     sap01-206 ( 211 ms )