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.println in 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. Apparently, this is not very flexible in terms of controlling the amount of log output, the destination, and the format of the messages.
In the SAP Logging API, the messages are separated into:
· 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:
· An 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, then 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 must 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 |
Logging Manager |
A unique single manager that mainly manages the log controllers. |
Log Controller |
An entity that represents the source area. |
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:
...
1. The system can be used for both tracing and logging.
2. It takes advantage of similarities of tracing and logging, and of synergistic effects of handling both – although differences are not neglected:
...
a. Path messages for traces
b. Cross-referencing between traces and logs
c. Language-independent messages for logs.
3. The system can be configured to work with different output formats and destinations.
4. 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).
See also:
Enabling Logging for an Application