Entegrasyonlarda Data Mapping Nasıl Yapılır?

Farklı sistemlerin birbiriyle iletişim kurduğu mimarilerde data mapping (veri eşleştirme), bir kaynaktan gelen veri alanlarının hedef sistemdeki karşılıklarına hatasız şekilde dönüştürülmesini sağlayan temel omurgadır. Kurumsal yazılım ekosistemlerinde ERP, CRM, e-ticaret platformları ve özel veri tabanları arasında veri akışı kurgulanırken, Entegrasyonlarda Data Mapping Nasıl Yapılır? sorusu mimari başarının merkezinde yer alır. Bu rehber; JSON, XML ve ilişkisel veri tabanı şemalarının analizinden dönüşüm kurallarının kurgulanmasına, istisna yönetiminden veri güvenliği ve KVKK/GDPR standartlarına kadar tüm data mapping süreçlerini teknik ve operasyonel detaylarıyla ele almaktadır.

Data Mapping Entegrasyonlarda Neden Kritik Bir Süreçtir?

Kurumsal entegrasyon projelerinde iki farklı yazılımın birbirine bağlanması, yalnızca API uç noktalarının (endpoints) tetiklenmesi anlamına gelmez. Gerçek operasyonel başarı, kaynak sistemden (source system) çıkan bilginin hedef sistem (target system) tarafından semantik ve yapısal olarak eksiksiz anlaşılabilmesine bağlıdır. Data mapping, Extract-Transform-Load (ETL) ve Extract-Load-Transform (ELT) süreçlerinin "Transform" (Dönüşüm) evresini oluşturur. Bu aşamada yapılan tek bir alan eşleştirme hatası, binlerce siparişin muhasebe sistemine yanlış aktarılmasına, stok miktarlarının sıfırlanmasına veya müşteri verilerinin bozulmasına yol açabilir.

Veri bütünlüğü (data integrity), kurumsal operasyonların sürdürülebilirliği açısından taviz verilemez bir metriktir. Bir e-ticaret platformu müşterinin fatura adresini tek bir metin bloğu (address_line: "Atatürk Mah. No:4 Kadıköy/İstanbul") olarak tutarken, hedef ERP sistemi bu bilgiyi ilçe, il, sokak ve kapı numarası şeklinde ayrıştırılmış alanlar halinde talep edebilir. Data mapping kuralları doğru kurgulanmadığında middleware (ara katman yazılımı) bu veriyi ya reddeder ya da hedef sistemde veri kirliliği (data pollution) yaratır.

Bunun yanı sıra, modern mikroservis mimarilerinde ve event-driven (olay güdümlü) sistemlerde asenkron çalışan kuyruklar (RabbitMQ, Apache Kafka vb.) sürekli payload taşır. Bu payload'ların her bir tüketici (consumer) servis tarafından standart formatta işlenebilmesi, esnek ve dokümante edilmiş veri eşleştirme şablonlarına dayanır. Doğru kurgulanan bir data mapping mimarisi, teknik borcu (technical debt) azaltır ve sistemlerden biri güncellendiğinde tüm entegrasyonun çökmesini engeller.

Veri Formatlarının Analizi: JSON, XML ve Veri Tabanı Şemaları

Sistem entegrasyonlarında en sık karşılaşılan senaryo, modern RESTful mimariler ile eski (legacy) kurumsal sistemlerin veya dosya tabanlı veri aktarımlarının bir arada çalışmasıdır. REST API'ler genellikle JSON (JavaScript Object Notation) formatını kullanırken, bankacılık, sigortacılık veya kamu entegrasyonlarında SOAP protokolü ve XML (Extensible Markup Language) etiketleri ağırlıktadır. Veri ambarı ve doğrudan veri tabanı replikasyonlarında ise SQL/NoSQL ilişkisel şemalar ve CSV dosyaları devreye girer. Başarılı bir data mapping, bu formatların anatomisini anlamakla başlar.

Hedef ve Kaynak Sistemlerde Yapısal Farklılıklar

JSON, hafif ve okunabilir yapısıyla nesneleri (@@CODE0@@) ve dizileri (@@CODE1@@) iç içe (nested) hiyerarşiler halinde taşır. XML ise hiyerarşiyi açılış-kapanış etiketleri ve nitelikler (attributes) üzerinden kurgular. Bir JSON nesnesinin doğrudan XML'e dönüştürülmesi sırasında niteliklerin (@@CODE2@@) mi yoksa alt elemanların (@@CODE3@@) mı kullanılacağı netleştirilmelidir.

Aşağıdaki tablo, sık kullanılan veri formatlarının entegrasyon süreçlerindeki temel teknik özelliklerini özetlemektedir:

Düz (flat) veri yapıları ile hiyerarşik yapılar arasındaki dönüşümler özel dikkat gerektirir. Örneğin bir CSV satırında yer alan tekrarlı verilerin (örneğin aynı sipariş ID'sine sahip farklı ürün satırları), hedef sistemde tek bir sipariş nesnesi altında toplanmış order_items dizisine (array) dönüştürülmesi (grouping/aggregation) gerekir.

Veri Tipleri (Data Types) ve Kısıtlamaların Anlaşılması

Veri tipi uyuşmazlıkları, entegrasyon boru hatlarında çalışma zamanı (runtime) çökmelerinin en yaygın nedenidir. Kaynak sistemde metin (string) olarak tanımlanmış bir alan, hedef sistemde tamsayı (integer), kayan noktalı sayı (float) veya boole (boolean) tipi bekleyebilir.

• Tarih ve Saat Formatları: Kaynak sistem tarih bilgisini Unix Epoch zaman damgası (@@CODE0@@) olarak sağlarken, hedef sistem ISO 8601 (@@CODE1@@) veya yerel saat dilimi formatı (DD/MM/YYYY HH:mm:ss) isteyebilir. Saat dilimi (UTC offset) dönüşümleri mutlaka kural setine eklenmelidir.

• Karakter Setleri ve Kodlama: UTF-8, ISO-8859-9 veya ASCII kodlama farkları, özel karakterlerin (ö, ç, ş, ğ, İ vb.) bozulmasına ("Mojibake" fenomeni) neden olur. Payload transferinde HTTP başlıklarında Content-Type: application/json; charset=utf-8 tanımı zorunlu tutulmalıdır.

• Sayısal Kısıtlamalar: Para birimi ve ondalık basamaklarda nokta (@@CODE0@@) veya virgül (@@CODE1@@) ayrımı ile kayan nokta hassasiyetleri (örneğin 2 hane yerine 4 hane kuruş tutulması) finansal tablolarda yuvarlama hatalarına (rounding errors) yol açabilir.

Adım Adım Data Mapping Süreci (Uygulama Metodolojisi)

Kurumsal ölçekte bir data mapping projesini yürütmek, gelişigüzel kod yazmanın ötesinde metodolojik bir mühendislik disiplini gerektirir. Süreç, analizden başlayıp test aşamasına kadar birbirini takip eden dört kritik fazdan oluşur.

1. Kaynak ve Hedef Veri Sözlüklerinin (Data Dictionary) Oluşturulması

Eşleştirme işlemine başlamadan önce her iki sistemin veri sözlüğü (Data Dictionary) veya teknik spesifikasyonu çıkarılmalıdır. Kaynak sistemin OpenAPI/Swagger dokümantasyonu, JSON Schema dosyaları veya XML XSD şemaları incelenir. Hangi alanların zorunlu (mandatory/required), hangilerinin isteğe bağlı (optional) olduğu, alanların maksimum karakter uzunlukları ve alabileceği enum değerler dokümante edilir.

2. Eşleştirme Kurallarının ve Dönüşüm (Transformation) Mantığının Yazılması

Alanlar arasındaki ilişki nadiren birebir (1:1 direct mapping) şeklindedir. Çoğu zaman dönüşüm mantığı (transformation logic) işletilmelidir:

• Birebir Eşleştirme (Direct Mapping): @@CODE0@@ $\rightarrow$ @@CODE1@@

• Birleştirme (Concatenation): @@CODE0@@ + @@CODE1@@ + @@CODE2@@ $\rightarrow$ @@CODE3@@

• Ayrıştırma (Splitting): @@CODE0@@ $\rightarrow$ @@CODE1@@ ve target.surname

• Değer Eşleme (Lookup/Enum Mapping): Kaynak sistemdeki durum kodu @@CODE0@@ ise hedef sistemde @@CODE1@@, @@CODE2@@ ise @@CODE3@@ değerine dönüştürülür.

• Koşullu Mantık (Conditional Logic): Eğer @@CODE0@@ ise hedef sistemde @@CODE1@@ zorunlu kılınır, aksi halde target.identity_number atanır.

3. Null Değerler ve Beklenmeyen Veriler İçin İstisna Yönetimi

Veri akışında eksik veya tanımsız veriler (null, undefined, empty string) entegrasyon motorunun durmasına yol açmamalıdır. Eşleştirme kuralları yazılırken varsayılan değerler (fallback/default values) tanımlanmalıdır. Örneğin kaynak sistemde @@CODE0@@ boş geliyorsa varsayılan olarak @@CODE1@@ atanması veya hedef sistem null kabul etmiyorsa boş metin ("") geçilmesi gibi kurallar istisna yönetimi (exception handling) kapsamında kurgulanır.

4. Dummy Verilerle Test ve Validasyon Aşaması

Canlıya (Production) geçmeden önce, tüm olası senaryoları içeren sentetik (dummy) veri setleri üretilir. Sınır değer testleri (boundary testing) uygulanır: Maksimum karakter uzunluğundaki metinler, özel karakterler, negatif sayılar ve eksik alanlar içeren payload'lar eşleştirme motoruna gönderilerek hedef sistem şemasına uygunluğu (Schema Validation) doğrulanır.

Data Mapping Sırasında Dikkat Edilmesi Gereken Riskler

Veri eşleştirme süreçleri yalnızca fonksiyonel bir veri taşıma operasyonu değildir; beraberinde operasyonel, finansal ve yasal riskler barındırır. Hatalı tasarlanmış bir dönüşüm katmanı, fark edilmesi aylar süren sessiz veri bozulmalarına (silent data corruption) yol açabilir.

Veri Kaybı (Data Loss) ve Şema Uyumsuzlukları

Hedef sistemin alan kısıtlamaları kaynak sistemden daha dar olduğunda veri kaybı riski oluşur (Truncation). Örneğin kaynak sistemde 500 karakterlik bir açıklama alanı, hedef sistemde VARCHAR(100) olarak tanımlanmış bir alana eşlendiğinde, middleware fazla metni sessizce kırpabilir (truncate) veya doğrudan hata vererek kaydı reddedebilir.

Benzer şekilde, dizi yapılarındaki ilişkisel uyumsuzluklar da veri kaybına neden olur. Kaynak sistem bir müşteriye ait birden fazla telefon numarasını liste olarak tutarken, hedef sistem yalnızca tek bir phone alanı kabul ediyorsa, hangi numaranın (birincil, son eklenen vb.) seçileceği açıkça tanımlanmalıdır. Aksi halde ikincil iletişim verileri kalıcı olarak kaybolur.

Güvenlik, Veri Maskeleme ve KVKK/GDPR Uyumluluğu

Kişisel Verilerin Korunması Kanunu (KVKK) ve Genel Veri Koruma Yönetmeliği (GDPR) uyarınca, sistemler arasında taşınan Kişisel Olarak Tanımlanabilir Bilgiler (PII - Personally Identifiable Information) regülasyona tabidir. Data mapping katmanı, verinin güvenli işlenmesinde bir filtre görevi görmelidir:

• Veri Minimizasyonu: Hedef sistemin işlevini yerine getirmesi için ihtiyaç duymadığı hassas alanlar (örneğin T.C. Kimlik No, kredi kartı CVV kodu, doğum tarihi) mapping kuralında doğrudan elenmeli (drop), hedef sisteme aktarılmamalıdır.

• Veri Maskeleme ve Hashing: Loglama mekanizmalarında veya analitik sistemlere veri aktarılırken e-posta adresleri (u***@domain.com) maskelenmeli, hassas kimlik bilgileri SHA-256 gibi algoritmalarla hash'lenmelidir.

• Şifreleme (Encryption in Transit): Mapping motorları veriyi bellekte (in-memory) işlerken ve API uç noktaları arasında taşırken TLS 1.3 standardı ve güçlü şifreleme protokolleri kullanılmalıdır.

Manuel ve Otomatize Data Mapping: Hangisi Tercih Edilmeli?

Entegrasyon mimarisi kurgulanırken karar vericilerin önündeki en temel yol ayrımı, mapping kurallarının yazılım geliştiriciler tarafından özel kodlarla (custom script/code) mı yazılacağı, yoksa iPaaS (Integration Platform as a Service) ve no-code/low-code otomasyon platformları (n8n, Make, Zapier, MuleSoft vb.) üzerinden görsel araçlarla mı yönetileceğidir.

Özel yazılım geliştirmede (Node.js, Python, Java vb. ile yazılan mikrosistemler), geliştirici tam kontrole sahiptir. Karmaşık algoritmik dönüşümler, bellek optimizasyonları ve özel kriptografik işlemler kolayca uygulanabilir. Ancak bu yaklaşım; yüksek başlangıç geliştirme maliyeti, şema değişikliklerinde sürekli kod revizyonu ihtiyacı ve bağımlılık riski doğurur.

Buna karşılık otomatize mapping araçları ve iPaaS çözümleri, sürükle-bırak (drag-and-drop) arayüzleri, hazır transformatör fonksiyonları (JSON parser, array aggregator, regex replacer) ve görsel hata takip panelleri sunar. Bu araçlar pazara çıkış süresini (time-to-market) hızlandırır ve teknik olmayan operasyon ekiplerinin de şema güncellemelerini yönetebilmesini sağlar.

Aşağıdaki karşılaştırma tablosu iki yaklaşımın stratejik dinamiklerini özetlemektedir:

Başarılı Bir Veri Entegrasyonu İçin En İyi Uygulamalar (Best Practices)

Kurumsal entegrasyonların uzun vadede sorunsuz çalışabilmesi, veri eşleştirme katmanının değişime ve hatalara karşı dirençli (resilient) tasarlanmasına bağlıdır. Sistemler zaman içinde güncellenir, yeni veri alanları eklenir veya mevcut API yanıt yapıları değişir. Bu dinamik ortama uyum sağlamak için sektörel standartlara dayalı pratikler uygulanmalıdır.

İlk olarak, Şema Sürümleme (Schema Versioning) prensibi benimsenmelidir. API uç noktalarında @@CODE0@@ yerine @@CODE1@@ yapısına geçildiğinde, mapping kuralları da sürüm kontrol sistemine (Git vb.) dahil edilmelidir. Eski ve yeni şema sürümleri belirli bir süre paralel çalıştırılarak sistemler arası geriye dönük uyumluluk (backward compatibility) korunmalıdır.

İkinci olarak, Dead Letter Queue (DLQ - İşlenemeyen Mesaj Kuyruğu) mimarisi kurulmalıdır. Mapping aşamasında şema hatası, geçersiz veri tipi veya eksik zorunlu alan nedeniyle işlenemeyen payload'lar ana akışı tıkamamalıdır. Bu tür hatalı kayıtlar otomatik olarak bir DLQ havuzuna yönlendirilmeli, loglanmalı ve operasyon ekiplerine bildirim (alert) gönderilmelidir. Veri düzeltildikten sonra ilgili kayıtlar kuyruktan tekrar tetiklenebilmelidir (replay capability).

Son olarak, İdempotans (Idempotency) kuralı işletilmelidir. Ağ kesintileri veya zaman aşımı (timeout) durumlarında aynı veri paketi middleware tarafından tekrar gönderilebilir. Data mapping katmanı, benzersiz bir işlem anahtarı (Idempotency Key / Transaction ID) üreterek hedef sistemde mükerrer (duplicate) kayıt oluşmasını engellemelidir.