Global Class and Method for Application Log

The goal of the object is to create the Global Class and Method for Application Log so that it can be reused where necessary in any RICEF object.

Application Log provides an infrastructure for collecting messages and exceptions in a log, saving, reading and deleting logs in the database and displaying them.

Application Log provides multiple advantages:

System-wide uniform event logging
Accessible standardized UI based on ABAP List Viewer (ALV)
High capabilities for analysis of log data

Application logging records the progress of the execution of an application. Whereas the system log records system events, you can use the application log to record application-specific events.

Application Log is designed to temporarily store messages. Logs should be deleted in intervals (e.g. weekly batch job for deleting logs) to avoid too high database load.

A typical use of the Application Log is within delivery processing. Negative results of a dangerous goods check are written to the Application Log. Application messages and reactions are collected based on a customer defined examination schema (reactions determine how the document will be handled further). This approach increases the transparency of the process for end users. Messages are collected temporarily and are not saved to the database.

First create object and sub object, Go to transaction SLG0.

Go to change mode and click on New entries button on the application tool bar.

Then define the sub object for the object.

Select the object and double click on sub object.

Create Global Class and Method to define the Application log code

Define the following Parameter in Method

Define following Data in the Method

Populate the Header data with the following details

Create the log with FM BAL_LOG_CREATE

Add all the message in the log using FM BAL_LOG_MSG_ADD

Save the Log using FM BAL_DB_SAVE

Display the log using FM BAL_DSP_LOG_DISPLAY

Define that Class and method in the code wherever necessary

The Method will create log with all the messages and generate log (Transaction SLG1)

Code is attached.

Christian Dr. Drumm May 8, 2014 at 6:24 am

Hi Debopriya,

creating an OO wrapper for the functions modules of the application log is a good idea. I guess it’s one of the classes most development organizations have build themselfs in one way or the other.

However, the version of an OO wrapper for the application log you presented isn’t suitable for reuse. Furthermore, it is not even an OO implemention, but rather a PERFORM disguised as a method. You could, for example, simply make this method static as no attributes of the class are used. If you really want to implemente a reusable OO API for the application log you should consider the following:

Create a class with the attributes object and sub-object and log handle
provide a constructor the instantiates the class using object and sub-object as a parameter and sets the log handle
provide methods for logging exceptions, logging messages, logging messages in a message table, logging messages in the BAPIRET2 structures, logging additional data….
create a separate class to collect methods related to displaying the application log

Using such a class as a basis, you could implement the method you presented here using just a few message calls. Furthermore you’d really have a reusable API for the application logs.

In summary, it is a pity, that SAP doesn’t provide a clean OO API for the application log out of the box and forces customers to develop such an API themself.

Best,

Christian

like (0)

4 Comments

You must be Logged on to comment or reply to a post.

Christian Dr. Drumm May 8, 2014 at 6:24 am
Hi Debopriya,

creating an OO wrapper for the functions modules of the application log is a good idea. I guess it’s one of the classes most development organizations have build themselfs in one way or the other.

However, the version of an OO wrapper for the application log you presented isn’t suitable for reuse. Furthermore, it is not even an OO implemention, but rather a PERFORM disguised as a method. You could, for example, simply make this method static as no attributes of the class are used. If you really want to implemente a reusable OO API for the application log you should consider the following:

Create a class with the attributes object and sub-object and log handle

provide a constructor the instantiates the class using object and sub-object as a parameter and sets the log handle

provide methods for logging exceptions, logging messages, logging messages in a message table, logging messages in the BAPIRET2 structures, logging additional data….

create a separate class to collect methods related to displaying the application log

Using such a class as a basis, you could implement the method you presented here using just a few message calls. Furthermore you’d really have a reusable API for the application logs.

In summary, it is a pity, that SAP doesn’t provide a clean OO API for the application log out of the box and forces customers to develop such an API themself.

Best,

Christian
like (0)
1. Debopriya Ghosh Post authorMay 8, 2014 at 8:05 am
  
  Hi Christian,
  
  Thanks a lot for the suggestion.
  
  Will come up with the new version as you said.
  
  BR
  
  Debopriya Ghosh
  
  like (0)
Suhas Saha May 8, 2014 at 4:42 pm

Why do you want to re-invent the wheel?

IF_RECA_MESSAGE_LIST is the most robust message handling API i have used until now. I know that it is not in the SAP_BASIS component & but you can build your custom framework based on it.

– Suhas

like (0)
1. Debopriya Ghosh Post authorMay 9, 2014 at 4:12 am
  
  Hi Suhas,
  
  Thanks a lot for the suggestions.
  
  BR
  
  Debopriya Ghosh
  
  like (0)