Sahada çalışan bir acente temsilcisi, müşteri ziyaretinde mobil uygulamada müşterinin telefon numarasını ve notlarını günceller. O sırada bağlantı zayıftır, değişiklik cihazda bekler. Aynı dakikalarda ofisteki bir çalışma arkadaşı web panelinde aynı müşterinin e-posta adresini ve adres bilgisini düzeltir. Temsilcinin cihazı bağlantıyı yeniden kurduğunda iki farklı değişiklik kümesi aynı kayıt üzerinde buluşur. Hangisi geçerli olacak? Bu sorunun cevabı, çevrimdışı destekleyen her uygulamanın en kritik tasarım kararlarından biridir.
Çakışma neden kaçınılmazdır?
Çevrimdışı çalışma, kullanıcıya bağlantıdan bağımsız hareket özgürlüğü verir. Bunun bedeli, aynı verinin bir süreliğine birden fazla yerde bağımsız olarak değişebilmesidir. Sunucu ile cihaz arasında sürekli bir bağlantı olmadığı için hiçbir taraf diğerinin o anda ne yaptığını bilemez. Çakışmayı tamamen önlemenin tek yolu çevrimdışı düzenlemeyi yasaklamaktır; bu da sahada çalışan ekipler için kabul edilemez bir kısıttır. Dolayısıyla amaç çakışmayı engellemek değil, çakışmayı doğru tespit edip makul biçimde çözmektir.
Önce tespit: Çakışmayı nasıl fark edersiniz?
Çakışmayı çözmeden önce varlığını güvenilir biçimde tespit etmek gerekir. Bunun için her kayıt bir sürüm bilgisi taşımalıdır. Yaygın yöntemler şunlardır:
- Sürüm numarası: Kayıt her güncellendiğinde sunucuda artan bir sayı. Cihaz, değişikliği gönderirken düzenlemeye başladığı sürüm numarasını da iletir. Sunucudaki sürüm farklıysa araya başka bir değişiklik girmiştir.
- Değişiklik zaman damgası: Basit ama cihaz saatlerinin güvenilmez olabileceği unutulmamalıdır. Sunucu tarafında atanan zaman damgaları daha güvenilirdir.
- İçerik özeti: Kaydın düzenleme öncesi halinin özeti saklanır ve sunucudaki güncel halin özetiyle karşılaştırılır.
Sürüm numarası, iyimser eşzamanlılık kontrolü olarak bilinen yaklaşımın temelidir ve çoğu senaryo için en dengeli seçenektir.
Çözüm stratejileri
Son yazan kazanır
En basit stratejidir: Sunucuya en son ulaşan değişiklik geçerli olur. Uygulaması kolaydır ama sessiz veri kaybına yol açar. Yukarıdaki örnekte temsilcinin değişikliği sonra ulaşırsa, ofisteki arkadaşın düzelttiği e-posta ve adres bilgisi kaybolur ve kimse bunu fark etmez. Bu strateji yalnızca kaybın önemsiz olduğu alanlarda, örneğin kullanıcının arayüz tercihleri gibi verilerde kabul edilebilir.
Alan bazlı birleştirme
Kayıt bir bütün olarak değil, alan alan değerlendirilir. Temsilci telefon ve notları, ofisteki kullanıcı e-posta ve adresi değiştirdiyse, iki değişiklik farklı alanlara dokunduğu için çakışma yoktur ve ikisi de uygulanır. Gerçek çakışma yalnızca aynı alan iki tarafta farklı değerlere değiştirildiğinde ortaya çıkar. Bu yaklaşım, çakışmaların büyük çoğunluğunu kullanıcıya hiç yansıtmadan otomatik olarak çözer.
Alan bazlı birleştirme için cihazın yalnızca değişen alanları ve bu alanların düzenleme öncesi değerlerini göndermesi gerekir. Kaydın tamamını göndermek, hangi alanın gerçekten değiştiğini belirsizleştirir.
Alan türüne göre kurallar
Bazı alanlar doğası gereği birleştirilebilir. Notlar veya etiketler gibi liste türündeki alanlarda iki taraftaki eklemelerin ikisi de korunabilir. Bir görüşme notu sahada, diğeri ofiste eklendiyse ikisi de müşterinin geçmişinde yer almalıdır. Tek değerli alanlarda ise bir kural seçilmelidir.
Kullanıcıya sormak
Aynı alan iki tarafta farklı değerlere değiştirildiyse ve hangisinin doğru olduğu kurala bağlanamıyorsa, karar kullanıcıya bırakılır. Uygulama iki değeri yan yana göstererek hangisinin korunacağını sorar. Bu seçenek en doğru sonucu verir ama kullanıcıyı yorar; bu yüzden yalnızca gerçekten gerekli durumlarda kullanılmalıdır.
Hangi veriler çevrimdışı düzenlenmemeli?
Her veri türü çevrimdışı düzenlemeye uygun değildir. Bazı işlemler doğası gereği anlık sunucu teyidi gerektirir:
- Teklif sorguları: Trafik, kasko ve DASK sorguları sigorta şirketi servislerine canlı erişim gerektirir. Çevrimdışıyken sorgu girdileri taslak olarak hazırlanabilir, ama sorgu ancak bağlantı geldiğinde başlatılmalıdır.
- Poliçeleştirme: Sonucu kalıcı ve dış sistemde kayıtlı bir işlemdir; çevrimdışı kuyruğa alınıp sessizce sonradan gönderilmemelidir.
- Tahsilat kaydı: Muhasebe tutarlılığı açısından çakışma riski taşımamalıdır.
Bu işlemlerde uygulama kullanıcıya bağlantı gerektiğini açıkça göstermelidir.
Senkronizasyon sırası ve bağımlılıklar
Çevrimdışıyken yapılan değişiklikler birbirine bağımlı olabilir. Temsilci önce yeni bir müşteri oluşturup ardından bu müşteriye not eklemiş olabilir. Senkronizasyon sırasında not, müşteri kaydından önce gönderilirse sunucu notu ilişkilendirecek bir kayıt bulamaz. Bu yüzden bekleyen değişiklikler oluşturulma sırasına göre gönderilmeli ve cihazda oluşturulan kayıtlar için geçici kimlikler kullanılarak sunucunun atadığı kalıcı kimliklerle eşleştirilmelidir.
Silme işlemleri ve mezar taşı kayıtları
Çevrimdışı senaryolarda silme işlemleri özel dikkat gerektirir. Ofisteki kullanıcı bir görevi silerken sahadaki temsilci aynı görevi tamamlandı olarak işaretlemiş olabilir. Sunucu kaydı tamamen silerse, cihazdan gelen güncelleme ya hata verir ya da kaydı yeniden oluşturur. Bu sorunu önlemek için silinen kayıtlar fiziksel olarak hemen kaldırılmaz; "silindi" işaretiyle bir süre saklanır. Bu işaretli kayıtlara mezar taşı kaydı denir. Cihaz senkronize olduğunda silme bilgisini alır ve kendi yerel kopyasını da kaldırır. Silinmiş bir kayda gelen güncellemeler için ise açık bir kural belirlenmelidir: Silme mi geçerli olacak, yoksa kayıt geri mi getirilecek?
Senkronizasyonu test etmek
Çakışma çözümü, yalnızca normal kullanımda değil uç senaryolarda da test edilmelidir. Uçak modunda yapılan çoklu düzenlemeler, aynı kaydın iki cihazda değiştirilmesi, senkronizasyonun yarıda kesilmesi ve uygulamanın bu sırada kapatılması gibi durumlar bilinçli olarak denenmelidir. Bu testlerde aranan sonuç, hiçbir değişikliğin sessizce kaybolmaması ve her iki tarafın sonunda aynı veriye ulaşmasıdır.
Kullanıcıya şeffaflık
Çevrimdışı çalışmanın güven vermesi için kullanıcının neyin senkronize edildiğini, neyin beklediğini görebilmesi gerekir. Bekleyen değişiklik sayısını gösteren küçük bir gösterge, son başarılı senkronizasyon zamanı ve otomatik çözülen çakışmalar hakkında kısa bilgilendirmeler kullanıcının sisteme güvenini artırır.
InsureHub mobil senkronizasyon ilkeleri
InsureHub, sigorta acentelerine sunduğu mobil sigorta uygulaması ile web paneli arasındaki veri tutarlılığını, sahada çalışan ekiplerin özgürlüğünü kısıtlamadan sağlamayı hedefler. Acente CRM kayıtlarında alan bazlı yaklaşım, farklı kişilerin aynı müşteri üzerinde yaptığı düzenlemelerin birbirini ezmemesine yardımcı olurken teklif ve poliçeleştirme gibi işlemler canlı bağlantıyla yürütülür.