Tekrar denemek neden dikkat ister?
Bir teklif sorgusu başarısız olduğunda ilk akla gelen çözüm, sorguyu tekrar göndermektir. Geçici bir ağ sorunu ya da kısa süreli bir yoğunluk nedeniyle başarısız olan bir istek, birkaç saniye sonra tekrarlandığında çoğu zaman başarılı olur. Bu nedenle tekrar deneme, teklif altyapısının vazgeçilmez bir parçasıdır.
Ancak kontrolsüz tekrar denemeler yeni sorunlar doğurur. Aynı isteğin kısa aralıklarla defalarca gönderilmesi, zaten zorlanan bir sistem üzerinde ek yük oluşturur. Daha da önemlisi, ilk istek aslında karşı tarafta işlenmiş ama yanıtı ulaşmamışsa, tekrar gönderilen istek mükerrer bir işlem oluşturabilir. Bu yazıda teklif sorgularında güvenli bir tekrar deneme politikasının nasıl kurulabileceğini ele alıyoruz.
Hangi hatalar tekrar denenmeli?
Tekrar deneme politikasının ilk adımı, hataları tekrar denenebilir ve tekrar denenemez olarak ayırmaktır. Her hatayı tekrar denemek, kalıcı sorunlarda boşuna zaman ve kaynak harcanmasına neden olur.
Tekrar denenebilir hatalar
- Ağ bağlantısının geçici olarak kesilmesi
- Zaman aşımı
- Karşı sistemin geçici yoğunluk bildirmesi
- Karşı sistemin kısa süreli bakımda olması
Tekrar denenmemesi gereken hatalar
- Eksik ya da hatalı veri nedeniyle reddedilen istekler
- Geçersiz kimlik doğrulama bilgileri
- Yetki dışı işlem bildirimi
- Ürünün ya da teminatın ilgili şirkette sunulmadığı bilgisi
Veri kaynaklı bir hatada sorguyu tekrar göndermek sonucu değiştirmez; bu durumda kullanıcının veriyi düzeltmesi gerekir. Kimlik doğrulama hatalarında ise tekrar denemeler, bazı sistemlerde hesabın geçici olarak kilitlenmesine bile yol açabilir.
Denemeler arasındaki bekleme süresi
Tekrar denemelerin hemen arka arkaya yapılması, geçici sorunun çözülmesine zaman tanımaz. Denemeler arasında artan bekleme süreleri kullanmak yaygın ve etkili bir yöntemdir. İlk tekrar kısa bir süre sonra, sonraki tekrarlar giderek uzayan aralıklarla yapılır.
Bekleme sürelerine küçük rastgele farklar eklemek de faydalıdır. Aynı anda başarısız olan çok sayıda istek, tam olarak aynı anda tekrar gönderilirse yeni bir yük dalgası oluşturur. Rastgele farklar, bu isteklerin zamana yayılmasını sağlar.
Deneme sayısına sınır koymak
Her tekrar deneme politikasının bir üst sınırı olmalıdır. Belirlenen deneme sayısına ulaşıldığında sorgu başarısız olarak işaretlenir ve kullanıcıya bildirilir. Sınırın olmaması, kalıcı bir sorunda sistemin aynı isteği süresiz tekrarlamasına neden olur.
Etkileşimli sorgularda deneme sayısı ve toplam bekleme süresi daha sınırlı tutulmalıdır; çünkü çalışan müşteriyle görüşürken sonucu beklemektedir. Planlı sorgularda ise daha uzun bir deneme süreci kabul edilebilir.
Mükerrer istek riski
Teklif sorgusu çoğu durumda yalnızca bilgi alan bir işlemdir ve tekrarlanması karşı tarafta kalıcı bir değişiklik oluşturmaz. Ancak bazı entegrasyonlarda teklif sorgusu karşı sistemde bir teklif kaydı oluşturur. Bu durumda yanıtı ulaşmayan bir isteğin tekrar gönderilmesi, aynı müşteri için birden fazla teklif kaydı açılmasına yol açabilir.
Mükerrer riski azaltmanın yolları
- Her sorgu isteğine benzersiz bir işlem anahtarı atamak ve tekrarlarda aynı anahtarı kullanmak
- Karşı sistem destekliyorsa bu anahtarla mükerrer istekleri tanımasını sağlamak
- Tekrar göndermeden önce, mümkünse önceki isteğin durumunu sorgulamak
- Aynı teklif kaydı için aynı anda birden fazla sorgunun başlatılmasını engellemek
Kullanıcı arayüzünde de mükerrer isteklerin önüne geçilmelidir. Sorgu düğmesine art arda basılması ya da sayfanın yenilenmesi, aynı sorgunun iki kez başlatılmasına neden olmamalıdır.
Kullanıcının başlattığı yeniden deneme
Otomatik tekrar denemelerin yanı sıra, kullanıcıya belirli bir şirket için sorguyu manuel olarak yeniden başlatma imkanı tanınabilir. Bu seçenek, otomatik denemeler tükendikten sonra ya da kullanıcı veriyi düzelttikten sonra kullanılır. Manuel yeniden denemenin yalnızca ilgili şirket için yapılması, diğer şirketlerden gelmiş sonuçların korunmasını sağlar.
Manuel denemenin de aynı mükerrer koruma kurallarına tabi olması gerekir. Kullanıcı önceki istek henüz sonuçlanmamışken yeniden deneme yapmaya çalışırsa, sistem bunu fark etmeli ve kullanıcıyı bilgilendirmelidir.
Branş akışlarına göre politika
Trafik, kasko ve DASK sorgularının entegrasyon davranışları farklı olabilir. InsureHub'da bu üç branş ayrı teklif sorgu akışlarıdır; tekrar deneme politikasının da branş ve sigorta şirketi bazında ayarlanabilmesi faydalıdır. Örneğin bir şirketin DASK entegrasyonu farklı bir zaman aşımı davranışına sahipse, bu akış için bekleme süreleri ayrı tanımlanabilir.
Tekrar denemelerin kayıt altına alınması
Her deneme, zamanı, sonucu ve hata türüyle birlikte kaydedilmelidir. Bu kayıtlar, bir sorgunun neden uzun sürdüğünü anlamayı ve entegrasyonlardaki tekrarlayan sorunları tespit etmeyi sağlar. Belirli bir şirkette tekrar deneme sayısının artması, bağlantıda bir sorun olduğunun erken işaretidir. Bu bilgiler sigorta acentesi yazılımı içindeki izleme ekranlarında yöneticiye sunulabilir.
Kontrol listesi
- Hataları tekrar denenebilir ve denenemez olarak sınıflandırın
- Artan bekleme süreleri ve küçük rastgele farklar kullanın
- Deneme sayısına etkileşimli ve planlı sorgular için ayrı sınırlar koyun
- Her isteğe benzersiz işlem anahtarı atayın
- Arayüzde art arda sorgu başlatmayı engelleyin
- Tüm denemeleri kayıt altına alın
Kullanıcıya deneme bilgisini göstermek
Otomatik tekrar denemeler arka planda yürüse de kullanıcının bundan haberdar olması faydalıdır. Sonuç satırında "yeniden deneniyor" gibi kısa bir durum bilgisi, çalışanın sorgunun takıldığını düşünüp gereksiz yere manuel deneme yapmasını önler. Denemeler tükendiğinde ise satırın açıkça başarısız duruma geçmesi ve sonraki adımın önerilmesi gerekir.
Sonuç
Tekrar deneme, geçici sorunları kullanıcıya yansıtmadan çözmenin etkili bir yoludur; ancak yalnızca doğru hatalar için, kontrollü aralıklarla ve sınırlı sayıda yapıldığında. Mükerrer isteklere karşı alınan önlemler ise tekrarların yeni sorunlar doğurmasını engeller. Bu politikaların sigorta teklif programı içinde nasıl çalıştığını görmek için demo talebi oluşturabilirsiniz.