Sistem entegrasyonunda hata senaryoları ve retry yaklaşımı, önce hangi verinin kritik olduğunun ayrıştırılmasıyla belirlenir; çünkü her hata aynı biçimde ele alınmaz. Saha operasyonu ve puantaj akışında giriş çıkış, lokasyon, vardiya, izin ve onay kayıtları farklı önem taşır. Bu nedenle entegrasyon retry politikası; geçici ağ sorunları, servis zaman aşımı, kuyruk gecikmesi ve doğrulama hataları için ayrı kurallar içermelidir. Kalıcı veri hatalarında otomatik tekrar yerine insan kontrolü gerekir. Sahadan gelen kayıtların bozulmaması için kuyruklama, idempotent işlem mantığı ve hata günlüğü birlikte tasarlanır. Akıllı Şantiye gibi kuruma özel geliştirilen bir yapı, /urunler/akilli-santiye bağlantısında görülebileceği üzere, puantajı tek başına giriş çıkış kaydı olarak değil; saha operasyonu, vardiya ve onay zinciriyle birlikte ele alır. Böylece entegrasyon retry politikası, sadece teknik bir ayar değil, iş kuralının parçası olur ve manuel kontrol yükü dengelenir. Ayrıca sahada aynı gün içinde birden fazla giriş-çıkış oluştuğunda, sistemin hangi kaydı esas alacağı önceden tanımlanmalıdır. Aksi halde operatör, kayıt düştü mü düşmedi mi diye tekrar tekrar işlem yapar ve bu da çift kayıt riskini artırır. Bu yüzden hata senaryosu tasarlanırken kullanıcı davranışı da hesaba katılır.
Hata senaryolarını sınıflandırmak
Entegrasyon retry politikası oluştururken ilk adım, hatayı kaynağına göre sınıflandırmaktır. Geçici ağ kopması, servis yanıt vermemesi, veri formatı uyuşmazlığı, yetki hatası, çift kayıt oluşması ve onay bekleyen işlem aynı değildir. Geçici olanlar için tekrar deneme anlamlıdır; veri yanlışsa aynı isteği yinelemek sorunu büyütür. Bu ayrım yapılmazsa sistem, sahada kaydı bekletir ya da yanlış veriyi tekrarlar. Saha operasyonunda puantaj verisi çoğu zaman mobil cihazdan, terminalden ya da farklı lokasyonlardan gelir. Bu nedenle hata senaryosu yalnızca teknik katmanda değil, kullanım bağlamında da değerlendirilmelidir. Örneğin internet kesintisi sırasında kayıt cihazda tutulur, bağlantı gelince sıraya alınır ve entegrasyon retry politikası buna göre çalışır. Ancak personel kimliği eşleşmiyorsa otomatik tekrar yerine inceleme gerekir. Burada amaç, her hatayı aynı kefeye koymadan iş sürekliliğini korumaktır. Bu yaklaşım, manuel kontrolü azaltırken denetim ihtiyacını ortadan kaldırmaz; yalnızca doğru noktaya taşır. Kuruma özel kurgu, /hizmetler/kurumsal-web-yazilimlari kapsamında ele alınan entegrasyon mantığıyla birlikte tasarlanır. Pratikte bu sınıflandırma, destek ekibinin de işini kolaylaştırır; çünkü hangi hata için sistemin otomatik aksiyon aldığı, hangisinde uyarı ürettiği açık olur. Böylece “kayıt neden gitmedi” sorusu tek bir teknik başlığa sıkışmaz, iş akışının parçası olarak okunur.
Retry kararını belirleyen iş kuralları
Entegrasyon retry politikası teknik bir süre ayarı gibi görünse de asıl belirleyici iş kuralıdır. Hangi kaydın otomatik yeniden denenebileceği, hangi kaydın durdurulacağı ve hangisinin onaya düşeceği önceden tanımlanmalıdır. Puantajda giriş çıkış kaydı, vardiya değişimi, fazla mesai ve izin hareketleri farklı öncelik taşır. Örneğin geçici servis hatasında giriş kaydı yeniden gönderilebilir; ancak aynı personel için çelişkili iki lokasyon kaydı varsa otomatik tekrar yerine uyarı gerekir. Bu noktada entegrasyon retry politikası, sadece “kaç kez denensin” sorusuna değil, “hangi koşulda denensin” sorusuna da cevap vermelidir. İş kuralı net değilse saha şefi, insan kaynakları ve yönetici aynı veriyi farklı yorumlar. Bu karışıklığı azaltmak için kayıtların statüsü, sorumlusu ve son işlem zamanı açık tutulur. Mobil kayıt ile manuel puantaj arasındaki fark da burada belirginleşir: mobil kayıt anlıktır, manuel kayıt sonradan girilebilir; fakat ikisi aynı doğrulama zincirinden geçmelidir. Böylece saha operasyonu ile puantaj aynı sistemde yönetilebilir ve entegrasyon retry politikası iş akışını bozmaz. Ayrıca bazı kurumlarda vardiya başlangıcı ile bitişi aynı anda işlenmez; bu durumda retry sırası da önem kazanır. Önce eksik olan kayıt tamamlanır, sonra raporlama katmanı güncellenir. Bu tür ayrıntılar, politikayı soyut bir teknik ayardan çıkarıp operasyonel bir kurala dönüştürür.
İnternet kesintisi ve veri kaybı riski
Saha ortamında en sık sorulan konulardan biri, bağlantı yokken ne olacağıdır. Entegrasyon retry politikası burada yalnızca tekrar deneme değil, kaybı önleme yaklaşımıdır. Mobil cihaz çevrimdışı çalışabiliyorsa kayıt yerelde saklanır, sıra numarası verilir ve bağlantı geldiğinde gönderilir. Bu sırada aynı kaydın iki kez işlenmemesi için idempotent yapı gerekir. Aksi halde internet geri geldiğinde tekrar eden kayıtlar puantajı bozabilir. Saha ekibinin kolay benimsemesi için süreç görünmez karmaşıklık taşımamalıdır; kullanıcı tek bir kayıt yapar, sistem arkada senkronizasyonu yönetir. Ancak bu otomasyon, denetimi ortadan kaldırmaz. Özellikle şantiye, vardiya ve farklı lokasyonlarda kayıtlar çakışabilir. Bu nedenle entegrasyon retry politikası, bekleyen kayıtların durumunu açıklayan ekranlar ve uyarı mekanizmalarıyla desteklenmelidir. İnternet kesildiğinde verinin kaybolmaması kadar, bağlantı döndüğünde hangi kaydın hangi sırayla işlendiği de önemlidir. Burada /hizmetler/mobil-uygulama-gelistirme yaklaşımı, saha kullanıcı deneyimini sade tutmak için referans alınabilir; fakat asıl ihtiyaç, saha verisini merkezi kurallarla güvene almaktır. Eğer bağlantı uzun süre gelmezse, sistemin bekleme süresi dolduğunda ne yapacağı da önceden belirlenmelidir. Kayıt askıda mı kalacak, yöneticiyi mi uyaracak, yoksa yerel bellekte mi tutulacak; bu soruların cevabı operasyonun kesintisizliği için kritiktir.
Onay akışı, bordro ve insan kaynakları uyumu
Puantaj sistemi yalnızca bordro için kullanılmaz; onay, denetim ve insan kaynakları akışının da parçasıdır. Entegrasyon retry politikası bu nedenle onay bekleyen kayıtlarla bordroya giden kayıtları ayırmalıdır. Saha şefi tarafından doğrulanmamış bir fazla mesai kaydı otomatik olarak bordroya aktarılmamalıdır. Aynı şekilde eksik giriş, geç çıkış veya lokasyon uyuşmazlığı gibi durumlar insan kaynakları ekranına düşmelidir. Kurum içinde yönetici, saha şefi ve insan kaynakları aynı veriyi farklı yetkilerle görmelidir; biri operasyonel ayrıntıyı, diğeri özet durumu izler. Bu yapı kurulmadığında manuel kontrol yükü artar ve kayıtlar arasında tutarsızlık oluşur. Taşeron personel ile kadrolu ekiplerin aynı yapıda yönetilmesi de mümkündür; önemli olan personel tipine göre onay zincirinin değişebilmesidir. Entegrasyon retry politikası, onay bekleyen veriyi sürekli tekrar göndermek yerine doğru rolün önüne taşımalıdır. Böylece sahadan gelen veri, bordro ve izin yönetimi süreçlerine kontrollü biçimde aktarılır. Bu yaklaşım, /urunler/akilli-santiye içinde kurgulanan saha operasyonu mantığıyla uyumlu çalışır ve puantajı yalnızca kayıt değil, süreç verisi haline getirir. Ayrıca onay geciktiğinde sistemin sessiz kalmaması gerekir; bekleyen kayıtların kaç saattir onayda olduğu izlenebilmelidir. Böylece hem bordro kapanışları hem de aylık kontrol süreçleri daha öngörülebilir hale gelir.
Doğrulama, denetim ve sürdürülebilir yapı
Sahadan gelen verinin doğruluğu, tek başına dijital kayıtla güvence altına alınmaz; doğrulama katmanları gerekir. Entegrasyon retry politikası bu doğrulama katmanlarıyla birlikte düşünülmelidir. Personelin giriş çıkışı cihaz, lokasyon, zaman ve onay bilgisiyle birlikte değerlendirilirse sahte veya hatalı kayıtların etkisi azalır. Ancak sistem ne kadar iyi kurulursa kurulsun, her şantiyede aynı puantaj kurgusu kullanılamaz. Vardiya düzeni, taşeron yoğunluğu, saha izinleri ve lokasyon sayısı değiştikçe iş kuralı da değişir. Bu yüzden kuruma özel geliştirme yaklaşımı önemlidir; hazır kalıp yerine işleyişe uyarlanmış akış gerekir. Entegrasyon retry politikası da bu uyarlamanın parçasıdır. Hangi hatanın kaç kez deneneceği, hangi kaydın beklemeye alınacağı ve hangi durumda manuel inceleme yapılacağı canlı işleyişe göre belirlenir. Böylece dijitalleşme, saha denetimini kaldırmaz; denetimi daha izlenebilir hale getirir. Kurumlar, sistemin teknik tarafını değil, iş sonucunu yönetmek ister. Bu nedenle retry kuralları sade, izlenebilir ve açıklanabilir olmalıdır. Gerekli entegrasyon mantığı, /sektorler/insaat-taahhut ve ilgili saha süreçleriyle uyumlu biçimde tasarlanır. Denetim tarafında önemli olan bir başka konu da logların geriye dönük okunabilmesidir; hangi denemenin ne zaman yapıldığı, hangi hatanın tekrarlandığı ve neden durdurulduğu sonradan izlenebilmelidir. Bu sayede hem iç kontrol hem de operasyonel şeffaflık güçlenir.
Sık sorulan sorular
Retry politikası kaç kez deneme yapmalı
Bu sayı sabit bir kural olarak belirlenmemelidir. Geçici servis hataları ile veri doğrulama hataları farklı ele alınır. Entegrasyon retry politikası, işin kritikliği, kayıt türü ve hata nedeni üzerinden kurulur. Amaç, gereksiz tekrarları azaltırken sahadaki kaydı kaybetmemektir. Bazı durumlarda tek bir tekrar yeterli olabilir; bazı durumlarda ise deneme yerine doğrudan uyarı üretmek daha doğrudur. Bu nedenle sayıdan önce hata tipi ve iş etkisi değerlendirilir.
Manuel kontrol ne zaman gerekir
Kayıt çelişkiliyse, kimlik eşleşmiyorsa ya da aynı personel için birden fazla lokasyon görünüyorsa manuel kontrol gerekir. Entegrasyon retry politikası bu tür durumlarda otomatik tekrar yerine uyarı üretmelidir. Böylece yanlış veri bordroya taşınmadan önce yakalanır. Ayrıca onay zinciri tamamlanmamış kayıtlar da manuel inceleme gerektirebilir. Bu, sistemin zayıflığı değil; iş kuralının gereğidir.
Taşeron ve kadrolu ekipler birlikte yönetilebilir mi
Evet, aynı yapıda yönetilebilir. Fark, personel tipine göre onay akışında ve raporlama alanlarında ortaya çıkar. Entegrasyon retry politikası bu ayrımı korumalı, ama veri modelini bölmemelidir. Böylece sahadaki tüm ekipler tek sistemde izlenebilir. Gerekirse taşeron kayıtları için farklı onay adımları tanımlanır, ancak temel entegrasyon mantığı aynı kalır. Bu da yönetimi sadeleştirir ve raporlamayı tutarlı hale getirir.