Veri Sözleşmesi: Şema Değişince Raporların Sessizce Bozulmasını Önlemek

Yapısal uyumla anlam uyumunu ayırın

Bir sipariş olayı hâlâ aynı sayısal alanı taşıyor olabilir. Ancak alan artık vergi hariç yerine vergi dahil tutarı ifade ediyorsa eski tüketici yanlış hesap yapabilir. Şema kontrolü bu anlam değişikliğini her zaman yakalayamaz. Alan açıklaması, birim, kaynak ve hesaplama kuralı sözleşmede birlikte bulunmalıdır.

Confluent dokümantasyonu geriye, ileriye ve her iki yöne uyumluluğu ayrı açıklar; geçişli kontrollerin yalnızca son sürüm yerine önceki sürümleri de kapsayabildiğini belirtir. [1] Bu seçenekleri bütün veri biçimlerinde aynı sonuç veren genel düğmeler gibi yorumlamayın. Kullanılan şema türünün kuralları ayrıca incelenmelidir.

Üreten ve tüketen tarafları birlikte kaydedin

Bir tablo veya olay akışı birkaç rapor, dış entegrasyon ve otomasyon tarafından kullanılabilir. Değişiklik yapılırken yalnızca üretici uygulamanın testi geçerse bütün sistemin uyumlu olduğu sonucuna varılamaz. Tüketici envanteri, sorumlu kişi ve hangi alanların kullanıldığı görünür olsun.

Varsayımsal teslimat olayında “tamamlandı” değeri daha önce bütün paketleri, yeni sürümde yalnızca bir paketi anlatmaya başlasın. Veri türü değişmemiştir, fakat yönetici raporu siparişleri erken tamamlandı sayabilir. Bu nedenle iş senaryolarını temsil eden örnek olaylar sözleşme testlerine eklenmelidir.

Değişiklik talebini etki analiziyle başlatın

Yeni alan ekleme, alanı kaldırma, zorunlu hale getirme ve anlam değiştirme farklı riskler taşır. İsteğe bağlı alan eklemek bazı tüketiciler için sorunsuz olabilir; bilinmeyen alanları reddeden istemcilerde yine sorun oluşabilir. Gerçek tüketici davranışını test edin, sadece teorik uyuma güvenmeyin.

Değişiklik için duyuru, geçiş dönemi ve geri dönüş yolu belirleyin. Eski ve yeni veri birlikte bulunacaksa hangi sürümün nasıl anlaşılacağı açık olsun. Geçmiş veriyi yeniden işleme ihtiyacı varsa arşivdeki eski şemaların okunabildiği de doğrulansın. Veri sözleşmesi yalnızca bugünkü mesajı korumamalıdır.

Örnek sözleşme kontrol tablosu

Bu tablo örnek kabul aracıdır. Şema geçişini yalnızca geliştirme ortamındaki birkaç kayıtla sınamayın. Eski sürüm, boş değer, yeni durum ve geçmiş kayıtları içeren kontrollü bir test kümesi hazırlayın. Gerçek müşteri bilgilerini gereksiz biçimde test verisine taşımayın.

Sapma olduğunda veriyi sessizce dönüştürmeyin

Beklenmeyen alan veya değer geldiğinde sistemin ne yapacağı tanımlı olmalıdır. Kritik veriyi yanlış varsayımla kabul etmek yerine karantina veya inceleme kuyruğu gerekebilir. Ancak her küçük ek alan için bütün akışı durdurmak da gereksiz kesinti yaratabilir. Politika, verinin iş etkisine göre belirlenmelidir.

Raporlarda veri tazeliği ve reddedilen kayıtlar görünür olsun. Kaynak akışı durmuşken son başarılı raporu güncel gibi sunmayın. Bir sorun düzeltildiğinde eksik dönemin nasıl yeniden işlendiği ve mükerrer kayıt oluşmadığı kontrol edilsin. Sözleşmenin sahibi değişiklikten sonra da sorumluluğunu sürdürmelidir.

Sık sorulan sorular

Şema doğrulaması veri doğruluğunu garanti eder mi?

Hayır. Biçimi doğru olan değer yanlış anlam veya yanlış kaynaktan gelebilir. İş kuralları ve örnek senaryolar ayrıca doğrulanmalıdır.

Her değişiklik için yeni veri akışı açılmalı mı?

Gerekmez. Uyumluluk ve geçiş ihtiyacına göre karar verilir. Önemli olan eski tüketicilerin nasıl etkilendiğinin kanıtla gösterilmesidir.