İnternet kesildiğinde de çalışan sistemler: Pazarlarımızda neden önemli?

Pek çok sistem, internet bağlantısının her zaman var olduğu varsayımıyla tasarlanır. Ancak bu varsayım her yerde iş günü boyunca geçerli kalmaz: uzak bir şubede, bir depoda ya da bir ağ arızası veya elektrik kesintisi sırasında. Kesintiyle birlikte sistem durursa satış da durur; işlemler kâğıt üzerinde birikir, sonra hatalarıyla birlikte sisteme yeniden girilir.

Çevrim dışı çalışan bir sistem temel işini cihazın kendisinde yapar, işlemleri yerel olarak kaydeder ve bağlantı geri geldiğinde bunları merkez sunucuyla senkronize eder. Böylece çalışan işine devam eder, gerisini sistem üstlenir.

Şirket şubelerinin farklı şehirlere ve konumlara dağıldığı pazarlarda çevrim dışı çalışma, şubeler için kurulan her sistemin ya da saha çalışması için geliştirilen her uygulamanın tasarımının bir parçası hâline gelir. Bu, projenin sonunda eklenen bir özellik değil, kodlamadan önce verilen bir karardır; çünkü verilerin nasıl kaydedileceğini, numaralanacağını ve senkronize edileceğini etkiler.

Neler çevrim dışı çalışmalı?

Her işlemin çevrim dışı çalışması gerekmez; bunu her şey için kurmak gereksiz bir karmaşıklık ekler. İşin kendisinden başlayın ve şunu sorun: Ne beklemeye gelmez? Yanıt çoğu zaman bu listeye yakındır:

• Satış ve müşteriye fiş kesilmesi.
• Nakit tahsilatların kaydı.
• Mal kabulü ve stok hareketlerinin kaydı.
• Depoda ya da şubede stok sayımı.
• Cihazda kayıtlı fiyatların ve ürün bilgilerinin görüntülenmesi.

Şubeleri kapsayan toplu raporlar, merkezden verilen onaylar ve ana fiyatların değiştirilmesi ise genellikle bağlantının geri gelmesini bekleyebilir. Bu ayrım yazılı ve üzerinde uzlaşılmış olduğunda, her çalışan kesinti sırasında neyi yapabileceğini ve neyi ertelemesi gerektiğini bilir.

Birkaç şubesi ve bir merkez deposu olan bir ticaret şirketi varsayalım. Şubede, bağlantıya ne olursa olsun satış, fiş kesme ve nakit kaydı sürmelidir; depoda da mal kabulü ve sayım devam etmelidir. Büyük indirimlerin onaylanması ve şubeler arası mal transferi ise bağlantının geri gelmesini bekleyebilir; çünkü ikisi de zaten merkezin onayını gerektirir.

Yerel depolama ve senkronizasyon

Cihazın çevrim dışı çalışabilmesi için kullandığı verilerin yerel bir kopyasına ihtiyacı vardır: ürünler, fiyatlar, müşteriler ve şubeye ait stok bakiyeleri. Her işlem, girildiği anda geçici belleğe değil, cihazdaki bir veri tabanına kaydedilir; böylece cihaz aniden kapansa bile hiçbir şey kaybolmaz.

Ardından senkronizasyon gelir; asıl zorluk da buradadır. Kaydedilen işlemler bir kuyruk üzerinden, sırasıyla sunucuya gönderilir ve sunucu alındığını onaylayana kadar gönderim yeniden denenir. Aynı işlem sunucuya iki kez ulaşırsa sunucu bunu tanımalı ve iki kez kaydetmemelidir.

Diğer yönde ise cihaz, merkezde değişenleri alır: yeni fiyatlar, eklenen ürünler, diğer şubelerin güncellediği bakiyeler. Her cihaza neyin ve ne zaman indirileceğini belirlemek önemli bir tasarım kararıdır; çünkü tüm verileri her cihaza indirmek senkronizasyonu yavaşlatır ve korunması gerekenlerin kapsamını genişletir.

Her işlemle birlikte, işlemin cihazda fiilen girildiği zaman ve sunucuya ulaştığı zaman kaydedilir; çünkü raporlar için birincisi, inceleme için ikincisi gerekir. Şubeler arasındaki işlemleri sıralamak için yalnızca cihaz saatine güvenilmez; çünkü cihaz saatleri farklı olabilir ya da elle değiştirilebilir.

Çakışma: iki şube aynı kaydı değiştirdiğinde

İki şubenin kesinti sırasında aynı ürünün son adedini sattığını ya da şube çevrim dışıyken merkezin bir fiyatı değiştirdiğini ve şubenin eski fiyattan satış yaptığını varsayalım. Bağlantı geri geldiğinde sunucuya birbiriyle çelişen iki değişiklik ulaşır ve sistemin bunlarla ne yapacağını bilmesi gerekir.

Bunlar teknik sorular olmadan önce iş sorularıdır ve yanıtları kodlamadan önce netleşmelidir. Bu çakışmaları çözmek için yaygın kurallardan bazıları şunlardır:

• Finansal işlemler iptal edilmez ve birleştirilmez: Gerçekleşen satış olduğu gibi kalır; stoktaki açık, sorumlu kişinin incelediği görünür bir düzeltme hareketiyle ele alınır.
• Fiyatlar gibi ana verilerin sahibi merkezdir; şubeden bunlardan farklı bir değer gelirse kaydedilir ve sorumlu kişi uyarılır.
• Müşterinin telefonu ya da adresi gibi bazı alanlarda son değişiklik geçerli sayılır; önceki değer kayıt geçmişinde saklanır.
• Yazılı bir kuralın çözmediği durumlar, inceleyecek belirli bir kişiye iletilir; sessizce karara bağlanmaz.

Çakışma çözüm kuralları, koda dönüşmeden önce birer iş kararıdır; yazılım geliştiriciler bunları yazmadan önce işin sahipleri bu kurallar üzerinde uzlaşmalıdır.

Belge numaralama ve çalışanın gördükleri

İki şube çevrim dışıyken fiş kestiğinde, ikisi de sıradaki numarayı sunucuya soramaz. Tüm cihazlar tek bir genel numara serisi kullanırsa, senkronizasyonda numaralar tekrarlanır ve belgeler birbirine karışır.

Çözüm, her belgenin cihazın kendisinde oluşturulan tekil bir kimlik ve görünür bir numara taşımasıdır; bu numara, şube ya da cihaz kodunu ve o şubenin ya da cihazın kendi sıra numarasını içerir. Böylece senkronizasyonda iki belge çakışmaz, numara müşteri ve muhasebeci için anlaşılır kalır ve her belge, onu düzenleyen şubeye ve cihaza kadar izlenebilir.

Çalışanın da kimseye sormadan işinin durumunu bilmesi gerekir. Ekranda cihazın bağlı olup olmadığı, kaç işlemin gönderilmeyi beklediği ve son başarılı senkronizasyonun ne zaman yapıldığı açıkça görünür. Senkronizasyonda bir işlem reddedilirse çalışana gerekçesiyle birlikte gösterilir; iz bırakmadan kaybolmaz.

Yöneticinin de merkezde bunun karşılığı olan bir görünüme ihtiyacı vardır: hangi şubelerin bir süredir senkronize olmadığı ve hangi cihazlarda geciken işlemler bulunduğu. Gösterge panelinde sakin görünen bir şube, satışsız değil, bağlantısız olabilir.

Yerel verilerin güvenliği ve kesinti testi

Bir şubedeki ya da bir satış temsilcisinin elindeki cihazda saklanan veriler, sunucudaki verilere göre kaybolmaya ya da çalınmaya daha açıktır. Bu yüzden hassasiyetlerine uygun biçimde korunur: yerel veri tabanının şifrelenmesi, parolaların düz metin olarak saklanmaması, çevrim dışı da çalışan bir oturum açma ve kaybolan bir cihazı devre dışı bırakıp senkronize olmasını engelleme imkânı. Sistem, cihaza neyin indirileceğini belirlediği gibi, senkronize edildikten sonra cihazdan neyin silineceğini de belirler.

Kullanıcı yetkileri sunucuda olduğu gibi cihazda da geçerlidir. Bağlantı varken indirim yapma ya da fiş iptal etme yetkisi olmayan bir çalışanın, kesinti sırasında da bu yetkisi yoktur. Cihaz, her işlemin ve o işlemi kimin yaptığının kaydını tutar; bu kayıt senkronizasyonla birlikte merkeze gönderilir.

Teste gelince, sistemin ağ bağlıyken başarıyla çalışması yeterli değildir. Test ortamındaki bir cihazın ağ bağlantısını saatler süren simüle edilmiş bir çalışma boyunca kesin, sonra bağlantıyı yeniden kurun ve gözlemleyin: İşlemler merkezde olduğu gibi, tekrar ya da eksik olmadan göründü mü?

Bir işlemin ortasında cihazı kapatmayı, senkronizasyonun ortasında bağlantının kesilmesini ve aynı kaydın iki cihazdan değiştirilmesini de deneyin; ardından her durumda sonucu kontrol edin. Bu senaryolar, gerçek bir kesintinin yoğun bir iş gününde ortaya çıkarabileceği sorunları canlıya geçişten önce gösterir.

Bu testlere şubelerin kendi çalışanlarının da katılması tercih edilir; çünkü kesinti anında gerçekte ne olduğunu onlar bilir: fişi kimin yazdırdığını, nakdi kimin kaydettiğini ve şube kalabalıklaştığında neyin geciktiğini.

Kodlamadan önce kontrol listesi

• Çevrim dışı sürmesi gereken işlemlerin ve bağlantının geri gelmesini bekleyecek işlemlerin yazılı listesi.
• Her cihazda hangi verilerin ve ne kadar süreyle saklanacağının belirlenmesi.
• Her veri türü için işin sahipleriyle uzlaşılmış çakışma çözüm kuralları.
• Sunucu bağlantısına dayanmayan bir belge numaralama yöntemi.
• Çalışanın görebildiği bir senkronizasyon durumu ve reddedilen işlemlerin net biçimde ele alınması.
• Yerel verilerin korunması ve kaybolan bir cihazı devre dışı bırakmanın bir yolu.
• Kesinti, bağlantının geri gelmesi ve ani kapanma için test senaryoları.

Bağlantı kesildiğinde iş onunla birlikte durmamalıdır. Mevcut sisteminiz internet kesildiğinde duruyorsa ya da birden fazla şube için yeni bir sistem veya sahada çalışacak bir mobil uygulama planlıyorsanız, durumunuzu ITS ekibiyle görüşebilirsiniz; hangi işlemlerin sürmesi gerektiğini ve bunların senkronizasyonunun nasıl ele alınacağını birlikte belirleyelim.