SAP Logging API
Purpose
During the development phase, it is common practice to insert logging statement within the code to produce informative logs at the runtime, whether for troubleshooting or for analysis purposes.
Without a standard logging framework, developers are very likely to use System.out.printlnin a sporadic manner or to call printStackTrace() in the case of an exception. Before executing the code in a productive system, the cleanup of these embedded lines can be very difficult. Therefore, this is not a flexible method in terms of controlling the amount of log output, the destination, and the message format.
In the SAP Logging API, the messages are separated in two main areas:
● Logging – classical log messages, for distinguished problematic areas.
● Tracing – classical trace messages, for coding problems.
Advantages
The availability and readability of traces or event logs are very important for both the developers and the potential users. Therefore, a common logging framework must be made available to satisfy the requirements of these groups. A standardized infrastructure will be essential and beneficial for both the developers and the consumers.
This framework has the following advantages:
● Easy to use API – enabling logs is not a popular task for a developer. Therefore, the API/method calls have to be simple and intuitive.
● Performance – the switching on of the logging mechanism must not degrade the performance of the application as if running with logging.
● Easy to maintain – the log insertion done by developer is totally decoupled from executing the code.
Switching on or controlling the amount of log output is configurable at runtime without modifying the source code.
Implementation Considerations
If your goal is to pinpoint distinguished problematic logistic areas, you should focus on log messages, whereas if you are more interested in analyzing coding problems, then trace messages is the one to be used. To enable logging is a major task. What you has to do is classify the source area that needs to be logged/traced, and then insert the output messages in the code.
Integration
The figure below represents a simplified version of the conceptual view that shows the key entities defined in the SAP Logging API. A brief introduction of the terms used is given in the Terminology of Key Components table after the figure.
Conceptual View of SAP Logging Tool
Terminology of Key Components
Term |
Description |
Log Manager |
A unique single manager that mainly manages the log controllers. |
Log Controller |
A Java object you call to write log and trace messages. |
Log Record |
A structure that holds a message and its relevant data. |
Log |
Represents the destination where the message should be output. |
Formatter |
Determines the format of the final message text. |
Filter |
Optional means to further screen out messages. |
Features
The SAP Logging API provides the following functionality:
...
● The system is used for both tracing and logging.
● It takes advantage of similarities of tracing and logging, and of synergistic effects of handling both.
● Cross-referencing between traces and logs.
● Language-independent messages for logs.
● The system can be configured to work with different output formats and destinations.
● It is highly controllable, because it:
...
a. Uses a controlled inheritance to reuse settings in hierarchies of code areas and message categories.
b. Enables a relative control for message writing (for example, enables extended tracing for a classified subset of trace calls).
More Information
Enabling Logging for an Application
Typical Practice for a Better Style