API entegrasyonuna başlamadan veri sahipliğini belirlemek

Örnek bir iş senaryosu

CRM'de güncellenen telefonun muhasebe sisteminden gelen eski telefonla her gece üzerine yazıldığını düşünün. Teknik bağlantı çalışıyor olsa da veri kalitesi düşmektedir. Telefon için hangi tarafın kaynak olacağı veya son değişikliğin hangi kuralla kabul edileceği yazılmalıdır. Çakışmalar sessizce çözülmek yerine gerekirse inceleme kuyruğuna düşmelidir.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Entegrasyon kapsamını bir matrisle netleştirin: veri grubu, kaynak, hedef, yön, sıklık, kimlik ve hata sorumlusu. Bu tablo teknik ekip kadar iş biriminin de okuyabileceği dilde olmalıdır. İki yönlü bağlantı gereken her alan için çakışma kuralı ayrıca yazılır. Silme işleminin anlamı özellikle önemlidir; bir sistemde pasifleşen kaydın diğer sistemde kalıcı olarak silinmesi beklenmeyebilir. İlk senkronizasyonda geçmiş verinin ne kadarının alınacağı belirlenmelidir. Bütün geçmişi taşımak gerekli olmayabilir, ancak dar tarih aralığı seçildiğinde devam eden eski işlemler dışarıda kalabilir. Kapsam seçimini gerçek açık kayıtlarla doğrulayın.

Bağlantıyı zor koşullarda doğrulama

Entegrasyon denemesine başarılı tek bir kayıtla başlayın, ardından kontrollü olarak hata koşulları ekleyin. Eksik zorunlu alan, bilinmeyen ürün kimliği, aynı olayın tekrarı ve geçici bağlantı kesintisi iyi örneklerdir. Her senaryoda beklenen sonucu önceden yazın. Hangi kayıt tekrar denenecek, hangisi insan incelemesine düşecek ve hangisi reddedilecek açık olmalıdır. İşlem günlüğünde kaynak kimlik ile hedef kayıt arasında bağlantı bulunmalıdır. Böylece sorun araştırılırken farklı sistemlerde aynı işin peşinden gidilebilir. Test anahtarları ve üretim anahtarları birbirinden ayrı tutulmalıdır.

Yeniden deneme politikasını dış servisin kurallarıyla uyumlu tasarlayın. Her hatayı aynı hızla tekrar göndermek kota sınırına takılabilir ve diğer işlerin de gecikmesine neden olabilir. Geçici bağlantı hatasıyla kalıcı veri hatası farklı davranış gerektirir. Kuyruğun en eski kaydı ve toplam bekleyen iş sayısı birlikte izlenmelidir. Az sayıda çok eski kayıt sessiz bir soruna işaret edebilir. Başarılı kaydın tekrar işlenmemesi kadar yarım kalan işlemin güvenli devamı da önemlidir. Bu nedenle işlem durumları yalnızca başarılı ve başarısız ikilisinden daha ayrıntılı olabilir.

İş birimi için okunabilir bir hata ekranı hazırlayın. Teknik hata kodunun yanında etkilenen kayıt, yapılabilecek işlem ve sorumlu ekip yer alsın. API sırları, parolalar ve gereksiz kişisel bilgiler günlüklerde bulunmamalıdır. Saklanan teknik kayıtların erişimi ve süresi belirlenmelidir. Canlıya geçmeden önce bağlantı kesildiğinde işin nasıl sürdürüleceğini de konuşun. Manuel işlem gerekiyorsa daha sonra senkronizasyon sırasında mükerrer oluşmaması için bu kayıtların işaretlenmesi gerekir. Başarı ölçütü yalnızca isteklerin yanıt alması değil, hedef işin doğru ve bir kez tamamlanmasıdır.

Ekibinize sorabileceğiniz sorular

• Her alanın esas kaynağı belli mi?
• Çakışan güncelleme nasıl ele alınıyor?
• Başarısız kayıt yeniden işlenebiliyor mu?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.