SAP Application Log (BAL) and SLG1

BAL separates log header identity from message content. The header classifies a run/business object using an application log object, subobject, external number, user/time and retention context. Messages can be SAP message-class entries, free text or exceptions with context. BAL_LOG_CREATE creates an in-memory handle; BAL_LOG_MSG_ADD/BAL_LOG_EXCEPTION_ADD populate it; BAL_DB_SAVE persists selected logs; BAL_DB_SEARCH/LOAD retrieve them; BAL_DSP_LOG_DISPLAY renders them. Persistent data is stored through BAL tables such as BALHDR/BALDAT, but application code should use the framework rather than direct inserts/updates.

Use BAL for batch/interface/mass-processing/application events where multiple messages must be correlated to one execution and support needs durable searchable evidence. It is ideal for 'processed 1,000 objects: 980 success, 20 errors' scenarios, background jobs, integrations and custom applications. Use ordinary MESSAGE for immediate dialog feedback and change documents for before/after field audit. Decide retention/object/subobject design before production so SLG1 searches remain useful.

SLG0/configuration defines application-log objects/subobjects; SLG1 searches/displays persisted logs. BAL can store technical exception detail while business reports show summarized status. Background jobs often write both job log and BAL—the job log proves scheduler execution, while BAL provides application object-level messages. Integration monitoring can correlate external request IDs through EXTNUMBER. Logs may later be archived/deleted according to retention policy.

A nightly customer synchronization processes 50,000 records. Writing only WRITE statements to the job log makes it impossible to search one customer a week later. The program creates a BAL log per run with external request/batch ID, adds structured messages per failed customer and persists the log. Support searches SLG1 by object/subobject/external number, finds the exact BAPI error and reprocesses only failed records. Sensitive payload fields are deliberately excluded.

BAL remains a standard on-stack logging framework in S/4HANA and is still used by many applications. Cloud-native side-by-side applications also need centralized observability, but may use BTP logging services rather than BAL. Clean-core custom code can use released logging facilities appropriate to its environment; classic private/on-premise custom apps can continue using BAL where supported.

Application developers define log events/context and message quality; support/operations consume SLG1; security/compliance define sensitive-data/retention policy; Basis assists with volume management/archiving when logs grow large.

SLG1 displays logs; BALHDR/BALDAT store persistent data. BAL_* function-module pages cover create/add/search/load/save. CDHDR/CDPOS serves a different change-audit purpose.

Production verification: Capture the exact system and client, user, business object or technical identifier, timestamp, configuration or version, and standard SAP log or monitor that proves the behavior before changing code or customizing. Reproduce with representative data, record the before and after result, and keep a rollback path for any production-facing change.

Operational readiness: For production readiness of SAP Application Log (BAL) and SLG1, add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.

Review checkpoint: Review checkpoint for SAP Application Log (BAL) and SLG1: create a minimal reproducible example and a production-shaped test, then record the exact input, system release, user context, expected outcome and evidence tool used. Verify both correctness and failure behavior, not only runtime success. If the topic can affect transaction integrity, concurrency, memory or performance, test the relevant boundary condition explicitly and compare before and after measurements. The page should be usable by a second developer during an incident without relying on tribal knowledge from the original author.