Sabah mesajı kısa: “Dün akşamki veri gelmemiş.” Cümlede modül adı yok, hata kodu yok, saat yok. Yine de cevap bir yerde duruyor.
Sorun kayıtların olmaması değil. Çoğu ekip aramaya ortadan başlıyor: en son kimin neyi değiştirdiği konuşuluyor, akla gelen ilk modül açılıyor, yarım saat sonra hangi adımın çalıştığı hâlâ bilinmiyor. Oysa kayıtlar sıralı okunabilir ve sıra, tahminden çok daha hızlı sonuç verir.
Hangi günlük hangi soruyu cevaplıyor
Önce zamanı ve kapsamı sabitleyin: hangi veri, hangi saat aralığı, hangi hedef. Sonra her kaydın hangi soruyu cevapladığını ayırın.
- Çalıştırma kaydı. Zamanlanmış bir akış varsa iş hiç kuyruğa girmiş mi, hangi adımda durmuş? Durum alanı
PENDING,RUNNING,AWAITING_CALLBACK,COMPLETED,FAILEDveyaCANCELLEDolabilir; ilk bakılacak yer burası. - Servis günlüğü. Giden API çağrılarında istek ve yanıt kayıtları, süreler ve hata ayrıntısı bulunur. Çağrı hiç gelmemiş mi, gelip yetki hatası mı almış, yoksa istek limitine mi çarpmış?
- Olay günlüğü. Akış bir olayla başlıyorsa alınan olay, çalıştırılan aksiyon ve sonucu burada durur. Olayın hiç oluşmamış olması da bir bulgudur.
- Kaynak tarafı. iDataView çalıştırma sonucu, SQL aktarım kayıtları veya TSAP pipeline günlüğü; hangi akış kullanıldıysa oradan okunur.
Operasyonel servis kodları bu aramayı kısaltıyor: WS ve WSC giden ve gelen API’yi, SQL aktarımı, MAIL ve FILE gönderim ile SAP-yerel dosya isteğini, TSAP SAP’ye yazma yönünü, CTM Fabric tarafını, BI analitik işleri gösterir. Aynı saat aralığında hangi servis türünün hata verdiğine bakmak, aramayı çoğu zaman tek modüle indirir.
AWAITING_CALLBACK durumunun anlattığı şey
Bir durum diğerlerinden çok yanlış okunuyor. Haricî SAP veya servis sonucu gereken adım AWAITING_CALLBACK durumuna alınır ve worker serbest bırakılır; iş takılmış değil, cevap bekliyordur. Bekleyen bir çalıştırmayı hata sanıp yeniden başlatmak, aynı işi ikinci kez tetikler.
Beklentiyi de doğru kurmak gerekiyor: tek bir kimliğin bütün modüller ve dış sistemler boyunca kendiliğinden taşındığını varsaymayın. Kayıtları pratikte birbirine bağlayan şey zaman aralığı, servis veya iş adı ve kaynak nesnedir. İlk adımda zamanı sabitlemek bu yüzden önemli.
Yeniden çalıştırma kararını kayıtlara bağlamak
İkinci bir uyarı: bir kaydın var olması içeriğinin doğru olduğunu göstermez. “Başarılı” sonucu, hedef sistemin veriyi iş açısından kabul ettiği anlamına gelmez. Özellikle SAP’ye yazan akışlarda hedef tablodaki satır sayısını ayrıca saymak gerekir.
Yeniden çalıştırma kararı da buna bağlı. TSAP paketleri arasında uçtan uca rollback yoktur; hata öncesinde yazılmış paketler SAP’de kalabilir. Önceki adımın hedefte ne bıraktığını görmeden yeniden başlatmak hasarı ikiye katlar. Başarısız işlerin kendiliğinden yeniden denendiğini de varsaymayın: max_retries alanı saklanır, ancak çalışan bir otomatik yeniden deneme uygulaması doğrulanmış değildir.
Kayıtları okumanın amacı yalnız sebebi bulmak değil, ikinci denemeyi güvenli hâle getirmek. Bu dört adımı bir kez yazıp nöbet listesinin yanına koymak, gece yarısı alınan kararların kalitesini belirliyor.
Son altı ayda açıklayamadığınız bir kesinti varsa dosyasını açın. Aynı kayıtları bu sırayla birlikte okuyalım ve izin hangi adımda koptuğunu görelim; eksik olan genellikle kayıt değil, okuma düzenidir.