API, Entegrasyon ve Kurumsal Sistemler
Kurumsal Veri Senkronizasyonunda Çakışma Yönetimi
Aynı kayıt farklı sistemlerde değiştiğinde hangi güncelleme korunmalı? Alan sahipliği, sürüm kontrolü ve uzlaştırma kurallarıyla veri çakışmalarını yönetin.

Çakışma yalnızca aynı anda yazmak değildir
Satış ekibi CRM’de müşterinin telefonunu güncellerken muhasebe ekibi ERP’de aynı müşterinin ödeme koşulunu değiştirebilir. Entegrasyon, değişen alanlar yerine kaydın tamamını aktarıyorsa bir sistem diğerinin güncellemesini fark etmeden silebilir. Bağlantının çalışması, verinin doğru uzlaştırıldığı anlamına gelmez. Çakışma yönetimi, hangi değişikliğin hangi gerekçeyle kabul edileceğini belirlemeyi gerektirir.
İşlemlerin tam olarak aynı anda gerçekleşmesi de şart değildir. Çevrimdışı çalışan bir uygulama, eski veriye dayanarak saatler sonra güncelleme gönderebilir. Kuyrukta bekleyen bir olay, daha yeni bir değişiklikten sonra hedefe ulaşabilir. Sorun, işlemlerin birbirinin sonucunu görmeden aynı bilgi üzerinde karar vermesidir. Bu nedenle yalnızca mesajların geliş sırasına bakmak yeterli olmaz.
Başlangıçta tekrar teslimatı ile gerçek çakışmayı ayırın. Aynı olayın yeniden gelmesi, iki kullanıcının aynı alan için farklı değerler üretmesinden farklıdır. İlki, aynı işlemin yeniden yan etki üretmesini önleyen kontrollerle yönetilir. İkincisi ise alan sahipliği, sürüm bilgisi ve gerektiğinde insan kararı gerektirir. Bu ayrım yapılmadan uygulanan genel kurallar, geçerli değişiklikleri kaybettirebilir. Tasarımın hedefi yalnızca sistemleri aynı değerde buluşturmak değil, iş açısından doğru değişiklikleri korumaktır.

Öne çıkanlar
Kayıt yerine alan bazlı sahiplik belirleyin
Müşteri kaydının tamamını CRM’ye veya ERP’ye ait saymak, farklı ekiplerin sorumluluklarını tek kurala sıkıştırabilir. Daha kullanışlı yaklaşım, her alanın yetkili kaynağını belirlemektir. Entegrasyon böylece değişikliğin yalnızca teknik olarak geçerli olup olmadığını değil, doğru kaynaktan gelip gelmediğini de değerlendirir. Aşağıdaki dağılım örnektir; gerçek sahiplik iş süreçleriyle birlikte belirlenmelidir. Alan sahipliği matrisinde alan adı, yetkili kaynak, düzenleme yetkisi, geçerli durum geçişleri ve istisnadan sorumlu kişi bulunmalıdır. Bir bilginin CRM ekranında görünmesi, CRM’nin onu kesinleştirme yetkisine sahip olduğu anlamına gelmez. Görüntüleme, değişiklik önerme ve onaylama yetkilerini ayırın. Sahipliği kaydın durumuyla da ilişkilendirin: Siparişin teslimat adresi ile düzenlenmiş faturanın adres bilgisi aynı kurallara tabi olmayabilir. Matrisi teknik ekibin tek başına hazırladığı bir belge olarak bırakmayın. İş sahipleri, ekranlarda izin verilen işlemlerle entegrasyonun kabul ettiği değişikliklerin uyumunu birlikte gözden geçirmelidir. Aksi halde kullanıcıya sunulan düzenleme yetkisi, arka planda sürekli reddedilen talepler üretebilir. İstisna kurallarının kim tarafından değiştirilebileceği de açık olmalıdır.
İletişim bilgileri
Telefon, satış temsilcisi ve görüşme notları için CRM yetkili kaynak olabilir. ERP’den gelen değişiklik önerileri CRM’de doğrulanabilir.
Finansal bilgiler
Ödeme koşulları ve muhasebe statüsü ERP sorumluluğunda tutulabilir. Diğer kaynaklardan gelen değişiklikler ilgili kontrol sürecinden geçmelidir.
Ortak düzenlenen alanlar
Adres gibi birden fazla ekibin değiştirdiği bilgilerde sahipliğin yanında başlangıç sürümü, değişiklik kapsamı ve uzlaştırma politikası tanımlanmalıdır.
Uygulama süreci
Çakışmayı yazma işleminden önce tespit edin
Gelen isteğin yeni değeri kadar, hangi kayıt durumuna dayanarak üretildiği de önemlidir. Hedef sistem bu bilgiyi denetlemeden güncelleme yaparsa başka bir değişiklik kaybolabilir. Kontrol ve yazma aynı atomik işlem içinde gerçekleşmelidir. Önce okuyup sonra koşulsuz yazmak, arada gerçekleşen güncellemeyi kaçırabilir; API ve veri katmanı bu kontrolü birlikte desteklemelidir. Entegrasyon mesajında kayıt kimliği, kaynak sistem, olay kimliği, değişen alanlar ve başlangıç sürümü taşınabilir. Kaynak ve hedef farklı sürüm sistemleri kullanıyorsa bu bilgilerin nasıl eşleştirileceği ayrıca tanımlanmalıdır. Eski sistemlerde son görülen durumun özeti yardımcı olabilir; ancak atomik koşullu yazmanın yerini bütünüyle tutmaz. Kontrol ile yazma arasındaki boşluk sürüyorsa risk de sürer. Sürüm desteği bulunmayan sistemlerde yazma yetkisini merkezileştirmek veya kontrollü bir entegrasyon adaptörü kullanmak değerlendirilebilir. Seçilen yöntem, mevcut uygulamaların aynı alanları başka yollarla değiştirip değiştirmediği dikkate alınarak tasarlanmalıdır. Entegrasyonun yaptığı kontrol, dışarıdan gerçekleşen kontrolsüz yazmaları tek başına güvenli hale getirmez.
- 01
Başlangıç sürümünü taşıyın
İstek, uygulamanın okuduğu kayıt durumunu belirtmelidir. Hedef, değişikliğin güncel mi yoksa eski bir görünüme mi dayandığını değerlendirebilmelidir.
- 02
Koşullu güncelleme uygulayın
Beklenen sürüm eşleşirse yazmayı kabul edin; eşleşmezse çakışma akışına geçin. HTTP API’lerinde ETag ve If-Match bu yaklaşımı destekleyebilir.
- 03
Güncel durumu yeniden değerlendirin
Kaydı yeniden okuyup değişen alanları karşılaştırın. Aynı isteği yalnızca yeni sürüm numarasıyla tekrarlamak, önlenmek istenen kayıp güncellemeyi yeniden oluşturabilir.
Karşılaştırma
Zaman damgası ile sürüm bilgisi aynı işi yapmaz
Olay zamanı ve gecikme analizi için yararlıdır.
Saat sapması ve gecikmiş teslimat nedeniyle tek başına karar ölçütü değildir.
Eski duruma dayanan güncellemeyi tespit eder.
Hangi değerin iş açısından doğru olduğunu kendiliğinden belirlemez.
Bağımsız değişiklikleri koruyun, bağlı alanları birlikte doğrulayın
CRM’de telefon, ERP’de ödeme koşulu değiştiğinde bu güncellemeler bağımsızsa ikisini de korumak mümkündür. Bunun için değişen alanları taşımak ve ortak başlangıç durumunu bilmek gerekir. Üç yönlü karşılaştırmada başlangıç değeri, mevcut hedef değeri ve gelen değer birlikte incelenir. Aynı alanın iki tarafta farklı değişmesi uzlaştırma gerektirirken, farklı alanlardaki değişiklikler iş kuralları doğrulandıktan sonra birleştirilebilir.
Alanların farklı olması her zaman güvenli birleşim anlamına gelmez. Ülke ve vergi numarası, para birimi ve tutar ya da adresin bileşenleri birbirine bağlı olabilir. Ayrı ayrı geçerli görünen değerler birleştiğinde tutarsız bir kayıt ortaya çıkabilir. Bu alanları birlikte doğrulanan gruplar olarak ele alın. Birleşimden sonra iş kurallarını yeniden çalıştırın; geçersiz sonucu otomatik kabul etmeyin.
Boş değerlerin anlamını da sözleşmede açıklayın. Mesajda bulunmayan alan değişiklik yapılmadığını, açıkça gönderilen boş değer ise silme talebini ifade edebilir. Bu ayrım kurulmazsa eksik veri gerçek bilgiyi silebilir. Bakiye gibi hesaplanan alanları doğrudan birleştirmek yerine ilgili hareketlerden türetin veya yetkili sistemden alın. Veri tipinin yanında iş anlamı da entegrasyon sözleşmesinin parçası olmalıdır.
Uygulama süreci
Belirsiz kayıtları sorumlusu belli bir uzlaştırma akışına alın
Her çakışmayı otomatik çözmek zorunda değilsiniz. Yüksek iş riski taşıyan veya açık kuralla karar verilemeyen değişiklikleri istisna akışına yönlendirin. Karar verecek kişi mevcut değeri, gelen öneriyi, kaynakları ve değişiklik gerekçesini birlikte görmelidir. İlgisiz kayıtlar işlemeye devam edebilmeli; bekleyen çakışmanın hangi işlemleri sınırlandırdığı açık olmalıdır. Blokajın kapsamını iş etkisine göre belirleyin. Tartışmalı ödeme koşulu yeni sipariş onayını etkileyebilirken telefon uyuşmazlığı aynı kısıtlamayı gerektirmeyebilir. Bekleyen kararlar için takip mekanizması kurun. İnsan kararı da yeni bir veri değişikliğidir: İnceleme sırasında kayıt yeniden değişmişse eski ekrandaki onay doğrudan uygulanmamalıdır. Onaylanan sonucu diğer sistemlere taşırken karar kimliğini ve kaynak çakışmayla ilişkisini koruyun. İnceleme ekranı yalnızca iki değer arasında seçim sunmamalıdır. Yetkili kişi gerektiğinde doğrulanmış yeni bir değer oluşturabilmeli ve karar gerekçesini kaydedebilmelidir. Hassas verileri genel hata kayıtlarına taşımayın; ayrıntılı inceleme bilgilerine erişimi görev ihtiyacına göre sınırlandırın. Böylece karar süreci hem anlaşılır hem de kontrollü kalır. İnceleme sorumlusu değiştiğinde bekleyen işlerin yeni sahibine devredilmesi de tanımlanmalıdır.
- 01
Çakışmayı kaydedin
Kayıt kimliği, etkilenen alanlar, sürümler ve uygulanan politika birlikte saklansın. Hassas değerleri gereksiz yere loglamayın.
- 02
İş sahibine yönlendirin
Mevcut değeri koruma, gelen değeri kabul etme veya doğrulanmış yeni değer oluşturma seçeneklerini yetkili kişiye sunun.
- 03
Kararı koşullu uygulayın
Güncel sürümü kontrol edin. Kayıt değişmişse yeniden değerlendirme isteyin; eski onayın yeni güncellemeyi ezmesine izin vermeyin.
Kontrol listesi
Tekrar, silme ve gecikme senaryolarını test edin
Normal veri akışının çalışması, çakışma politikasının doğruluğunu kanıtlamaz. Geciken, tekrarlanan ve eski sürüme dayanan güncellemeleri testlerde özellikle üretin. Başarı ölçütü yalnızca son kayıt değeri değildir. Denetim kaydı, yeniden denemenin yan etkileri ve kararın diğer sistemlere doğru taşınması da doğrulanmalıdır. Beklenen sonuçları teknik ekip ile iş sahipleri birlikte yazmalıdır. Canlı ortamda çakışma nedenlerini, otomatik kararları ve bekleyen incelemeleri izleyin. Belirli alanda sürekli uyuşmazlık, hatalı sahipliğe veya eski veriyle çalışan bir ekrana işaret edebilir. Periyodik karşılaştırmalarda bulunan farkları körlemesine eşitlemeyin; aynı uzlaştırma kurallarını uygulayın. Hangi politika sürümünün hangi kararı ürettiği izlenebilir olsun. Senkronizasyon döngülerini de izleyin. CRM’den ERP’ye taşınan değişikliğin yeni bir kullanıcı işlemi gibi geri gönderilmesi gereksiz trafik ve çakışma üretebilir. Kaynak olay ilişkisini koruyun; ancak yalnızca kaynak etiketine bakarak bütün geri dönüşleri reddetmeyin. Hedef sistemde yapılan meşru düzeltmelerin de aktarılabilmesi gerekir. Gerçek değişiklik ile yalnızca aktarım kaynaklı yazmayı ayırt etmek bu noktada önemlidir.
- ✓
Tekrar teslimat
Olay kimliğiyle tekrarları ayırın. Tekrar kontrolü ve başarılı yazma tutarlı kaydedilsin; yeniden deneme ikinci bir hareket üretmesin.
- ✓
Silme ve güncelleme yarışı
Eski güncellemenin silinen kaydı istemeden yeniden oluşturmadığını doğrulayın. Silme işaretlerinin saklanmasını yeniden oynatma ve çevrimdışı çalışma sınırlarıyla ilişkilendirin.
- ✓
Bağımsız ve bağlı alanlar
Bağımsız değişiklikler korunmalı; bağlı alanlar birleşim sonrası birlikte doğrulanmalıdır.
- ✓
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.


