!--a11y-->
Overview 
The SAP Logging API offers high quality support for common practices in logging:
· It generates trace and log messages.
· APIs are available that combine these two types of messages together for advanced analysis. You can find these APIs in the SAP NetWeaver Developer Studio help.
· Other advanced features are available that will be covered in later sections.
Log Controller is the Java class that represents the source area. In general, you deal with its two subclasses directly:
· Category – generates log messages. An example category: “/System/Database”, “/System/Security”.
· Location – generates trace messages. An example location: “com.sap.tc”, “com.sap.tc.logging”.
For a complete class hierarchy diagram defined for the Logging API, see Appendix B.
With the Location or Category defined, you are ready to insert output methods in your code to produce messages whenever necessary. A severity level is assigned to each call.
There are a number of methods available to write messages with different severity. They can be separated in two groups, where the first group has intuitive name with severity level indicated. These methods produce messages with the respective severity incorporated in the method name. According to the severity scale shown in Appendix A, you can find, for example with Location class:
Common Output API – Group 1
Common output API with severity indicated |
fatalT(string the_message) |
errorT(string the_message) |
warningT(string the_message) |
infoT(string the_message) |
pathT(string the_message) |
debugT(string the_message) |
The second group also has intuitive names, but without explicit severity level shown in their names. The table below shows the ones that are commonly used:
Common Output API – Group 2
Common output API (mostly for program flow) |
Description |
entering() |
Denotes a method entry with level Severity.Path. Always used together with exiting(). |
exiting() |
Denotes a method exit with level Severity.Path. Always used together with entering(). |
throwing(Throwable the_exception) |
Outputs the exception content with level Severity.Warning. |
assertion(Boolean the_assertion, String the_message): |
A trace method to verify your assertion. It throws a Severity.Error message when the condition is false. |

It may first appear that there are overwhelmingly numerous methods, but they are pretty much overloaded methods with different arguments to enhance flexibility. It is better to provide more options for different requirements, rather than to provide inadequate APIs. For more information, see Enable Output Messages.
General procedures:
...
1. Identify the source area you would like to produce trace/log output.
2. Assign a severity level to the source.
3. Specify an output destination.
4. Insert messages with corresponding severity level.
5. Run the program.
The message is be produced and sent to the destination only when the severity of the message is equal to or higher than the source.
From a developer’s point of view the focus is on the steps 1 and 4 defined above. The other steps are more or less determined and configured by the operators/end-users eventually. This shows the idea of decoupling the task of enabling the logs by the developers and the program execution by the users.
...

The example below corresponds to the steps mentioned above.
1. Source area – a class fooClass under an arbitrary package com.sapmarkets.fooPackage.
2. Severity of the source – DEBUG.
a. Allow messages with severity DEBUG level or above to be printed.
3. Destination – a file.
4. Insert an informational text at the very first line of a method, that is, a fooMethod() indicating the entry point to this method, with severity PATH (higher than DEBUG).
The message text is written to the file with a standard format as shown below:
May 3, 2001 6:54:18 PM com.sapmarkets.fooPackage.FooClass.fooMethod [main] Path: Entering method |
This corresponds to:
Date and timestamp Full path method name [thread name] Severity: Message |
For more information, see Simple Example Flow.