Tek bir veritabanında çalışan bir uygulamada çok adımlı bir işlemi tutarlı tutmak görece kolaydır: Bütün adımlar bir veritabanı işlemi içine alınır, herhangi bir adım başarısız olursa tümü geri alınır. Ancak acente yazılımlarında kritik işlemler çoğu zaman tek bir veritabanının sınırları içinde kalmaz. Bir poliçeleştirme akışı; sigorta şirketi servisine istek göndermeyi, ödeme altyapısında tahsilat başlatmayı, poliçe belgesini almayı, acente kayıtlarını güncellemeyi ve müşteriye bildirim göndermeyi içerebilir. Bu adımların her biri farklı bir sistemde gerçekleşir ve klasik geri alma mekanizması burada çalışmaz. Saga deseni, bu tür dağıtık işlemlerde tutarlılığı sağlamanın yerleşik yöntemidir.
Saga nedir?
Saga, uzun süren bir iş sürecini her biri kendi içinde tamamlanan küçük yerel işlemlere böler. Her adım başarıyla tamamlandığında bir sonraki adım tetiklenir. Herhangi bir adım başarısız olursa, daha önce tamamlanmış adımların etkilerini tersine çeviren telafi işlemleri sırayla çalıştırılır. Yani saga, geri almayı veritabanına bırakmak yerine iş mantığı düzeyinde tanımlar.
Burada kritik bir ayrım vardır: Telafi işlemi, adımı hiç gerçekleşmemiş gibi silmek değildir. Gerçekleşmiş bir işlemin etkisini ortadan kaldıran yeni bir işlemdir. Alınmış bir tahsilat silinmez; iade edilir. Kesilmiş bir poliçe kayıttan kaldırılmaz; iptal edilir.
Örnek akış: Poliçeleştirme sagası
Kullanıcının bir kasko teklifini poliçeye dönüştürdüğünü düşünelim. Basitleştirilmiş bir saga şu adımlardan oluşabilir:
- Acente sisteminde poliçeleştirme kaydı "başlatıldı" durumunda oluşturulur.
- Ödeme altyapısında tahsilat için provizyon alınır.
- Sigorta şirketi servisine poliçeleştirme isteği gönderilir.
- Şirketten poliçe numarası ve belge alınır.
- Provizyon kesin tahsilata çevrilir.
- Acente kaydı "tamamlandı" durumuna getirilir, yenileme takibi planlanır ve müşteriye bilgilendirme gönderilir.
Her adımın bir telafi işlemi tanımlanır. Örneğin üçüncü adımda şirket isteği reddederse, ikinci adımın telafisi olarak provizyon iptal edilir ve birinci adımın telafisi olarak kayıt "başarısız" durumuna alınır. Kullanıcıya da reddin nedeni gösterilir.
Adımların sıralaması bilinçli bir tasarım kararıdır. Geri alınması en zor adım, yani bu örnekte sigorta şirketi tarafında poliçenin kesilmesi, mümkün olduğunca geç ve diğer ön koşullar sağlandıktan sonra yapılmalıdır. Kolayca geri alınabilen provizyon gibi adımlar öne alınır.
İki koordinasyon yaklaşımı
Koreografi
Merkezi bir yönetici yoktur. Her servis kendi adımını tamamladığında bir olay yayınlar; bir sonraki servis bu olayı dinleyerek kendi adımını başlatır. Az sayıda adımdan oluşan basit akışlar için uygundur ve servisler arasında gevşek bağ sağlar. Ancak adım sayısı arttıkça akışın bütününü görmek zorlaşır. Hangi olayın hangi adımı tetiklediğini anlamak için birden fazla servisin kodunu incelemek gerekir.
Orkestrasyon
Merkezi bir orkestratör, sagadaki adımları sırayla yönetir. Her servise ne yapacağını söyler, yanıtını bekler ve sonuca göre bir sonraki adıma veya telafi sürecine geçer. Akışın tamamı tek bir yerde tanımlandığı için anlaşılması, izlenmesi ve değiştirilmesi kolaydır. Poliçeleştirme gibi çok adımlı ve iş açısından kritik süreçler için genellikle bu yaklaşım tercih edilir.
Saga durumunu kalıcı tutmak
Orkestratör, sagadaki her adımın durumunu kalıcı olarak kaydetmelidir. Sunucu yeniden başlatıldığında yarıda kalmış sagalar kaldıkları yerden devam edebilmeli veya telafi sürecine girebilmelidir. Bu nedenle saga durumu bellekte değil, veritabanında bir durum makinesi olarak tutulur. Her kayıt; mevcut adımı, tamamlanan adımları, her adımın sonucunu ve son güncelleme zamanını içerir.
Belirsiz sonuçlarla başa çıkmak
Dağıtık sistemlerde en zorlu durum, bir adımın sonucunun bilinmemesidir. Sigorta şirketine poliçeleştirme isteği gönderildi ama yanıt gelmeden bağlantı koptu. Poliçe kesildi mi, kesilmedi mi? Bu durumda saga hemen telafi sürecine girmemelidir; çünkü poliçe şirket tarafında kesilmiş olabilir. Doğru yaklaşım şudur:
- Şirket bir durum sorgulama servisi sunuyorsa, işlemin durumu sorgulanır.
- Durum belirlenemiyorsa saga "doğrulama bekliyor" durumunda bekletilir ve operasyon ekibine bildirim gider.
- Kullanıcıya belirsizlik açıkça gösterilir; aynı teklif için ikinci bir poliçeleştirme başlatması engellenir.
Belirsizliği tahminle kapatmak yerine görünür kılmak, mükerrer poliçe veya yanlış iptal gibi daha ağır sorunların önüne geçer.
Telafi işlemlerinin tasarımı
Telafi işlemleri sıradan işlemlerden daha fazla dikkat gerektirir:
- İdempotent olmalıdır: Telafi işlemi birden fazla kez tetiklenebilir; ikinci çağrı ek etki üretmemelidir.
- Başarısız olabilir: Telafi işlemi de hata alabilir. Bu durumda yeniden denenir; sonunda da başarısız olursa insan müdahalesi için kayıt oluşturulur.
- İş kurallarına uygun olmalıdır: Bazı adımların telafisi zamanla sınırlıdır. Örneğin bir poliçenin iptal koşulları şirketin ve branşın kurallarına bağlıdır. Trafik, kasko ve DASK poliçelerinin iptal süreçleri farklı olabileceğinden telafi adımları branşa göre tanımlanmalıdır.
İzleme ve görünürlük
Sagaların sağlığı düzenli izlenmelidir. Belirli bir adımda takılı kalan sagaların sayısı, telafi sürecine giren sagaların oranı ve doğrulama bekleyen kayıtlar operasyon panelinde görünür olmalıdır. Her saga bir korelasyon kimliği taşırsa, bir poliçeleştirme sürecinin bütün adımları dağıtık izleme araçlarında tek bir akış olarak incelenebilir.
Ara durumların kullanıcıya gösterilmesi
Saga tamamlanana kadar kayıt bir ara durumda bulunur. Bu ara durumların kullanıcı arayüzünde anlaşılır biçimde gösterilmesi önemlidir. "Poliçeleştirme sürüyor", "şirket onayı bekleniyor" veya "işlem geri alınıyor" gibi durumlar, kullanıcının ne olduğunu anlamasını ve yanlış bir işlem başlatmamasını sağlar. Ara durumdaki bir kayıt üzerinde çelişkili işlemler, örneğin aynı teklif için ikinci bir poliçeleştirme veya henüz kesinleşmemiş bir tahsilatın iadesi, arayüz ve API düzeyinde engellenmelidir.
InsureHub'da çok adımlı işlem orkestrasyonu
InsureHub, sigorta acentelerine yazılım sağlarken poliçeleştirme ve tahsilat gibi birden fazla sisteme dokunan süreçlerin her adımının izlenebilir ve gerektiğinde telafi edilebilir olmasını hedefler. Sigorta teklif programı içinde başlayan bir teklifin poliçeye dönüşüm adımları ve Acente CRM kayıtlarındaki durum geçişleri, bu tutarlılık ilkesine dayanır.