API, Entegrasyon ve Kurumsal Sistemler
Kurumsal Entegrasyonlarda Veri Dönüşümü Nasıl Tasarlanır?
CRM ve ERP arasında veri taşımak, alan adlarını değiştirmekten fazlasını gerektirir. Eşleştirme, kanonik model, doğrulama ve test kararlarını bir sipariş akışı üzerinden ele alıyoruz.
Veri dönüşümü, anlamı koruyarak model değiştirmektir
CRM’deki bir siparişi ERP’ye aktarmak, yalnızca alan adlarını değiştirmek gibi görünebilir. Ancak CRM’de müşteri olarak tutulan kayıt, ERP’de birden fazla cari hesapla ilişkilendirilebilir. Bir sistemde sipariş tutarı vergi dâhil, diğerinde vergi hariç olabilir. Alanlar teknik olarak eşleşse bile iş anlamı korunmadığında entegrasyon yanlış sonuç üretir. Bu nedenle tasarım, mesaj biçiminden önce verinin ne anlama geldiğine odaklanmalıdır.
Başlangıç noktası veri sözleşmesidir. Kaynak alanın neyi temsil ettiği, hedefin ne beklediği, hangi bilginin dönüştürülebileceği ve hangi durumun hata sayılacağı açıkça tanımlanmalıdır. Amaç yalnızca hedef API’nin kabul ettiği mesajı üretmek değil, hedef sistemde doğru iş kaydının oluşmasını sağlamaktır. Teknik ekip ile ilgili iş birimi, bu sözleşmeyi gerçek kayıt örnekleri üzerinden birlikte değerlendirmelidir.
Örnek olarak CRM’de onaylanan bir satış siparişini ele alalım. CRM müşteri referansı, yerel tarih gösterimi ve kilogram cinsinden miktar gönderiyor; ERP ise cari kodu, saat dilimi belirtilmiş tarih ve gram cinsinden miktar bekliyor. Tasarım boyunca bu alanların anlamını, dönüşüm kurallarını ve hata durumlarını birlikte izleyeceğiz. Aynı yaklaşım, diğer kurumsal veri akışlarına da uyarlanabilir.
Öne çıkanlar
Kaynak ve hedef arasındaki eşleştirmeyi belgeleyin
Eşleştirme belgesi yalnızca kaynak ve hedef alanlarını sıralamamalıdır. Veri tipi, zorunluluk, dönüşüm kuralı, referans veri kaynağı ve hata davranışı da belgede bulunmalıdır. Örnek kayıtlar üzerinde çalışmak, API dokümanında görünmeyen boş değerleri ve eski kodları ortaya çıkarabilir. Belge, uygulama sırasında verilen kararları da yansıtacak şekilde güncel tutulmalıdır. Alan sahipliğini de belirleyin. Müşteri unvanının yetkili kaynağı ERP ise CRM’den gelen farklı bir unvan mevcut bilgiyi otomatik olarak değiştirmemelidir. Oluşturma ve güncelleme işlemleri ayrı kurallar gerektirebilir. Kaynakta bulunmayan alan, boş metin ve açıkça gönderilen null aynı anlama gelmeyebilir; bunların hedefte ne yapacağı sözleşmede açıklanmalıdır. Referans eşleştirmelerinde kod çiftinin yanında geçerlilik durumunu da değerlendirin. Kapatılmış bir cari hesap teknik olarak bulunabilir, ancak yeni sipariş için kullanılamayabilir. Eşleştirme kayıtlarını kimin güncelleyeceği ve değişikliklerin bekleyen mesajlara nasıl uygulanacağı da belirlenmelidir. Böylece destek ekibi hatalı kayıtları rastgele kodlarla düzeltmek zorunda kalmaz.
Kimlik ve referanslar
CRM müşteri referansını ERP cari koduna bağlayın. Eşleşme bulunmadığında yeni cari oluşturulması ayrı bir iş kararı olmalıdır.
Kodlar ve durumlar
Onaylandı durumunun hedefteki karşılığını belirleyin. Tanınmayan kodları sessizce varsayılan duruma çevirmeyin.
Varsayılan değerler
Varsayılanları yalnızca iş anlamı biliniyorsa kullanın. Eksik para birimini tahmin etmek yerine kaydı incelemeye ayırın.
Karşılaştırma
Doğrudan eşleştirme mi, kanonik model mi?
Doğrudan eşleştirme: Az sayıda sistem ve basit kurallar için daha az modelleme yükü getirir.
Kanonik model: Paylaşılan kavramları ortaklaştırır; ayrıca model yönetimi gerektirir.
Doğrudan eşleştirme: Benzer kurallar farklı bağlantılarda tekrarlanabilir.
Kanonik model: Hedef ayrıntıları adaptörde tutulabilir; ortak modelin sürümü ayrıca yönetilir.
Uygulama süreci
Sipariş akışında dönüşüm sırasını belirleyin
Dönüşümü tek bir büyük fonksiyon yerine açık adımlara ayırın. Bu ayrım, hatanın yerini bulmayı ve kuralları bağımsız test etmeyi kolaylaştırır. Hedefe gönderim de dönüşümden ayrı bir sorumluluk olmalıdır. Böylece mesajın yanlış üretilmesiyle doğru mesajın hedefe ulaştırılamaması birbirinden ayrılabilir. Her aşamanın girdisi, çıktısı ve hata davranışı tanımlanmalıdır. Sipariş örneğinde kilogramı grama çevirirken yalnızca sayı değil, birim bilgisi de güncellenir. Ondalık hassasiyet ve yuvarlama kuralı ürünün niteliğine göre belirlenmelidir. Yerel tarihe saat dilimi eklemek için kaynağın hangi saat dilimini kullandığı bilinmelidir. Eksik bilgi tahminle tamamlanmamalıdır. Yaz saati uygulaması nedeniyle belirsiz olabilecek yerel zamanlar için de açık davranış gerekir. Para tutarlarında gösterim dönüşümü ile kur dönüşümünü ayırın. Ondalık ayıracını düzenlemek teknik normalizasyondur; para birimini değiştirmek ise kur kaynağı, geçerlilik tarihi ve yuvarlama kararı gerektirir. Vergi dâhil tutardan vergi hariç tutara geçiş de finans ekibinin onayladığı kurallarla uygulanmalıdır. Dönüşüm katmanı bu kararları kendiliğinden üretmemelidir.
- 01
Girdiyi kontrol edin
Mesajın okunabilirliğini, şemasını ve gerekli alanların beklenen tipte olduğunu doğrulayın.
- 02
Normalize edin ve referansları çözün
Tarih ve sayı gösterimini düzenleyin; müşteri ve ürün referanslarını geçerli hedef kodlarına bağlayın.
- 03
Hedef mesajı doğrulayın
Birim dönüşümünü uygulayın, hedef alanları oluşturun ve çıktıyı ERP sözleşmesine göre kontrol edin.
Kontrol listesi
Doğrulamayı, hata takibini ve testleri birlikte tasarlayın
Şema doğrulaması, verinin iş açısından geçerli olduğunu tek başına göstermez. Miktar sayısal olabilir ancak ürün için uygun olmayan birimle gönderilebilir. Girişte biçim, dönüşüm sırasında anlam, çıkışta hedef sözleşmesi kontrol edilmelidir. Hata kaydı ilgili alanı ve ihlal edilen kuralı göstermeli; erişim anahtarları veya gereksiz kişisel bilgiler içermemelidir. Her eşleştirme kuralını bir test senaryosuna bağlayın. Sorunsuz örneklerin yanında boş alanları, bilinmeyen kodları, sınır değerleri ve eski kayıtları da sınayın. Üretim örnekleri kullanılacaksa hassas bilgileri ayıklayın. Dönüşüm testlerini sabit referans verileriyle çalıştırın; bağlantı ve hedef davranışını ise entegrasyon testlerinde ayrıca değerlendirin. Böylece başarısızlığın hangi sorumluluk alanından kaynaklandığı daha kolay anlaşılır. Yanlış mesajın reddedilmesini de doğru mesajın üretilmesi kadar önemseyin. Beklenen hata kodunu, ilgili alanı ve kaydın yönlendirileceği süreci doğrulayın. Uygun test ortamında hedefin kabul ettiği mesajın beklenen iş kaydını oluşturduğunu kontrol edin. Yalnızca başarılı bir API yanıtı almak, siparişin bütün alanlarının doğru işlendiğini kanıtlamaz. Operasyon ekibi, hatanın hangi aşamada oluştuğunu ve yeniden işleme için neyin düzeltilmesi gerektiğini görebilmelidir.
- ✓
Veri hatasını ayırın
Eksik cari eşleşmesini incelemeye yönlendirin; değişmeyen mesajı tekrar göndermek sorunu çözmez.
- ✓
Geçici arızayı yönetin
Erişim sorunlarında kontrollü yeniden deneme uygulayın ve mükerrer sipariş oluşmasını önleyecek davranışı test edin.
- ✓
İşlem izini koruyun
Kaynak kimliği, korelasyon kimliği, dönüşüm sürümü ve hata kodunu ilişkilendirin.
- ✓
Uygulama süreci
Değişiklikleri sürümleyin ve etkisini inceleyin
Alan adı değişmeden anlam değişebilir. Bir tutarın artık vergi dâhil gönderilmesi, şema aynı kalsa da dönüşümü bozabilir. Bu nedenle eşleştirme belgesi, kod, referans tabloları ve testler birlikte yönetilmelidir. Geçmiş mesaj yeniden işlendiğinde eski mi, güncel mi kuralın kullanılacağı açıkça kararlaştırılmalıdır. Bekleyen mesajların hangi sürümle işleneceği de bu kararın parçasıdır. Yeni sürümden önce örnek kayıtların eski ve yeni çıktılarını karşılaştırın; beklenen farkları iş birimiyle doğrulayın. Geri dönüş planı yalnızca yazılımı kapsamamalıdır. Yeni kuralla oluşturulmuş ERP siparişi, eski kod yeniden yüklendiğinde kendiliğinden düzelmez. Referans tabloları ve işlenmiş kayıtlar için yapılacak işlemleri de belirleyin. Gerekli veri düzeltmeleri yetkili ekiplerin onayıyla yürütülmelidir. Sistemler farklı zamanlarda güncelleniyorsa geçiş dönemini planlayın. Eski mesajlar kabul edilecekse desteklenen sürümleri ve kaldırılma koşullarını belgeleyin. Yeni alanın bulunmadığı mesajlarda uygulanacak davranışı açıkça tanımlayın. Dönüşüm sürümünü işlem kaydıyla ilişkilendirmek, geçmişte belirli bir çıktının neden üretildiğini sonradan açıklamayı kolaylaştırır.
- 01
Etki alanını çıkarın
Değişikliğin kaynakları, hedefleri, bekleyen kayıtları ve yeniden işleme süreçlerini nasıl etkilediğini belirleyin.
- 02
Sözleşmeyi güncelleyin
Örnek mesajları ve testleri yenileyin; geçiş döneminde desteklenecek sürümleri belgeleyin.
- 03
Kontrollü devreye alın
Hata kategorilerini izleyin ve sorun durumunda uygulanacak geri dönüş adımlarını önceden hazırlayın.
Uygulanabilir tasarım, sahipliği belli kurallarla başlar
İyi bir veri dönüşümü tasarımının çıktısı yalnızca çalışan kod değildir. Anlamı açıklanmış alanlar, sahipliği belirlenmiş kurallar, uygun dönüşüm katmanı, test verileri ve izlenebilir hata akışı birlikte ortaya çıkmalıdır. Küçük bir entegrasyonda doğrudan eşleştirme yeterli olabilir; ortak kavramlar arttığında modelleme yaklaşımı yeniden değerlendirilebilir.
İlk adım, temsilî bir akış seçip kaynak ve hedef sözleşmesini çıkarmaktır. Birim, tarih, kimlik ve boş değer kuralları bu akışta netleştiğinde diğer akışlar daha tutarlı tasarlanabilir. Her sistemi aynı şablona zorlamak yerine ortak kuralları ve sisteme özgü istisnaları ayırın. Ekibin hatalı kaydı nasıl düzelteceğini bilmesi de tasarımın uygulanabilirliğinin parçasıdır.
Bikare’nin API ve sistem entegrasyonları hizmeti bu ihtiyaçlar için değerlendirilebilir. Özel adaptörler gerektiğinde özel yazılım geliştirme de kapsamda ele alınabilir. Keşif görüşmesine sistem listesini, örnek mesajları ve bilinen eşleştirme sorunlarını getirmek, görüşmenin yalnızca bağlantı teknolojisine değil, korunması gereken veri anlamına da odaklanmasına yardımcı olur.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
