SLG1 — Application Log Display

SLG1 displays entries from the Business Application Log, a generic logging framework that any ABAP program can call to record structured messages during processing. The transaction itself does no logging; it queries the underlying log tables and renders whatever the calling program chose to write, using an object and subobject key that the writing program defines. The structural fact that explains most confusion is that hundreds of unrelated applications, from IDoc processing to custom Z-programs, share the same log tables and the same viewer transaction. Two consultants debugging completely different processes both end up in SLG1, and if the object/subobject is not known in advance the log list can be enormous and irrelevant. Finding the right entry depends entirely on knowing, or discovering, which key the specific application used when it wrote the log.

SLG1 gets used when a background job or interface finishes without a short dump and without an obviously failed job status, but the business result is wrong or incomplete. Typical cases: a mass update run that skipped certain records silently, an IDoc or proxy interface that processed but logged warnings the calling system never surfaced, or a report that ran to completion but wrote detailed error text into the application log instead of the job log. It is reached for after checking job status and before assuming the process is a mystery, because many standard programs deliberately push detail into SLG1 rather than the spool or job log. Fiori apps built for a specific business object sometimes expose a filtered log view of the same underlying data, but for cross-application or ad hoc analysis SLG1 remains the direct route to the raw log.

Start in BALHDR filtered on OBJECT and SUBOBJECT plus the creation date and time fields to isolate the run in question, and note the LOGNUMBER of the candidate header. Then query BALM filtered on that LOGNUMBER, checking MSGTY to isolate errors and warnings versus pure informational noise. If the header exists but no rows appear in BALM, the program opened a log but never wrote messages to it, which is itself diagnostic. If no header exists at all for the time window, the process never created a log or it has already been deleted by retention cleanup.

SLG1 and the underlying Business Application Log framework are unchanged on S/4HANA; the transaction, the table structure, and the object/subobject model carry over directly from ECC. There is no general-purpose Fiori replacement for browsing the log framework itself, though individual Fiori apps built around a specific business object may present a curated view of the same log entries relevant to that object. For anything outside those curated views, SLG1 remains the tool.

First stop for the functional or interface consultant investigating a specific business process failure, since the content is business-specific message text. It becomes a Basis or ABAP problem only when the framework itself misbehaves, such as logs not saving, retention deleting too aggressively, or table growth affecting performance. A good handover includes the object, subobject, external ID if any, exact time window, and the expected versus actual message severity.

SM21 is worth comparing against, since it is the technical system log and catches a different class of event than the business-oriented application log, and the two are often checked together when a process fails silently. SM13 is relevant when the failure traces back to a database update that was logged separately from the application log. SM35 matters when the process in question ran through batch input sessions, since those sessions can generate their own application log entries alongside session-level status.