Bir işlemin doğrulanması, “akış hata vermedi” sonucundan fazlasıdır. Okumada doğru verinin döndüğünü; yazmada doğru kaydın ve beklenen alanların değiştiğini kontrol edin. Hata durumunda önce işlemin hangi aşamada kaldığını bulun.
Önce sorunun yerini ayırın
| Gözlem | İlk kontrol |
|---|---|
| Runtime başlamıyor | Log, bağımlılıklar, Secret ve bağlantı başlangıç ayarları |
| Sorgu çalışmıyor | SQL sözdizimi, tablo/schema ve kullanıcının yetkisi |
| Sorgu çalışıyor, veri gelmiyor | Filtre değeri, tipi, doğru veritabanı ve boş sonuç beklentisi |
| UPDATE hata vermiyor ama kayıt değişmiyor | Etkilenen satır sayısı, WHERE koşulu ve sürüm/durum |
| Yazmadan sonra akış hata veriyor | İlk yazmanın commit olup olmadığı ve transaction kapsamı |
| İstemci yanıt alamıyor | İşlemin sonucunun bilinmemesi; iş kimliğiyle ayrı okuma |
Mock veya örnek alıcı yanıtıyla yapılan simülasyon, gerçek SQL yetkisini ve kalıcı yazmayı doğrulamaz. Gerçek bağlantı kontrolünü Run ile, sonucu da ayrı okumayla yapın.
Bağlantı hatalarında neye bakmalısınız?
| Belirti | Kontrol |
|---|---|
| Secret/property bulunamadı | Ad ve anahtar, runtime namespace’i, okuma yetkisi, ilgili bağımlılık |
| Sürücü veya sınıf bulunamadı | JDBC/havuz kütüphanesi ve bağımlılık değişiminden sonra yeniden başlatma |
| Connection refused / DNS / timeout | Runtime’dan sunucu adresi, port, ağ erişimi ve veritabanının sağlığı |
| Kimlik doğrulama reddi | Secret’taki kullanıcı/parola, veritabanındaki hesap ve gerekiyorsa TLS |
| Permission denied | Kullanıcının veritabanı, schema, tablo ve işlem yetkisi |
| Tablo bulunamadı | Bağlandığınız veritabanı, schema ve gerçek tablo adı |
| Duplicate key / constraint violation | İş kimliği, zorunlu alan, miktar veya ilişkili kayıt |
| Havuzdan bağlantı beklemesi | Uzun sorgu/kilit/transaction, eşzamanlı iş sayısı ve havuz sınırı |
Yanlış parolayı veya SQL sözdizimi hatasını tekrar deneyerek düzeltemezsiniz. SQL sorgu süresi, ağ bağlantısı, havuzdan bağlantı bekleme ve istemcinin HTTP bekleme süresi ayrı sınırlardır; yalnız birini artırmak diğerini çözmez.
Mesajı iş kimliğiyle bulun
İş kimliğini elde ettiğiniz noktada lunex.monitor.applicationId property’sine atayın. Bu kimlik sipariş, belge veya işlem referansınız olabilir. Log level = Info normal sonuçları aramak için kullanılabilir. Application ID ve özel arama alanları nasıl hazırlanacağını anlatır.
Message Monitor → Search by identifier → Application ID üzerinden kendi iş kimliğinizi arayın. Çalışma geçmişini, hata yerini ve yanıtı inceleyin. Gerektiğinde sınırlı süreli Debug/Trace ile mesajın adımlar arasındaki değişimini takip edin; kayıt seviyelerini önceden kontrol edin.
Teknik Completed sonucu iş talebinin mutlaka kabul edildiği anlamına gelmez. Akış iş kuralı reddini kontrollü yanıta çevirmiş olabilir. Teknik durum, HTTP yanıtı ve veritabanındaki kalıcı iş durumu farklı sorulara cevap verir. Parolayı veya token’ı izleme alanlarına kopyalamayın.
Tekrar göndermeden önce neyi bilmelisiniz?
Geçici bağlantı hatasında sınırlı yeniden deneme uygun olabilir. Geçersiz girdi, yetersiz stok veya değişmiş kayıt sürümünde önce iş koşulu düzeltilmelidir. Hata yönetimi sayfasındaki mekanizmaları buna göre seçin.
Özellikle timeout, “işlem yapılmadı” anlamına gelmez. Veritabanı commit etmiş, yalnız yanıt ulaşmamış olabilir. Yeni bir iş kimliği üretip tekrar göndermek yerine mevcut kimlikle kaydı okuyun. Kayıt varsa istek bilgileriyle karşılaştırın; yoksa yeniden deneme kararını verin. Aynı kimlikle farklı içerik geldiğinde nasıl davranılacağını açıkça belirleyin.
Akış içindeki bir adımı yeniden denemek, istemcinin bütün HTTP isteğini yeniden göndermesi ve kuyruktan mesajın tekrar teslim edilmesi aynı kapsam değildir. Hangisinde hangi yazmaların tekrar çalıştığını hesaba katın.
Transaction ile idempotency arasındaki fark
Transaction, tek bir denemenin parçalarını birlikte commit veya rollback eder. İdempotency, aynı iş isteği tekrar geldiğinde işin etkisinin tekrar uygulanmamasını hedefler. Birine sahip olmak diğerini kendiliğinden sağlamaz.
Kalıcı iş anahtarı, veritabanı benzersizlik kuralı ve gerekiyorsa ilk başarılı sonucun kaydı bu davranışın parçalarıdır. Çatışmayı reddetmek çift kayıt oluşmasını önleyebilir; ilk yanıtı tekrar sunan bütün bir idempotency düzeniyle aynı şey değildir. Ayrıntılı denemeler sipariş yazma örneğinde yer alır.
Tamamlandığını nasıl anlayacaksınız?
Beklenen sonuç, boş/bulunamayan kayıt, hatalı girdi, tekrar gelen mesaj ve işlem ortasında hata durumlarını kendi işinize göre sınayın. Birden çok istek aynı kaynağı değiştirecekse eşzamanlı çalışmayı da değerlendirin.
Sonuçlar doğru olduğunda bağlantı ve iş akışı dosyalarını Git ve dağıtım sürecine alın. Ortam adresi, Secret, gerekli yetkiler ve runtime bağımlılıklarını hedef ortamda yeniden doğrulayın. Deneme projesini durdurmak veritabanına yazılmış iş kayıtlarını silmez.
Hazır bir uygulamada bu kontrollerin nasıl yapıldığını görmek için sipariş ve stok örneğini kullanabilirsiniz.