ST22 Dump'ında Hangi Bölüme Bakmalı? Kök Nedeni Taşıyan 6 Alan

Bir ST22 short dump'ı aslında birkaç sayfalık bir rapordur ve o raporun her bölümü aynı ağırlıkta değildir. Tecrübeli bir ABAP geliştiricisi dump'ı baştan sona okumaz; doğrudan iki üç bölüme atlar, oradan hipotezini kurar, sonra gerekirse geri kalanına bakar. Yeni başlayan biri ise genellikle ekranın en üstünde yazan hata adına bakıp "bu ne demek" diye aramaya başlar — ve çoğu zaman kök nedene götürmeyen bir yola sapar.

Bu yazı, bir dump'ın hangi bölümünün hangi soruyu yanıtladığını ele alıyor. Aynı liste, AI'ın dump analizinde neden bazı durumlarda isabetli, bazı durumlarda yalnızca yönlendirici olabildiğini de açıklıyor: çünkü AI da aynı bölümleri okur ve o bölümlerde yazmayan bir şeyi bilemez.

1. Hata sınıfı: dump'ın adı

Dump'ın en tepesindeki büyük harfli ad — CONVT_NO_NUMBER, OBJECTS_OBJREF_NOT_ASSIGNED, DBIF_RSQL_SQL_ERROR, TIME_OUT gibi — runtime'ın hatayı hangi kategoriye koyduğunu söyler. Bu bilgi değerlidir ama sınırlıdır: kategoriyi verir, nedeni vermez.

Aradaki farkı görmek önemlidir. CONVT_NO_NUMBER "sayıya çevrilemeyen bir metin sayıya çevrilmeye çalışıldı" demektir; ama o metnin neden orada olduğunu — bir arayüz dosyasından mı geldi, bir kullanıcı mı boş bıraktı, bir birim alanı mı yanlış eşlendi — söylemez. Dolayısıyla hata sınıfı bir arama terimi olarak iyidir, bir teşhis olarak değil. Yalnız ada bakıp internette çözüm aramak, dump analizinde en sık yapılan zaman kaybıdır: aynı ada sahip iki dump'ın kök nedeni tamamen farklı olabilir.

Bu bölümün asıl işlevi, sonraki bölümlerde neye bakacağınızı belirlemesidir. Bir tip dönüşüm hatasıysa değişken içeriklerine; bir referans hatasıysa nesnenin nerede oluşturulduğuna; bir veritabanı hatasıysa çalıştırılan SQL'e ve veritabanının döndürdüğü mesaja bakılır.

2. "Ne oldu" ve "Hata analizi" metinleri

Dump'ın üst kısmındaki açıklama bölümleri, SAP'nin hata hakkındaki kendi yorumunu içerir. Burada iki tür bilgi karışık durur: gerçekten olay-özgü olanlar (hangi alan, hangi değer, veritabanının döndürdüğü hata metni) ve o hata sınıfı için her zaman aynı basılan genel şablon metinler.

Ayrımı yapmak bakılacak yeri daraltır. "Hata analizi" bölümünde geçen bir alan adı, bir tablo adı veya alıntılanmış bir değer olay-özgüdür ve doğrudan kök nedene işaret eder. "Bu hata genellikle ... durumunda oluşur" biçimindeki cümleler ise şablondur; sizin olayınız hakkında bir şey söylemez. Veritabanı hatalarında bu bölüm özellikle kıymetlidir, çünkü veritabanının kendi hata kodu ve metni — ki gerçek nedeni genelde o taşır — burada geçer.

3. Kaynak kod bölümü: işaretli satır suçlu değildir

Dump, hatanın oluştuğu satırı çevresindeki birkaç satırla birlikte gösterir. Bu bölüm en çok bakılan yerdir ve en çok yanlış okunan yerdir: işaretli satır hatanın oluştuğu yerdir, sebebinin bulunduğu yer değildir.

Klasik örnek, bir referansın atanmadığı için patlayan bir metot çağrısıdır. Dump metot çağrısının satırını işaretler; oysa asıl hata, o nesnenin oluşturulmasının bir IF bloğu içinde kalması ve o koşulun bazı durumlarda sağlanmamasıdır — yani dump'ta hiç görünmeyen, onlarca satır yukarıdaki bir yer. Aynı şey tip dönüşümlerinde de geçerli: patlayan satır dönüşümü yapan satırdır, ama bozuk değeri oraya taşıyan atama başka yerdedir.

Buradaki pratik kural şu: işaretli satırı okuduktan sonra soruyu değiştirin. "Bu satır neden hata verdi" yerine "bu satıra bu değer nasıl geldi" diye sorun. Bu soru sizi doğal olarak sonraki iki bölüme götürür.

4. Çağrı yığını: hata nereden tetiklendi?

Dump'ın çağrı yığını (aktif çağrılar ve olaylar listesi) hangi programın hangi olayından başlayıp hangi form, metot veya fonksiyon modülü zincirinden geçerek hata satırına gelindiğini gösterir. Tek bir satırın kendi başına anlatamadığı şeyi bu liste anlatır: bağlamı.

Bu bölüm iki soruyu birden yanıtlar. Birincisi, hatanın hangi senaryoda oluştuğu — arka planda çalışan bir işten mi, bir kullanıcı ekranından mı, bir RFC çağrısından mı geldiği. İkincisi, ve pratikte daha kritik olanı: kimin kodu. Zincirde standart SAP nesneleri ile kendi Z nesneleriniz karışık durur. Hata standart bir fonksiyon modülünün içinde oluşmuş görünse bile, o modülü hatalı parametreyle çağıran sizin kodunuz olabilir — bu durumda düzeltilecek yer standart nesne değil, çağıran taraftır. Yığında kendi nesnelerinizden en derinde olanı bulmak, çoğu dump'ta doğrudan müdahale edilecek noktayı verir.

Bir enhancement, user-exit veya BAdI implementasyonu zincire buradan girer — ve devralınan bir sistemde çalışıyorsanız, yığında adını ilk kez gördüğünüz bir nesnenin ne yaptığını anlamak dump'ı okumaktan daha uzun sürebilir.

5. Değişken içerikleri ve sistem alanları

Dump'ın alt kısmındaki değişken içerikleri ve sistem alanları bölümü, tüm rapor içinde gerçek veriyi gösteren tek yerdir. Kaynak kod hangi işlemin yapıldığını, çağrı yığını nereden gelindiğini söyler; ama "hangi değer bu hatayı tetikledi" sorusunun cevabı yalnızca burada yazar.

Tip dönüşüm ve bölme hatalarında bu bölüm genelde işi bitirir: sorunlu değeri görünce hem neden patladığı hem de nereden gelmiş olabileceği anlaşılır. Sistem alanları ise olayın çerçevesini verir — hangi kullanıcı, hangi dil, hangi işlem kodu, hangi tarih. Bir hata yalnızca belirli bir dilde veya belirli bir birimde ortaya çıkıyorsa, bunun ilk izi burada görünür.

Bu bölüm aynı zamanda dump analizinin gizlilik açısından en hassas yeridir, çünkü canlı iş verisi (müşteri adı, tutar, belge numarası) buraya düşer. Bir dump'ı analiz için herhangi bir araca verirken bu bölümün ne içerdiğine bakmak, kurumsal bir alışkanlık olmayı hak eder.

6. Kullanıcı, zaman ve tekrar sayısı

Bu bölüm tek bir dump'ın içinde değil, ST22'nin liste görünümünde okunur — ve sıklıkla atlanır. Oysa düzeltmenin aciliyetini ve biçimini belirleyen şey burada yazar: aynı hata tek bir kullanıcıda bir kez mi düştü, yoksa gün içinde farklı kullanıcılarda onlarca kez mi tekrarlıyor?

İki durum farklı iş gerektirir. Tekrarlayan ve birden fazla kullanıcıya yayılmış bir dump, veriye veya yapılandırmaya bağlı sistemik bir sorunun işaretidir — kalıcı bir düzeltme ister. Tek seferlik bir dump, bir defalık bozuk kayıt veya olağandışı bir kullanım sırası olabilir; kodun savunmasını güçlendirmek yeterli olabilir. Zaman deseni de bir ipucudur: her gün aynı saatte tekrarlayan dump'lar genelde zamanlanmış işlere bakmanız gerektiğini söyler, ay sonunda yoğunlaşanlar ise veri hacmine veya kapanış süreçlerine.

AI bu bölümleri nasıl kullanır?

mdp/aigui'de bir short dump kaydını AI ile analiz ettiğinizde model de aynı bölümleri okur ve olası kök nedenle birlikte bir çözüm önerisi üretir. AI'ın buradaki gerçek katkısı sihirli bir teşhis değil; yukarıda anlattığımız okuma sırasını hızlı ve tutarlı biçimde uygulamasıdır: hata sınıfını kategori olarak alması, işaretli satırla yetinmeyip yığına ve değişken içeriklerine bakması, ve tanıdık hata desenlerini geçmiş binlerce benzer olaydan tanıması. Bu, özellikle o modüle yabancıysanız, hipotez kurma süresini kısaltır.

Sınırı da aynı yerden gelir. AI, dump'ta yazmayan bir şeyi bilemez — ve dump, kök nedenin genellikle yalnızca izini taşır. Bu yüzden analizin ikinci yarısı dump'ı gerçek kaynak kodla ilişkilendirmektir: ilgili programı açıp değeri oraya taşıyan yolu takip etmek. Düzeltme aşamasında da ürünün geri kalanıyla aynı kural geçerlidir — AI bir değişiklik öneriyorsa bunu satır bazlı bir diff olarak görürsünüz ve SAP'a yalnızca sizin onayınızla yazılır; hiçbir adım kendiliğinden ilerlemez.

Sonuç

Bir dump'ı hızlı okumanın yolu, bölümlere soru sormaktır: hata sınıfı hangi kategori, açıklama metinleri SAP ne diyor, kaynak kod nerede patladı, çağrı yığını nereden gelindi ve kimin kodu, değişken içerikleri hangi değerle, liste görünümü ne kadar sık. Bu altı sorunun cevabı bir arada okunduğunda, hata adını aramaya hiç gerek kalmadan makul bir hipotez çıkar.

Ve en pratik tek kural, üçüncü bölümdeki kural: işaretli satır hatanın oluştuğu yerdir, sebebinin bulunduğu yer değildir. Dump analizinde kaybedilen zamanın büyük kısmı, o satırı suçlu sanmaktan kaynaklanır.