Capturing Background Job Errors in SAP Using the Application Log (SLG0/SLG1)

[[{“value”:”

When an ABAP program runs interactively, errors can be shown directly to the user on screen — a message, a popup, an abort. But when that same report runs as a background job, there’s no one watching, and no screen to show anything on. If an error occurs, it can easily go unnoticed until someone stumbles across missing or incomplete data days later.

This is exactly the problem SAP’s Application Log framework solves. Using transactions SLG0 (to define log objects) and SLG1 (to display logs), you can capture, store, and later review errors even without an active user session. In this blog post, I’ll walk through how to set up and use the Application Log with a simple, practical example: a report that inserts student records into a custom table. The goal isn’t to build a complex business scenario — it’s to isolate the logging mechanism itself so the pattern is easy to understand and reuse in your own programs.

The Scenario

Suppose we have a custom table ZSTUDENTS with fields STUDENTID, NAME and BRANCH. We have a report that reads student data from an external source (an Excel upload, an OData call, etc.), generates sequential student IDs, and inserts the records into the table.

DATA: lt_students TYPE TABLE OF zstudents.
lt_students = ‘call the data from XL or ODATA etc’.
SELECT MAX( student_id ) FROM zstudents INTO @DATA(lv_max_studid).
IF sy-subrc <> 0 OR lv_max_studid IS INITIAL.
lv_max_studid = 0.
ENDIF.

LOOP AT lt_students ASSIGNING FIELD-SYMBOL(<ls_student>).
lv_max_studid += 1.
<ls_student>-studentid = lv_max_studid.
ENDLOOP.
INSERT zstudents FROM table lt_student.
* Check the Insertion Status
IF sy-subrc <> 0.
* here we write logic for error log
ENDIF.

When this runs interactively, a failed INSERT is easy enough to notice. When it runs as a background job overnight, we need a reliable place to record that failure — which is where the Application Log comes in.

Step 1: Set Up the Log Object in SLG0

Before writing any ABAP code, you need to define where the log entries will be stored. This is done in transaction SLG0, by creating an Object and a Sub-object:

• Object — represents the main application or process generating the log (e.g., ZSTUDENT).
• Sub-object — represents a specific part of that process, used to further categorize entries (e.g., ZINSERT).

1. Go to transaction SLG0.
2. Click New Entries, provide the Object name and a short description, and click save.

Select your Object row, double-click Sub-objects in the left dialog structure, enter your sub-object details, and save.

Once defined, these two values become the “address” your ABAP code writes to, and the filter you’ll later use in SLG1 to find your entries.

Step 2: Declare the Required Structures & Populate the Log Header

On the ABAP side, a handful of standard structures and types are used to build and manage the log:

Fill ls_log  with the object and sub-object defined in SLG0, along with the user and program creating the log:

DATA: ls_log TYPE bal_s_log,
lt_log_handle TYPE bal_t_logh,
lv_log_handle TYPE balloghndl,
ls_message TYPE bal_s_msg.

ls_log-object = ‘ZSTUDENT’.
ls_log-subobject = ‘ZINSERT’.
ls_log-aluser = sy-uname.
ls_log-alprog = sy-repid.

ls_log: stores the log header information.

 lt_log_handle: Stores one or more log handles.

lv_log_handle: stores the unique log identifier.

ls_message: stores the message details.

Step 3: Create the Log Handle

With the header populated, call BAL_LOG_CREATE to create the log and receive a handle for it:

CALL FUNCTION ‘BAL_LOG_CREATE’
EXPORTING
i_s_log = ls_log
IMPORTING
e_log_handle = lv_log_handle
EXCEPTIONS
LOG_HEADER_INCONSISTENT = 1
OTHERS = 2.
IF sy-subrc <> 0.
” If log creation fails, fallback to MESSAGE
MESSAGE ‘Unable to create application log’ TYPE ‘E’.
RETURN.
ENDIF.

This handle (lv_log_handle) is what you’ll use to attach messages to this specific log instance.

Step 4: Add an Error Message to the Log

If the INSERT fails, add a message describing the error. There are two common ways to do this.

Option A — Free text message, useful for quick, one-off messages without a dedicated message class:

CALL FUNCTION ‘BAL_LOG_MSG_ADD_FREE_TEXT’
EXPORTING
i_log_handle = lv_log_handle
i_msgty = ‘E’
i_text = |Student record could not be inserted.|
EXCEPTIONS
LOG_NOT_FOUND = 1
MSG_INCONSISTENT = 2
LOG_IS_FULL = 3
OTHERS = 4.

Option B — Message from a custom message class, which is generally preferable for reusable, translatable messages:

ls_message-msgid = ‘ZMSG’.
ls_message-msgno = ‘001’.
ls_message-msgty = ‘E’.
ls_message-msgv1 = ‘Student ID already exists’.
CALL FUNCTION ‘BAL_LOG_MSG_ADD’
EXPORTING i_log_handle = lv_log_handle
i_s_msg = ls_message.APPEND lv_log_handle TO lt_log_handle.

Step 5: Save the Log to the Database

Adding messages only builds the log in memory — it still needs to be persisted so it can be viewed later. Append the handle to the log handle table, then call BAL_DB_SAVE:

CALL FUNCTION ‘BAL_DB_SAVE’
EXPORTING i_save_all = abap_true
i_t_log_handle = lt_log_handle
EXCEPTIONS
LOG_NOT_FOUND = 1
SAVE_NOT_ALLOWED = 2
NUMBERING_ERROR = 3
OTHERS = 4.
IF sy-subrc <> 0.
” If save fails, show fallback message
MESSAGE ‘Failed to save application log’ TYPE ‘E’.
RETURN.
ENDIF.

Once saved, the log entry is permanently stored in the database tables behind SLG1 and can be retrieved at any time — regardless of whether the job that created it is still running.

Step 6: Schedule and Review

With the logging logic in place, schedule the report as a background job via SM36. If an error occurs during execution, it will no longer disappear silently — it will be visible in SLG1, filtered by the ZSTUDENT /ZINSERT object and sub-object, complete with the user, program, and timestamp that generated it.

1. Open transaction SLG1.
2. Filter by your defined Object (ZSTUDENT) and Sub-object ( ZINSERT).
3. Click Execute.

Transaction SLG1 will render a comprehensive overview showing the failure events complete with timestamps, executing application users, and explicit line message tracking.

Conclusion

This blog post walked through how to capture and store error messages using SAP’s Application Log framework, from defining a log object in SLG0 to creating, populating, and saving the log via BAL_LOG_CREATE, BAL_LOG_MSG_ADD/ BAL_LOG_MSG_ADD_FREE_TEXT, and BAL_DB_SAVE. Using a simple student-table insert as the example kept the focus on the logging mechanism itself rather than on business complexity. Readers should now be able to apply this same pattern to any background job in their own systems, ensuring that errors are never lost simply because no one was watching the screen when they occurred.

“}]] 

  Read More Technology Blog Posts by Members articles 

#abap