ST22 Short Dump Analizi: AI Kök Nedeni Nasıl Bulur?

Her ABAP geliştiricisinin tanıdığı bir an vardır: ST22'yi açarsınız, karşınızda uzun bir short dump durur — hata sınıfı, kısa metin, kaynak satır, çağrı zinciri, o anki değişken değerleri. Bilgi eksik değildir; aksine fazladır. Asıl zorluk, bu yığının içinden "ne oldu"yu değil "neden oldu"yu çıkarmaktır. Bu yazıda ST22 short dump analizinin neden yorucu olduğunu, AI'ın bir dump'ı gerçekte nasıl okuduğunu ve kök nedenden düzeltmeye giden akışın mdp/aigui'de nasıl işlediğini adım adım ele alıyoruz — pazarlama cümlesi kurmadan, her adımda neyin otomatik olduğunu neyin sizin elinizde kaldığını netleştirerek.

1. ST22 dump'ı ne söyler, ne söylemez

Bir short dump, çalışma zamanında yakalanmamış bir istisna oluştuğunda SAP çalışma zamanı ortamının ürettiği bir olay kaydıdır. İçinde çok değerli veriler bulunur: runtime error adı (örneğin CONVT_NO_NUMBER), istisna sınıfı, hatanın tetiklendiği program ve satır, çağrı zinciri (call stack) ve çoğu zaman ilgili değişkenlerin o anki içerikleri.

Sorun, dump'ın size belirtiyi göstermesi ama nedeni yorumlamayı size bırakmasıdır. Hatanın patladığı satır çoğu zaman gerçek sorunun kaynağı değildir — yalnızca sorunun yüzeye çıktığı yerdir. Sayıya çevrilemeyen bir alan üç ekran öncesinde beslenmiş, initial kalan bir referans bambaşka bir metotta oluşturulmamış olabilir. Deneyimli bir geliştirici bu bağı zihninde kurar; ama bu, dump'ı okumak, kaynağa gitmek, çağrı zincirini geri sarmak ve değişken değerlerini karşılaştırmakla geçen gerçek bir emek gerektirir.

İşin bir de zamanlama boyutu var. Dump'lar genellikle en kötü anda düşer: bir batch job gece yarısı patlar, canlıda bir kullanıcı işlemi yarıda kalır. Analizi yapan kişi çoğu zaman o kodu yazan kişi değildir. "Gördüm ama anlamadım" anı ile "tamam, kök neden bu" anı arasındaki mesafe, işte bu yazının konusu.

2. AI bir short dump'ı nasıl okur

mdp/aigui'nin ST22 hata analizi, short dump kaydını AI'a verip olası kök nedeni ve çözüm önerilerini almak üzerine kuruludur. Ama bir dil modeline ham dump metnini vermek tek başına yeterli değildir — asıl fark, analizin bağlamla beslenmesinden gelir.

AI bir dump'ı okurken önce yapısını çözer: hangi runtime error, hangi istisna sınıfı, çağrı zincirinde hangi program ve modüller var, hata satırı nerede. Ardından kritik adım gelir: mdp/aigui doğrudan SAP sisteminize bağlıdır ve ADT (ABAP Development Tools) REST API üzerinden gerçek kaynak kodunu okuyabilir. Yani analiz, dump'ın işaret ettiği satırı "hayal etmez" — o programın gerçek kaynağıyla ilişkilendirir. Bu, kod üretiminde olduğu gibi burada da temel ilkedir: model genel bir eğitim setinden tahmin yürütmez, sizin sisteminizin gerçeğiyle çalışır.

Sonuç, ham dump'ın yeniden ifadesi değil, bir yorumdur: "Bu hata büyük olasılıkla şu satırdaki şu değişkenin şu koşulda beklenmedik değer almasından kaynaklanıyor; kontrol edilecek yer burası." Öneri kesin bir teşhis olarak değil, doğrulanması gereken bir hipotez olarak sunulur — çünkü son hakem her zaman sistemin kendisidir.

3. En sık görülen runtime hataları ve tipik kök nedenleri

Short dump'ların büyük kısmı, aslında az sayıda tanıdık runtime error etrafında toplanır. AI'ın değeri, bu kalıpları tanıyıp analizi doğru yöne çevirmesinde ortaya çıkar. En sık karşılaşılanlardan birkaçı:

• CONVT_NO_NUMBER: sayısal olmayan bir karakter alanının sayısal bir alana taşınması veya aritmetiğe sokulması. Kök neden çoğu zaman hata satırında değil, o alanı besleyen upstream veride gizlidir.
• OBJECTS_OBJREF_NOT_ASSIGNED (CX_SY_REF_IS_INITIAL): initial kalmış bir nesne referansı üzerinden metot çağrısı. Genellikle bir CREATE OBJECT ya da fabrika çağrısının atlandığı veya koşullu daldan hiç geçmediği anlamına gelir.
• DBIF_RSQL_SQL_ERROR: veritabanı katmanından dönen bir hata — örneğin duplicate key ile insert, uyumsuz veri tipi ya da uzunluk taşması. Analiz genellikle SQL'in kendisiyle sınırlı değildir; veriyi hazırlayan mantığa uzanır.
• TSV_TNEW_PAGE_ALLOC_FAILED: bellek limiti aşımı, tipik olarak sınırsız büyüyen bir iç tablo. Kök neden çoğu zaman filtresiz bir seçim ya da paketlere bölünmeden işlenen büyük veri kümesidir.
• TIME_OUT: diyalog işleminin azami çalışma süresini aşması. Uzun döngüler, verimsiz veri seçimi veya kilit bekleme senaryolarına işaret eder.
• MESSAGE_TYPE_X: programın bilinçli olarak kendini sonlandırması. Burada asıl soru, bu X mesajını tetikleyen iş kuralının hangi koşulda devreye girdiğidir.

Bu isimler her ABAP geliştiricisine tanıdık gelir; kritik olan, dump'ın gösterdiği yüzeydeki satırdan gerçek nedene inebilmektir. AI, tanıdık kalıbı hızla belirleyip analizi "nerede bakmalı"ya odaklar — ama son kararı, bağlamı en iyi bilen kişi olarak siz verirsiniz.

4. Kök nedenden düzeltmeye: aynı onay akışı

Kök nedeni anlamak yarısıdır; diğer yarısı düzeltmektir. mdp/aigui'de bu iki adım kopuk değildir: analizden çıkan düzeltme önerisi, kod üretiminin geri kalanıyla aynı disipline tabidir. Yani öneri editörünüze sessizce yazılmaz — değişiklik önce satır bazlı bir diff olarak önünüze gelir, hangi satırın eklendiği ve değiştirildiği işaretli kalır, siz onaylamadan editördeki kod değişmez.

Bu, canlıda çalışan bir programı düzeltirken kritik önemdedir. Bir short dump'ı gidermek için yapılan acele bir değişiklik, dokunmaması gereken başka bir yeri sessizce bozabilir. Satır bazlı diff bu belirsizliği ortadan kaldırır: neyin değiştiği tartışmaya yer bırakmadan görünürdür.

Düzeltme SAP'a yalnızca sizin onayınızla gider; yazma ve aktivasyon hiçbir koşulda otomatik çalışmaz. Aktivasyondan önce syntax denetimi devreye girer — derlenemeyen bir düzeltme aktive edilmez. Değişiklik bir transport gerektiriyorsa, transport talebini uygulama içinden arayabilir veya oluşturabilirsiniz. Kısacası hata analizi tek başına duran bir modül değil; keşiften düzeltmeye, aktivasyona ve transport'a kadar aynı IDE akışının parçasıdır.

5. Dump içeriği nereye gider? Güvenlik modeli

Short dump'lar hassas olabilir: değişken değerleri, kullanıcı adları, iş verisi parçaları içerebilirler. Dolayısıyla "bu içerik nereye gidiyor?" sorusu meşru bir sorudur ve nettir: analiz için gereken bağlam seçtiğiniz AI model sağlayıcısına gönderilir, ama bu trafik doğrudan sizin cihazınızdan sağlayıcıya akar. mdp/aigui sunucuları aracı konumda değildir; dump içeriğiniz bizim altyapımızdan geçmez.

API anahtarları için de aynı model geçerlidir: anahtarlarınız yalnızca cihazınızda şifreli olarak saklanır ve hiçbir zaman mdp/aigui sunucularına iletilmez. SAP bağlantı bilgileriniz de aynı şekilde yalnızca cihazda şifreli tutulur.

Trafiğin şirket ağından çıkmaması gereken kurumsal senaryolar için ek seçenekler vardır: yönetilen AI erişimi ile şirket yöneticisi model erişimini merkezi olarak yapılandırır, kullanıcılar kendi anahtarlarını hiç girmeden şirketin belirlediği politikalar dahilinde çalışır. Daha katı izolasyon gerektiren durumlarda Microsoft Azure AI Foundry (VNet, private access) desteklenir.

Sonuç

ST22 short dump analizi, aslında bir "veri okuma" değil "bağ kurma" işidir: belirtiyi gösteren satırdan, onu tetikleyen gerçek nedene uzanan zinciri bulmak. AI bu zinciri sizin yerinize kapatmaz — ama tanıdık runtime error kalıplarını hızla belirleyip, dump'ı gerçek kaynak kodunuzla ilişkilendirerek "nerede bakmalı" sorusunu dakikalar içinde daraltır.

Kazanç sadece hız değil; düzeltmenin de aynı onay-döngülü, syntax-denetimli, transport-uyumlu akışın içinde kalması. Analizden aktivasyona kadar son karar — ve sorumluluk — her adımda geliştiricide. Değişen tek şey, dump karşısında geçen o ilk yorumlama süresinin ne kadar kısaldığı.