Logging in SAP and Error Handling / SAP’de Loglama ve Hata Yönetimi
- Hilmi Günay
- 4 days ago
- 8 min read
1. The Importance of Logging and Error Handling in Production Systems
In SAP projects, code that simply works is often considered sufficient. However, the real test
begins once the solution is moved to the production system. The number of users increases, data volume grows, and processes are no longer limited to dialog programs; background jobs, integrations, and chained flows come into play.
In production environments, a significant portion of errors never appear on the user interface. An RFC call may fail, a batch job may stop at a specific record, or data coming from an external system may arrive in an unexpected format. In such cases, an error only becomes meaningful if it is logged correctly. Otherwise, the issue is either completely lost or remains only as a short dump record.
At this point, logging and error handling stop being temporary tools used during debugging and turn into permanent mechanisms that ensure the system’s sustainability. The ability of support teams to understand a problem without having to reproduce it, perform root cause analysis, and prevent the same error from occurring again is only possible with proper logging.
A sound error-handling approach in production systems:
Records where and with which data an error occurred
Guides the user without exposing technical details
Provides traceability for support and operations teams through central tools such as SLG1
Reduces the need for debugging to an exceptional case
The purpose of this article is to go beyond simple error catching and present a traceable, sustainable, and professional logging approach for production systems.
2. Message Class (SE91)
Message classes are the standard mechanism in SAP systems used to communicate with users. When used correctly, they clearly explain what went wrong and what action is expected from the user.
However, message classes are not a logging tool. They are not designed to store technical details, track process flows, or provide data for support teams. For this reason, message classes should be positioned only as the user-facing part of the error-handling architecture.
This is also why this article does not go into SE91 details. The real value lies not in how a message is defined, but in deciding when a message should be shown and when a log entry should be written.
3. MESSAGE or Log? The Decision Point
One of the most critical questions in production systems is: Who is this information for?
If the information requires an action from the user, a MESSAGE should be used. Examples include missing mandatory fields, invalid input, or violations of business rules.
If the information is needed to understand how the system behaved, then it is a logging topic. Integration errors, batch job issues, unexpected exceptions, and technical process flows should be recorded via the Application Log.
When this distinction is not clearly made:
Users are exposed to technical messages
Support teams are left with insufficient information
4. What Is the Application Log (BAL)?
The Application Log (BAL) is SAP’s standard and centralized logging infrastructure designed specifically for production systems. It records what happened in the system, at which step, and with which data—without displaying this information to the user.
The key difference of BAL is not just that it stores errors, but that it stores them together with their context. Logs are grouped under objects and subobjects, making it possible to clearly track which module, which substep, and which business purpose a process belongs to.
The Application Log becomes especially critical in the following scenarios:
Background jobs
Integrations and RFC calls
Scheduled or chained processes
Programs running without user interaction
In such cases, MESSAGE statements are usually insufficient. The Application Log, on the other hand, provides a filterable, readable, and comparable monitoring capability via SLG1. Support teams can understand where a process failed without debugging.
In short, BAL provides much more than just “an error occurred.” It answers the question: How did the error occur?
5. Why Should Logging Be Detailed?
Insufficient logging is often no better than no logging at all. A message saying “An error occurred” has little value by itself. A log should make it possible to reproduce the error and identify its root cause.
A well-detailed log:
Shows whether the same error occurs repeatedly
Reveals which data caused the problem
Makes weak points in the process visible
How to Create an Application Log (BAL) Object
a. Defining Log Object and Subobject
Before using the Application Log, a log object and optionally one or more subobjects must be defined in the system.
Steps:
Go to transaction SLG0
Create a new Object
Object: ZSD_INTEGRATION
Description: SD Integration Processes
Add one or more Subobjects under the object
Subobject: DELIVERY
Description: Delivery Integration
Note: The object should represent the overall process, while the subobject represents a specific substep of that process.
How to Write a BAL Log Entry
Using BAL essentially consists of three steps:
Create the log
Add messages to the log
Save the log to the database
Below is a simple and clear example.
1. Creating the Log
DATA: lv_log_handle TYPE balloghndl.
CALL FUNCTION 'BAL_LOG_CREATE'
EXPORTING
i_object = 'ZSD_INTEGRATION'
i_subobject = 'DELIVERY'
i_extnumber = lv_vbeln "process key
IMPORTING
e_log_handle = lv_log_handle.
i_object / i_subobject → Values defined in SLG0
i_extnumber → Very useful for searching in SLG1 (document number, etc.)
2. Adding a Message to the Log
DATA: ls_msg TYPE bal_s_msg.
ls_msg-msgty = 'E'.
ls_msg-msgid = 'ZSD_MSG'.
ls_msg-msgno = '001'.
ls_msg-msgv1 = lv_vbeln.
CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
i_log_handle = lv_log_handle
i_s_msg = ls_msg.
In this approach:
A message class is used, but nothing is shown to the user
The message is visible in SLG1
Alternatively, you can write free text instead of using a message class:
ls_msg-msgty = 'E'.
ls_msg-msgid = '00'.
ls_msg-msgno = '398'.
ls_msg-msgv1 = 'RFC call failed for delivery'.
3. Saving the Log to the Database
CALL FUNCTION 'BAL_DB_SAVE'.
Viewing Logs via SLG1
Go to transaction SLG1
Enter Object / Subobject
Enter External Number (if available)
Execute
This approach not only shortens error resolution time but also contributes to making the system more robust over time.
Conclusion
Logging and error handling in SAP are not just reactive mechanisms for catching errors. A well-designed logging approach makes system behavior understandable and provides predictability in production environments.
MESSAGE statements guide the user, while the Application Log explains the system. When these two are balanced correctly, errors stop being surprises and become manageable data points. This is what differentiates mature projects: not just solving issues, but making them traceable.
1. Üretim Sistemlerinde Loglama ve Hata Yönetiminin Önemi
SAP projelerinde kodun çalışıyor olması çoğu zaman yeterli kabul edilir. Ancak üretim sistemine geçildiğinde asıl sınav başlar. Kullanıcı sayısı artar, veri hacmi büyür, süreçler yalnızca dialog programlardan ibaret olmaktan çıkar; background job’lar, entegrasyonlar ve zincirleme akışlar devreye girer.
Üretim ortamında oluşan hataların önemli bir kısmı kullanıcı ekranında görünmez. Bir RFC çağrısı başarısız olabilir, bir batch job belirli bir kayıtta takılabilir ya da harici bir sistemden gelen veri beklenmedik bir formatta olabilir. Bu tip durumlarda hata, yalnızca doğru şekilde loglandıysa anlam kazanır. Aksi halde problem ya tamamen kaybolur ya da yalnızca bir dump kaydı olarak kalır.
Loglama ve hata yönetimi bu noktada, geliştiricinin debug sırasında kullandığı geçici bir araç değil; sistemin yaşayabilirliğini sağlayan kalıcı bir mekanizma haline gelir. Destek ekiplerinin problemi tekrar oluşturmak zorunda kalmadan anlayabilmesi, kök neden analizinin
ve aynı hatanın tekrarının önlenmesi ancak doğru loglama ile mümkündür.
Üretim sistemlerinde sağlıklı bir hata yönetimi yaklaşımı;
Hataların nerede ve hangi veriyle oluştuğunu kayıt altına alır,
Kullanıcıyı teknik detaylarla boğmadan yönlendirir,
Destek ve operasyon ekiplerine SLG1 gibi merkezi araçlar üzerinden izlenebilirlik sağlar,
Debug ihtiyacını istisnai bir duruma indirir.
Bu makalede amaç, hata yakalamaktan çok daha fazlasını ele almak; üretim sistemlerinde izlenebilir, sürdürülebilir ve profesyonel bir loglama yaklaşımını ortaya koymaktır.
2. Message Class (SE91)
Message class’lar, SAP sistemlerinde kullanıcıyla iletişim kurmak için kullanılan standart mekanizmadır. Doğru kullanıldığında, kullanıcıya neyin yanlış gittiğini ve hangi aksiyonun beklendiğini sade bir şekilde iletir.
Ancak message class’lar bir loglama aracı değildir. Teknik detayları saklamak, süreçleri izlemek veya destek ekiplerine veri sağlamak gibi bir amacı yoktur. Bu nedenle message class’lar, hata yönetimi mimarisinin yalnızca kullanıcıya bakan yüzü olarak konumlandırılmalıdır.
Bu makalede SE91 detaylarına girilmemesinin nedeni de budur: Asıl değer, mesajın nasıl tanımlandığından çok, hangi durumda mesaj gösterilip hangi durumda log yazıldığıdır.
3. MESSAGE mi, Log mu? Karar Noktası
Üretim sistemlerinde en kritik soru şudur:Bu bilgi kimin için?
Eğer bilgi, kullanıcının aksiyon almasını gerektiriyorsa MESSAGE kullanılmalıdır. Örneğin eksik bir alan, hatalı bir giriş veya iş kuralına aykırı bir durum bu kapsamdadır.
Eğer bilgi, sistemin nasıl davrandığını anlamak için gerekiyorsa bu bir log konusudur. Entegrasyon hataları, batch job problemleri, beklenmeyen exception’lar ve teknik akışlar Application Log üzerinden kayıt altına alınmalıdır.
Bu ayrım net yapılmadığında:
Kullanıcı teknik mesajlarla karşılaşır,
Destek ekipleri ise yetersiz bilgiyle baş başa kalır.
4. Application Log (BAL) Nedir?
Application Log (BAL), SAP’nin üretim sistemleri için sunduğu standart ve merkezi loglama altyapısıdır. Kullanıcıya gösterilmeyen; ancak sistemin nasıl çalıştığını, hangi adımda ne yaşandığını ve hangi verilerle sorun oluştuğunu detaylı şekilde kayıt altına alan bir mekanizmadır.
BAL’in temel farkı, hatayı yalnızca kaydetmesi değil; bağlamı ile birlikte saklamasıdır. Log’lar object ve subobject yapısı altında gruplanır. Bu sayede bir sürecin hangi modülde, hangi alt adımda ve hangi amaçla çalıştığı net şekilde izlenebilir.
Application Log özellikle şu senaryolarda kritik hale gelir:
Background job’lar
Entegrasyon ve RFC çağrıları
Zamanlanmış veya zincirleme süreçler
Kullanıcı etkileşimi olmadan çalışan programlar
Bu tür senaryolarda MESSAGE çoğu zaman yetersiz kalır. Application Log ise SLG1 üzerinden filtrelenebilir, okunabilir ve karşılaştırılabilir bir izleme imkânı sunar. Destek ekipleri, debug yapmadan sürecin nerede koptuğunu anlayabilir.
Kısacası BAL, üretim sistemlerinde “hata oldu” bilgisinden çok daha fazlasını sağlar: Hata nasıl yaşandı?
5. Loglama Neden Detaylandırılmalıdır?
Yetersiz log, çoğu zaman hiç log olmamasından farksızdır. “Hata oluştu” bilgQisinin tek başına bir değeri yoktur. Log, hatanın tekrar üretilebilmesini ve kök nedeninin bulunabilmesini sağlamalıdır.
Detaylandırılmış bir log:
Aynı hatanın tekrar edip etmediğini gösterir
Hangi verilerin problemli olduğunu ortaya koyar
Süreç içindeki zayıf noktaları görünür hale getirir
Application Log (BAL) Nesnesi Nasıl Oluşturulur?
a. Log Object ve Subobject Tanımlama
Application Log kullanabilmek için önce sistemde bir log nesnesi (Object) ve isteğe bağlı alt nesne (Subobject) tanımlanır.
İşlem adımları:
SLG0 işlem koduna gir
Yeni bir Object oluştur
Object: ZSD_INTEGRATION
Description: SD Integration Processes
Object içine bir veya daha fazla Subobject ekle
Subobject: DELIVERY
Description: Delivery Integration
Not:Object genel süreci, Subobject ise sürecin alt adımını temsil etmelidir.
BAL Log Kaydı Nasıl Atılır?
BAL kullanımı temelde 3 adımdan oluşur:
Log oluşturma
Log’a mesaj ekleme
Log’u veritabanına kaydetme
Aşağıda en sade ve anlaşılır örnek var.
1. Log Oluşturma
DATA: lv_log_handle TYPE balloghndl.
CALL FUNCTION 'BAL_LOG_CREATE'
EXPORTING
i_object = 'ZSD_INTEGRATION'
i_subobject = 'DELIVERY'
i_extnumber = lv_vbeln "işlem anahtarı
IMPORTING
e_log_handle = lv_log_handle.
i_object / i_subobject → SLG0’da tanımladığın değerler
i_extnumber → SLG1’de arama yaparken çok işe yarar (belge no vb.)
2. Log’a Mesaj Ekleme
DATA: ls_msg TYPE bal_s_msg.
ls_msg-msgty = 'E'.
ls_msg-msgid = 'ZSD_MSG'.
ls_msg-msgno = '001'.
ls_msg-msgv1 = lv_vbeln.
CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
i_log_handle = lv_log_handle
i_s_msg = ls_msg.
Burada:
Message class kullanılır ama kullanıcıya basılmaz
Mesaj SLG1’de görünür
İstersen message class yerine serbest metin de yazabilirsin:
ls_msg-msgty = 'E'.
ls_msg-msgid = '00'.
ls_msg-msgno = '398'.
ls_msg-msgv1 = 'RFC call failed for delivery'.
3. Log’u Veritabanına Kaydetme
CALL FUNCTION 'BAL_DB_SAVE'.
SLG1 Üzerinden Log Görüntüleme
SLG1 işlem kodu
Object / Subobject gir
External Number (varsa) gir
Execute
Bu yaklaşım, yalnızca hata çözüm süresini kısaltmaz; aynı zamanda sistemin zaman içinde daha sağlam hale gelmesine katkı sağlar
Sonuç
SAP’de loglama ve hata yönetimi, yalnızca bir hata yakalama refleksi değildir. İyi tasarlanmış bir loglama yaklaşımı, sistemin davranışını anlaşılır kılar ve üretim ortamında öngörülebilirlik sağlar.
MESSAGE’lar kullanıcıyı yönlendirir, Application Log ise sistemi anlatır. Bu ikisi doğru dengelendiğinde, hatalar sürpriz olmaktan çıkar; yönetilebilir birer veri haline gelir. Olgunlaşmış projelerde fark yaratan da tam olarak budur: sorunları yalnızca çözmek değil, izlenebilir hale getirmek.
Comments