E-Ticaret XML Entegrasyonu Nedir?

E-ticaret XML entegrasyonu, tedarikçinin ürün, varyant, stok, fiyat, kategori, açıklama ve görsel verisini XML biçiminden alıp işletmenin kendi ürün ana verisine kontrollü kurallarla dönüştüren veri hattıdır. XML yalnızca etiketli bir veri gösterim biçimidir; indirme, güvenli ayrıştırma, alan eşleştirme, doğrulama, zamanlama, hata yönetimi ve yayınlama ise entegrasyon yazılımının işidir. Bu nedenle bir XML bağlantısını panele eklemek, tek başına güvenilir entegrasyon kurulduğu anlamına gelmez.

Tedarikçi katalogları sık değiştiğinde manuel ürün girişi sürdürülemez hâle gelebilir. Ancak otomasyon, hatayı da hızlandırabilir: yanlış KDV yorumu binlerce üründe hatalı fiyat; belirsiz stok alanı fazla satış; değişen SKU mükerrer kayıt; kontrolsüz görsel URL’si güvenlik ve hak ihlali doğurabilir. Sağlam yaklaşım; örnek feed, veri sözlüğü, yazılı veri sözleşmesi, güvenlik kapısı, staging, guardrail, mutabakat ve geri alma planını birlikte kurar.

E-Ticaret XML Entegrasyonu Nedir?

Uçtan uca akış; kaynağa bağlanma, dosyayı indirme, XML sözdizimini güvenli biçimde ayrıştırma, şema ve iş kurallarını doğrulama, alanları işletmenin modeline eşleme, sonuçları staging alanında karşılaştırma, onaylanan değişiklikleri yayınlama ve canlı veriyi yeniden okuyarak mutabakat yapma adımlarından oluşur. Her adım ayrı başarı ve hata durumu üretmelidir. HTTP 200 yalnız indirme isteğinin yanıt aldığını gösterir; ürünlerin işlendiğini veya doğru yayımlandığını kanıtlamaz.

Katman	Sorumluluk	Başarı kanıtı	Başlıca risk
XML belge	Etiketli veriyi taşır	Well-formed belge	Bozuk sözdizimi veya encoding
Erişim katmanı	HTTPS, SFTP ya da API’den alır	Doğrulanmış kaynak ve checksum	SSRF, yönlendirme, token sızıntısı
Dönüşüm katmanı	Alanları normalize eder	Mapping sürümü ve test sonucu	Yanlış birim, kimlik veya kategori
İş kuralı katmanı	Stok ve fiyat guardrail’i uygular	Kabul/red gerekçesi	Olağan dışı değeri yayına alma
Yayın katmanı	Staging verisini canlıya taşır	Read-back ve mutabakat	Kısmi yayın veya mükerrer ürün

XML Nedir ve E-Ticarette Hangi Amaçlarla Kullanılır?

W3C’nin XML 1.0 belirtimi, XML belgelerinin sözdizimini ve işlemci davranışını tanımlar. Elementler hiyerarşi kurar, attribute değerleri bir öğeye nitelik ekler, namespace aynı adlı alanları farklı sözlüklerden ayırır. XML ürün adı, varyant, fiyat, stok, marka ve görsel gibi alanları taşıyabilir; fakat bu alanların ticari anlamını kendiliğinden belirlemez. “stock” alanının fiziksel, rezerve düşülmüş veya satılabilir stok olması veri sözleşmesinde açıklanmalıdır.

Kavram	Ne işe yarar?	Entegrasyon notu
Element	Hiyerarşik alanı temsil eder	Aynı bilgi farklı tedarikçide farklı yolda olabilir
Attribute	Bir öğeye kısa nitelik ekler	Element ile attribute arasında otomatik eşdeğerlik varsayılmaz
Namespace	Ad çakışmasını önler	Prefix değişebilir; eşleşme namespace URI üzerinden yapılmalıdır
CDATA	İçeriği markup olarak yorumlamadan taşır	Sanitizasyon veya güvenlik kontrolü değildir
Encoding	Baytların karaktere çevrilmesini belirtir	Beyan, HTTP başlığı ve gerçek bayt dizisi uyuşmalıdır

Namespaces in XML belgesi namespace kapsamını açıklar. CDATA içindeki HTML, zararsız kabul edilmemeli; ürün açıklaması yayımlanmadan önce izinli etiket ve URL politikasıyla temizlenmelidir. UTF-8 beyanı bulunan dosyanın gerçekte farklı encoding ile üretilmesi Türkçe karakterleri bozabilir; BOM, XML declaration, HTTP Content-Type ve örnek karakterler birlikte test edilmelidir.

XML Linki, XML Alma ve XML Verme Ne Demektir?

XML linki çoğunlukla bir feed dosyasının HTTPS adresidir; bazen kullanıcı adı, parola, imzalı token veya IP kısıtı gerekir. XML alma, tedarikçi verisini işletmenin sistemine içe aktaran inbound akıştır. XML verme ise işletmenin verisini fiyat karşılaştırma, bayi veya başka bir sisteme outbound sunmasıdır. İki yön farklı veri sahipliği, güvenlik ve hata sözleşmeleri gerektirir. Bu rehber inbound tedarikçi kaynağına odaklanır.

Yöntem	Artı	Sınır	Kontrol
HTTPS URL	Kolay zamanlanır, koşullu istek mümkün	Kaynak URL değişebilir	TLS, allowlist, redirect ve boyut sınırı
Kimlik doğrulamalı HTTPS	Erişim denetlenebilir	Secret yaşam döngüsü gerekir	Vault, rotasyon, log maskeleme
SFTP	Dosya bırakma ve erişim kontrolü güçlü olabilir	Anahtar ve dosya tamamlanma işareti gerekir	Host key doğrulama, atomik rename
API tabanlı XML	Sayfalama ve filtreleme sunabilir	Kota ve sürüm yönetimi gerekir	Rate limit, cursor, idempotency
Manuel yükleme	Küçük pilot için basit	Süreklilik ve izlenebilirlik zayıf	Dosya kaynağı, hash ve onay kaydı

XML, CSV, Excel, JSON API ve SOAP Arasındaki Farklar Nelerdir?

Format seçimi tek başına kaliteyi belirlemez. XML hiyerarşi ve namespace açısından güçlüdür; CSV düz tablo için ekonomiktir; JSON web API’lerinde yaygındır; SOAP mesajlaşma sözleşmesi ve zarf yapısı getirir; panel girişi düşük hacimde denetimli olabilir. Karar veri yapısı, değişim sıklığı, doğrulama, güvenlik ve işletme kapasitesiyle verilmelidir.

Yaklaşım	Uygun olduğu durum	Zayıf taraf	Kontrol ihtiyacı
XML feed	Hiyerarşik katalog ve periyodik toplu veri	Şema farklılığı, parser güvenliği	XSD, streaming, mapping
CSV/Excel	Düz ve küçük/orta veri seti	Tip ve hiyerarşi belirsizliği	Sütun sözlüğü, encoding
JSON API	Sık ve seçici veri alışverişi	Kota, sürüm ve ağ bağımlılığı	OpenAPI/sözleşme, retry
SOAP	Kurumsal sözleşmeli servisler	Karmaşıklık ve ağır mesaj	WSDL, güvenli parser
Panel girişi	Az ürün, seyrek değişiklik	Manuel hata ve ölçek sınırı	Çift kontrol, audit

Tedarikçi XML’i ile Google Merchant Center Feed’i Aynı Şey midir?

Hayır. Tedarikçi XML’i işletmenin katalog oluşturmak için aldığı iç kaynaktır. Google Merchant Center veri kaynağı ise ürünlerin Google yüzeylerinde değerlendirilmesi için Google’ın alan ve politika sözleşmesine göre hazırlanan dışa dönük kaynaktır. Google’ın veri kaynağı seçenekleri XML’in yalnız kabul edilen yöntemlerden biri olduğunu gösterir. Tedarikçi feed’ini değiştirmeden Google’a göndermek; kimlik, fiyat, stok, URL ve politika uyuşmazlığı yaratabilir. Bu ayrım burada özetlenir; Merchant Center kurulumu ayrı bir niyettir.

Boyut	Tedarikçi XML’i	Merchant Center veri kaynağı
Yön	Tedarikçiden mağazaya inbound	Mağazadan Google’a outbound
Şema	Tedarikçiye özgü olabilir	Google ürün veri şartlarına bağlı
Amaç	Ürün ana verisini beslemek	Google’da ürün sunumu
Kimlik	Supplier SKU, GTIN, MPN karışımı olabilir	Kalıcı item id ve gerekli tanımlayıcılar
Kontrol	Normalize, zenginleştir, onayla	Canlı sayfayla fiyat ve stok tutarlılığı

Her Tedarikçinin XML Yapısı Aynı mıdır?

Evrensel ve zorunlu tek bir tedarikçi ürün XML şeması yoktur. Bir kaynak “ProductCode”, diğeri “sku”; biri fiyatı KDV dâhil, diğeri hariç; biri eksik ürünü silinmiş, diğeri geçici hata olarak yorumlayabilir. Bu yüzden örnek dosya görmek yalnız başlangıçtır. Alan adları, yollar, tipler, birimler, null davranışı, güncelleme sahibi ve yaşam döngüsü yazılı veri sözlüğüne dönüşmelidir.

Alan	Tip	Zorunlu	Birim/format	Boş davranışı	Sahip
supplier_sku	String	Evet	Büyük/küçük harf korunur	Kaydı reddet	Tedarikçi
gtin	String	Koşullu	8/12/13/14 hane	İncele; sıfırla doldurma	Marka sahibi
stock_qty	Decimal	Evet	Adet veya paket açıkça yazılır	Yayını dondur	Tedarikçi
purchase_price	Decimal	Evet	Para birimi ayrı alan	Fiyatı güncelleme	Tedarikçi
tax_rate	Decimal	Koşullu	Yüzde	Kategori kuralına gönder	Satıcı/vergi uzmanı
image_url	URL	Hayır	HTTPS	Mevcut görseli koru	İçerik sahibi

Well-Formed XML, XSD Geçerliliği ve Ticari Geçerlilik Nasıl Ayrılır?

Well-formed belge XML sözdizimi kurallarına uyar. XSD, öğe yapısı, veri tipi ve bazı kısıtları doğrular. W3C XSD 1.1 yapısal doğrulama için güçlü araçlar tanımlar; yine de “fiyat kârlı mı”, “görsel kullanım hakkı var mı” veya “stok satılabilir mi” sorularını otomatik cevaplamaz. XML processor profiles ayrıca işlemci davranışlarının uygulamaya göre değişebileceğini anlamaya yardım eder.

Veri Sözleşmesi, Veri Sözlüğü ve Şema Versiyonlama Neden Gereklidir?

Veri sözlüğü alanların anlamını; veri sözleşmesi tarafların üretim, erişim, değişiklik, hata ve destek yükümlülüklerini tanımlar. Sözleşmede şema sürümü, geriye uyumluluk, değişiklik bildirim süresi, örnek dosya, freshness hedefi, tam/delta davranışı, silme işareti ve kısmi başarının sonucu bulunmalıdır. Schema drift yalnız alan adının değişmesi değildir; tip, birim, hiyerarşi, boş değer ve anlam değişimi de drift’tir.

Ürün Kimliği: SKU, GTIN, EAN, UPC, MPN ve Marka Nasıl Yönetilir?

Supplier SKU tedarikçinin kendi kimliğidir; merchant SKU satıcının kalıcı iç kimliğidir; kanal SKU ise satış kanalındaki kaydı temsil eder. Aynı değerleri kullanmak mümkün olsa da sahiplik ve değişim kuralı ayrılmalıdır. GS1 GTIN açıklaması, GTIN’in ticari öğeleri tanımlamak için kullanıldığını belirtir. GTIN metin olarak saklanmalı; sayısal tipe çevrilip baştaki sıfırlar kaybedilmemelidir. MPN üretici parça numarasıdır ve marka bağlamıyla değerlendirilmelidir.

Ürün kimlikleri hazırlanırken SKU, barkod ve varyant hazırlama rehberi temel veri kalitesi bağlamını tamamlar. Entegrasyon, bu hazırlığın yerine geçmez; gelen veriyi kurallara göre eşler. Aynı GTIN iki aktif üründe gelirse otomatik birleştirme yerine marka, MPN, paket adedi ve varyant boyutu karşılaştırılmalıdır.

Varyant, Kategori ve Özellik Eşleştirme Nasıl Yapılır?

Parent-child modelinde ana ürün ortak açıklama ve görselleri; varyant ise renk, beden, SKU, GTIN, stok ve fiyatı taşır. Tedarikçi “Lacivert”, “NAVY” ve “Navy Blue” gönderebilir; hedef sözlük bunları kontrollü değere normalize eder. Kategori eşleştirme, tedarikçi kategorisini doğrudan site kategorisi yapmak değildir. Kategori; zorunlu özellik, vergi, ürün güvenliği, filtre ve SEO davranışını etkileyebilir.

Ürün Başlığı, Açıklaması ve Görselleri Doğrudan Yayınlanmalı mıdır?

Genellikle hayır. Tedarikçi başlığı iç kod, büyük harf veya kanal için uygunsuz ifade içerebilir. Açıklama eksik, kopya, yabancı dilde ya da zararlı HTML barındırabilir. Görsel URL’si geçici olabilir; hotlink, içerik türü, boyut, yönlendirme ve kullanım hakkı sorunları doğurabilir. Entegrasyon önce içeriği staging’e almalı, kaynak ve lisans kaydını tutmalı, HTML’i sanitize etmeli ve kategoriye göre zorunlu güvenlik alanlarını kontrol etmelidir.

İçeriğin kullanıcıya sunumu için ürün sayfası kalite ölçütleri, kopya ve indeksleme kararları için e-ticaret SEO yaklaşımı ayrı uzmanlık kaynaklarıdır. XML entegrasyonu içerik hakkını veya SEO başarısını garanti etmez.

Full Feed, Delta Feed ve Ürün Yaşam Döngüsü Nasıl Yönetilir?

Full feed belirli andaki bütün kapsamı temsil eder; delta feed yalnız değişiklikleri taşır. Full snapshot mutabakatı kolaylaştırır fakat büyük dosya ve uzun işlem yaratabilir. Delta verimlidir fakat sıra, kaçırılan olay ve başlangıç noktası yönetimi ister. Feed’de görünmeyen ürün otomatik silinmemelidir: dosya yarım kalmış, kategori filtresi değişmiş veya tedarikçi geçici hata yaşamış olabilir. “Yok”, “pasif”, “stok dışı”, “silindi” ve “geçici eksik” ayrı durumlar olmalıdır.

Tedarikçi Stoğu Satılabilir Stok mudur?

Tedarikçi stoğu çoğu zaman yalnız kaynak miktardır. Başka bayilerin satışı, feed üretim gecikmesi, rezervasyon, paket içeriği, minimum sipariş, güvenlik stoğu ve kanal tahsisi düşülmeden doğrudan yayınlanırsa fazla satış riski doğar. Satılabilir stok; kaynak stoktan doğrulanmış rezervasyon, tampon, paket gereksinimi ve işletme kısıtları çıkarılarak hesaplanır. Kesin formül ürün ve tedarikçi davranışına göre test edilmelidir. Genel stok planlaması için fiziksel ve satılabilir stok rehberi daha geniş çerçeve sunar.

Tedarikçi Fiyatı Satış Fiyatına Nasıl Dönüştürülür?

Alış fiyatı, liste fiyatı ve satış fiyatı ayrılmalıdır. KDV dâhil/hariç bilgisi, para birimi, kur kaynağı ve zamanı, iskonto, ödeme maliyeti, kargo, pazaryeri komisyonu, iade payı, hedef marj ve yuvarlama politikası formülde açıkça yer almalıdır. Fiyatlandırma kuralları için kârlılık ve fiyat koruması rehberi tamamlayıcıdır. XML yalnız girdiyi taşır.

Temsili örnek: KDV hariç alış fiyatı 1.000 TL, KDV oranı yüzde 20, değişken operasyon maliyeti 120 TL ve hedef brüt katkı 280 TL ise temsili taban satış fiyatı KDV dâhil 1.680 TL’dir: (1.000 + 120 + 280) × 1,20. Komisyon satış fiyatının yüzdesiyse denklem buna göre yeniden çözülmelidir; yüzdeyi maliyete sabit tutar gibi eklemek tutarsız sonuç verir. Bu rakam sektör ortalaması veya Solofor fiyatı değildir.

Çoklu Tedarikçide Aynı Ürün Nasıl Yönetilir?

Aynı ürün birden çok kaynaktan geldiğinde tek bir “en iyi tedarikçi” seçmek her alan için doğru değildir. İçerik marka sahibinden, stok en güvenilir ve hızlı kaynaktan, fiyat toplam maliyeti en düşük kaynaktan gelebilir. GTIN tek başına yeterli değilse marka, MPN, paket adedi ve varyant birlikte doğrulanır. Stokları toplamak yalnız kaynakların aynı fiziksel stoğu temsil etmediği kanıtlandığında güvenlidir.

XML Ne Sıklıkta Çekilmelidir ve Değişiklik Nasıl Algılanır?

Polling sıklığı iş riskine, kaynak üretim sıklığına, dosya boyutuna ve tedarikçi kotasına göre belirlenir. Tedarikçi feed’i dört saatte bir üretiyorsa dakikada bir indirmek veriyi gerçek zamanlı yapmaz. Kaynak üretim zamanı, indirme başlangıcı, parse bitişi ve canlı yayın zamanı ayrı ölçülmelidir. RFC Editor’daki RFC 9110, ETag ve Last-Modified doğrulayıcılarını ve koşullu istek semantiğini tanımlar. Kaynak destekliyorsa If-None-Match veya If-Modified-Since gereksiz aktarımı azaltabilir; 304 yeni ürün işlendiği anlamına gelmez, içerik değişmedi demektir.

Büyük XML Dosyaları Nasıl Güvenli ve Verimli İşlenir?

DOM bütün belgeyi belleğe alır; küçük ve kontrollü belgelerde geliştirmeyi kolaylaştırabilir. Streaming parser kaydı sırayla işler ve büyük dosyada bellek kullanımını sınırlar; ancak çapraz kayıt bağımlılıklarını ayrı tasarlamak gerekir. Hiçbiri koşulsuz üstün değildir. Sıkıştırılmış dosyada sıkıştırılmış ve açılmış boyut, oran, öğe sayısı, derinlik, attribute sayısı, metin uzunluğu ve toplam süre sınırlandırılmalıdır. Arka plan import işinin site performansına etkisi için e-ticaret performans rehberi tamamlayıcıdır.

İçe Aktarma Hattı Hangi Aşamalara Ayrılmalıdır?

Güvenilir hat, tek bir “import başarılı” bayrağı yerine her aşamayı ölçer. Run ID bütün log, metrik ve audit kayıtlarını bağlar. Aynı kaynak sürümü yeniden işlendiğinde idempotency anahtarı mükerrer ürün üretmemelidir. Retry yalnız geçici hatalarda ve sınırlı bütçeyle uygulanır; kalıcı veri hataları dead-letter queue veya inceleme kuyruğuna gönderilir.

Staging, Dry Run, Canary ve Rollback Neden Gereklidir?

Staging, kaynağın canlı kataloğu doğrudan değiştirmesini önler. Dry run yeni ürün, kapanacak ürün, fiyat ve stok dağılımını önizler. Canary seçilmiş kategori veya düşük riskli ürün grubunda sınırlı yayın yapar. Atomik batch ya tamamını uygular ya da geri alır; bu mümkün değilse kısmi başarı semantiği yazılı olmalıdır. Rollback yalnız veriyi değil mapping, fiyat formülü, kategori sözlüğü ve içerik temizleme sürümünü de kapsamalıdır.

XML Entegrasyonu Nasıl İzlenir ve Mutabakat Nasıl Yapılır?

Log tekil olayın ayrıntısını, metrik sayısal eğilimi, audit kimin hangi kuralı değiştirdiğini, alarm ise müdahale gerektiren koşulu gösterir. Kaynak kayıt sayısı, parse edilen, kabul edilen, reddedilen, yeni, güncellenen, pasife alınan ve canlı read-back sayıları aynı run içinde karşılaştırılmalıdır. Son başarılı import zamanı kullanıcıya gösterilmeli; son deneme zamanı başarı gibi sunulmamalıdır. e-ticaret raporlama yaklaşımı bu KPI’ların ticari raporlarla bağını açıklar.

XML Entegrasyonu Güvenliği Nasıl Kurulmalıdır?

Güvenilmeyen XML, veri dosyası olduğu için güvenli değildir. OWASP XXE Prevention, DTD ve external entity işlemenin kapatılmasını, external DTD yüklemenin ve XInclude’ın engellenmesini, entity expansion ve kaynak sınırlarının uygulanmasını önerir. OWASP XML Security şema zehirleme, entity expansion ve XML enjeksiyonu gibi ek riskleri ele alır. Parser ayarları dil ve kütüphane sürümüne göre test edilmelidir; “varsayılan güvenlidir” kabulü yapılmamalıdır.

XML URL’sini sunucunun çekmesi SSRF yüzeyi oluşturur. OWASP SSRF Prevention doğrultusunda protokol, alan adı, port ve gerekiyorsa yol allowlist’i; DNS çözümlemesi; loopback, private, link-local ve metadata IP engeli; her yönlendirme sonrasında yeniden doğrulama; egress kısıtı uygulanmalıdır. TLS sertifika doğrulaması kapatılmamalı, secret’lar vault’ta tutulmalı, rotasyon ve revoke desteklenmelidir. OWASP Logging ile uyumlu olarak token, parola, kişisel veri ve tam yetkili URL loglanmamalıdır.

Tedarikçi Sözleşmesinde Hangi Veri Maddeleri Bulunmalıdır?

Teknik entegrasyon, tedarikçi sözleşmesinden bağımsız değildir. Uptime tek başına yeterli değildir; feed üretim sıklığı ve freshness hedefi, alan doğruluğu, şema değişiklik bildirimi, destek sorumlusu, silme/pasif semantiği, içerik-görsel lisansı, ürün güvenliği verisi, export ve fesih davranışı yazılmalıdır. Kabul kriterleri ölçülebilir, kanıtı belirli ve ihlal durumunda eskalasyonu tanımlı olmalıdır.

Ürün Güvenliği ve Zorunlu Bilgiler XML’den Gelmiyorsa Ne Olur?

Tedarikçinin veri sağlaması satıcının çevrim içi sunum ve ürün uygunluğu sorumluluklarını otomatik kaldırmaz. Ticaret Bakanlığının uzaktan satışta ürün güvenliği düzenlemesi kapsamında gerekli Türkçe uyarı, güvenlik bilgisi ve işaretlerin satış ilanında bulunması gerekebilir. Kategoriye özgü teknik düzenleme ayrıca incelenmelidir. XML’de alan yoksa ürün otomatik yayınlanmamalı; satıcı doğrulanmış kaynaktan tamamlamalıdır. Bu bölüm hukuki danışmanlık değildir; güncel mevzuat ve uzman görüşüyle doğrulanmalıdır.

XML Entegrasyonu KVKK Kapsamına Girer mi?

Yalnız ürün kataloğu çoğu durumda kişisel veri içermeyebilir; ancak feed, URL, destek kaydı veya loglarda gerçek kişi adı, e-posta, telefon, IP, tokenla ilişkilendirilen hesap ya da sipariş verisi bulunursa kapsam analizi gerekir. Yurt dışındaki bulut, izleme veya yapay zekâ hizmeti kişisel veri alıyorsa aktarım şartları ayrıca değerlendirilmelidir. KVKK’nın yurt dışına aktarım rehberi ve güncel standart sözleşme dokümanları, uygun mekanizmanın belirlenmesinde resmî başlangıç noktasıdır. Veri minimizasyonu, saklama süresi, erişim yetkisi ve alt işleyen envanteri yazılı olmalıdır. Kesin hukuki değerlendirme somut veri akışına göre yapılır.

XML Entegrasyonu SEO’yu Nasıl Etkiler?

Binlerce tedarikçi açıklamasını aynen yayınlamak düşük değerli ve birbirine benzeyen sayfalar oluşturabilir. Otomatik “kopya içerik cezası” gibi kesin bir iddia doğru değildir; asıl hedef kullanıcıya özgün, doğru ve yararlı ürün bilgisi sunmaktır. Ürün kimliği ile URL kararlı tutulmalı, varyant stratejisi, stok dışı davranış, canonical ve indeksleme kuralları editoryal kararla belirlenmelidir. Product structured data, tedarikçi XML feed’i değildir; canlı sayfadaki görünür bilgiyle tutarlı ayrı bir işarettir.

Yapay Zekâ XML Entegrasyonunda Nasıl Kullanılabilir?

Yapay zekâ alan ve kategori eşleştirme önerisi, hata kümelendirme, anomali önceliklendirme ve açıklama taslağı üretebilir. Ancak öneri kaynak değer, güven skoru ve gerekçeyle sunulmalı; kimlik birleştirme, fiyat, ürün güvenliği ve hukuki iddia insan onayı olmadan uygulanmamalıdır. Model tedarikçi verisini eğitim veya üçüncü taraf hizmet için kullanacaksa gizlilik ve sözleşme kapsamı doğrulanmalıdır. yapay zekâ destekli e-ticaret yaklaşımı içerik ve operasyon kullanım alanlarını tamamlar.

Beş Ayrıntılı Operasyon Senaryosu

Senaryo 1: Küçük katalog ve tek tedarikçi

Temsili 800 ürün, günlük full feed, 15 MB dosya. İşletme önce 80 üründe dry run yapar; SKU ve KDV alanları yüzde 100 eşleşmeden yayına geçmez. Kaynak dört saatte bir üretiliyorsa çekim de bu ritme yakın planlanır. İki ardışık başarılı run ve sıfır kritik fiyat anomalisi sonrası canary genişletilir.

Senaryo 2: Hızlı moda ve sık stok değişimi

Temsili 25.000 varyant, 30 dakikalık delta ve gece full snapshot. Supplier SKU değişebildiği için merchant SKU ile kalıcı mapping tutulur. ATS, tedarikçi miktarından temsili tampon ve açık sipariş rezervasyonu çıkarılarak hesaplanır. Delta sequence atlanırsa yayın durur ve full mutabakat çalışır.

Senaryo 3: Dövizli elektronik kataloğu

Temsili 12.000 ürün EUR alış fiyatıyla gelir. Kur kaynağı ve zamanı ayrı kaydedilir; KDV, garanti, marka ve MPN zorunludur. Yüzde 20’den büyük günlük fiyat değişimi temsili eşik olarak manuel onaya gider. GTIN çakışması marka ve paket adedi doğrulanmadan birleştirilmez.

Senaryo 4: Çoklu tedarikçi ve aynı ürün

Üç tedarikçi aynı GTIN’i gönderir. İçerik marka yetkili kaynaktan, stok en taze kaynaktan, fiyat landed cost formülünden seçilir. Aynı fiziksel depo olasılığı nedeniyle stoklar kanıt olmadan toplanmaz. Seçim nedeni her ürün için audit kaydında tutulur.

Senaryo 5: Büyük sıkıştırılmış feed

Temsili 2 GB açılmış boyuta ulaşabilen gzip feed streaming işlenir. Sıkıştırılmış/açılmış byte, öğe, derinlik ve süre limitleri uygulanır. 5.000 kayıtlık batch’ler staging’e yazılır; tüm batch mutabakatı geçmeden canlı indeks değiştirilmez. Kısmi dosyada hiçbir silme kararı çalışmaz.

XML Entegrasyonu İçin Tedarikçiye ve Sağlayıcıya Hangi Sorular Sorulmalıdır?

1. Feed full snapshot mı, delta mı; her ikisi varsa ilişki nasıl kurulur?
2. Kaynak üretim zamanı hangi alanla ve saat dilimiyle verilir?
3. Şema ve alan anlamları için sürümlü veri sözlüğü var mı?
4. Değişiklikler kaç gün önce ve hangi kanaldan bildirilir?
5. Supplier SKU hangi koşullarda değişebilir?
6. GTIN, marka ve MPN doğruluğundan kim sorumludur?
7. Duplicate SKU veya GTIN geldiğinde kaynak davranışı nedir?
8. Varyant parent-child ilişkisi hangi kalıcı anahtarla kurulur?
9. Stok alanı fiziksel, kullanılabilir, rezerve düşülmüş veya tahsis edilmiş miktardan hangisidir?
10. Sıfır, negatif, boş ve eksik stok ayrı ne anlama gelir?
11. Feed’de olmayan ürün silinmiş mi, geçici eksik mi sayılır?
12. Pasif ve tombstone sinyali var mı?
13. Alış fiyatı KDV dâhil mi, para birimi hangi alandadır?
14. İskonto ve kampanya fiyatlarının başlangıç/bitiş zamanı var mı?
15. Fiyat düzeltmesi geriye dönük yapılırsa nasıl bildirilir?
16. Kategori ve özellik sözlükleri sürümlü müdür?
17. Birim, ağırlık, desi ve paket adedi nasıl tanımlanır?
18. Açıklama ve görsellerin kullanım hakkı hangi kanalları kapsar?
19. Görsel URL’lerinin kalıcılık süresi ve erişim koşulu nedir?
20. Ürün güvenliği ve zorunlu uyarı alanları hangi kategorilerde sağlanır?
21. XML hangi protokol ve kimlik doğrulamayla sunulur?
22. TLS sertifikası, IP kısıtı ve secret rotasyonu nasıl yönetilir?
23. ETag veya Last-Modified destekleniyor mu?
24. 429 ve bakım penceresi davranışı nedir?
25. Maksimum dosya boyutu ve beklenen kayıt sayısı nedir?
26. Sıkıştırma biçimi ve açılmış boyut üst sınırı nedir?
27. Test ortamı ve hatalı örnek feed sağlanıyor mu?
28. Kısmi veya yarım dosya nasıl işaretlenir?
29. Geçmiş feed sürümleri ne kadar saklanır?
30. Hata desteğinin sorumlusu ve eskalasyon süresi nedir?
31. Freshness hedefi nasıl ölçülür ve raporlanır?
32. Mapping değişikliği kim tarafından onaylanır?
33. Dry run ve değişiklik önizlemesi var mı?
34. Canary ve rollback hangi kapsamı destekler?
35. Run ID, alan bazlı red nedeni ve audit log sunuluyor mu?
36. Kaynak-hedef mutabakat raporu alınabiliyor mu?
37. Veriler ve mapping kuralları taşınabilir formatta export edilebilir mi?
38. Fesihte secret, cache ve staging verileri nasıl silinir?
39. Standart mapping ile özel proje maliyeti nasıl ayrılır?
40. Ürün hacmi, tedarikçi sayısı ve çağrı limitleri yazılı olarak nerede yer alır?

PoC ve UAT Test Matrisi

XML Entegrasyonunun Maliyeti Hangi Kalemlerden Oluşur?

TCO yalnız modül lisansı değildir. Tedarikçi erişim ücreti, ilk analiz, mapping, veri temizleme, görsel indirme ve depolama, altyapı, güvenlik testi, izleme, bakım, şema değişikliği, destek, manuel inceleme ve çıkış maliyeti ayrı hesaplanmalıdır. Temsili tutarlar canlı Solofor fiyatı veya sektör ortalaması değildir; kurumun gerçek hacim ve işçilik verisiyle doldurulmalıdır.

Hazır XML Modülü mü, Özel Entegrasyon mu Seçilmelidir?

E-Ticaret Paketi Seçerken XML Entegrasyonu İçin Nelere Bakılmalıdır?

Tedarikçi sayısı, ürün/varyant hacmi, güncelleme ritmi, mapping arayüzü, staging, rollback, log, alarm, API/PIM/ERP genişlemesi, veri sahipliği ve kullanım limitleri yazılı karşılaştırılmalıdır. Genel altyapı seçimi için e-ticaret paketi seçim kriterleri, hazır ve özel çözüm sınırı için hazır e-ticaret altyapısı değerlendirmesi kullanılabilir. Sağlayıcının “XML var” demesi yerine gerçek örnek feed ile PoC sonucu istenmelidir.

SoloCommerce XML Entegrasyonunda Nasıl Konumlanır?

16.07.2026 tarihinde canlı SoloCommerce paketleri sayfasında ürün, kategori, varyant, fiyat ve set ürün yönetimi; paket seviyesine göre pazaryeri, stok/depo görünürlüğü, ERP/finans ve özel entegrasyon seçenekleri görülmektedir. Sayfa özel entegrasyonları Profesyonel ve Enterprise seviyelerinde teklif bazlı; SLA’yı Enterprise kapsamında konumlandırır. Canlı sayfa, her tedarikçi XML şemasının standart olarak hazır olduğunu veya belirli ürün/çağrı limitini garanti etmiyor. Bu nedenle XML kapsamı, örnek şema ve hacimle ayrıca doğrulanmalıdır.

Canlı pazaryeri sayfası ürün dağıtımı bağlamıyla ilgili olsa da sayfanın üst bölümünde “yakında” ifadesi görüldüğünden pazaryeri entegrasyonu kapsamı aktif ve eksiksiz hizmet garantisi gibi yorumlanmamalıdır. Tedarikçi XML’inin inbound normalizasyonu ile kanallara outbound aktarım ayrı projelerdir. SoloCommerce’i yalnız XML linki eklenen bir panel değil; markalı site, katalog, varyant, fiyat, stok, sipariş, içerik, raporlama ve gerektiğinde özel entegrasyonun birlikte değerlendirildiği bir altyapı olarak ele almak daha doğrudur.

E-Ticaret XML Entegrasyonu Kontrol Listesi

İş ihtiyacı ve kapsam

• ✅ Tedarikçi sayısını yaz.
• ✅ Ürün ve varyant hacmini ölç.
• ✅ Güncelleme ritmini belirle.
• ✅ Kritik kategorileri ayır.
• ✅ Alan sahiplerini belirle.
• ✅ Başarı KPI’larını yaz.
• ✅ Manuel süreç maliyetini ölç.
• ✅ No-go kapılarını onayla.

Tedarikçi ve sözleşme

• ✅ Örnek full feed al.
• ✅ Örnek delta feed al.
• ✅ Veri sözlüğünü imzalat.
• ✅ Freshness hedefini yaz.
• ✅ Değişiklik bildirim süresini yaz.
• ✅ Silme semantiğini tanımla.
• ✅ İçerik hakkını doğrula.
• ✅ Destek sorumlusunu belirle.
• ✅ Exit ve export maddesini ekle.

Erişim ve kimlik doğrulama

• ✅ HTTPS/SFTP yöntemini doğrula.
• ✅ Alan adı allowlist’i kur.
• ✅ Port ve yol sınırını yaz.
• ✅ Secret’ı vault’ta sakla.
• ✅ Rotasyon takvimini belirle.
• ✅ TLS doğrulamasını test et.
• ✅ IP kısıtını belgeleyin.
• ✅ Erişim iptalini prova et.

XML, şema ve encoding

• ✅ XML sürümünü kaydet.
• ✅ Namespace URI’lerini çıkar.
• ✅ XSD sürümünü kaydet.
• ✅ Well-formed kontrolü kur.
• ✅ UTF-8 örneklerini test et.
• ✅ BOM davranışını test et.
• ✅ CDATA içeriğini temizle.
• ✅ DTD’yi kapat.
• ✅ External entity’yi kapat.
• ✅ XInclude’ı kapat.

Veri sözleşmesi

• ✅ Her alanın tipini yaz.
• ✅ Zorunlu alanları işaretle.
• ✅ Null davranışını yaz.
• ✅ Boş metin davranışını yaz.
• ✅ Birimleri belirt.
• ✅ Para birimini belirt.
• ✅ Saat dilimini belirt.
• ✅ Alan sahibini ata.
• ✅ Hata kodlarını tanımla.
• ✅ Şema sürüm politikasını yaz.

Ürün kimliği

• ✅ Supplier SKU’yu metin tut.
• ✅ Merchant SKU’yu kalıcı yap.
• ✅ Kanal SKU’yu ayır.
• ✅ GTIN’i metin sakla.
• ✅ Check digit kontrolü yap.
• ✅ Marka ve MPN’i birlikte kullan.
• ✅ Duplicate kuralını yaz.
• ✅ Kimlik değişimini audit et.
• ✅ Yanlış birleşme rollback’i hazırla.

Varyant, kategori ve özellik

• ✅ Parent anahtarını doğrula.
• ✅ Varyant SKU’sunu doğrula.
• ✅ Renk sözlüğü kur.
• ✅ Beden sözlüğü kur.
• ✅ Kategori mapping’i onayla.
• ✅ Özellik mapping’ini ayır.
• ✅ Birim dönüşümünü test et.
• ✅ Paket adedini doğrula.
• ✅ Ağırlık/desiyi doğrula.
• ✅ Tanımsız değer kuyruğu kur.

İçerik ve görsel

• ✅ Başlık kalite kuralı kur.
• ✅ Açıklama sanitizasyonu yap.
• ✅ Görsel hakkını belgeleyin.
• ✅ URL allowlist’i uygula.
• ✅ Content-Type doğrula.
• ✅ Byte sınırı koy.
• ✅ Harici URL’yi kalıcı depoya al.
• ✅ Zorunlu uyarıları kontrol et.

Stok

• ✅ Stok semantiğini yaz.
• ✅ Kaynak üretim zamanını al.
• ✅ ATS formülünü belgeleyin.
• ✅ Rezervasyonu düş.
• ✅ Tamponu veriye göre belirle.
• ✅ Sıfırı silme sayma.
• ✅ Negatifi karantinaya al.
• ✅ Set stoğunu bileşenden hesapla.
• ✅ Çoklu kaynağı kanıtsız toplama.
• ✅ Stale feed politikasını uygula.

Fiyat, vergi ve döviz

• ✅ Alış/liste/satış fiyatını ayır.
• ✅ KDV durumunu yaz.
• ✅ Para birimini zorunlu tut.
• ✅ Kur kaynağını kaydet.
• ✅ Kur zamanını kaydet.
• ✅ Komisyonu formüle ekle.
• ✅ Kargo/iade maliyetini ekle.
• ✅ Price floor belirle.
• ✅ Price ceiling belirle.
• ✅ Anomali onayı kur.

Full/delta ve yaşam döngüsü

• ✅ Feed tipini doğrula.
• ✅ Sequence/cursor sakla.
• ✅ Tombstone sinyalini yaz.
• ✅ Pasif ile stok dışını ayır.
• ✅ Geçici eksiği silme.
• ✅ Periyodik full mutabakat yap.
• ✅ İki aşamalı pasif uygula.
• ✅ Geri dönüş penceresi tanımla.

Performans ve kapasite

• ✅ Dosya boyutu sınırı koy.
• ✅ Açılmış boyutu sınırla.
• ✅ Streaming seçimini test et.
• ✅ Derinlik sınırı koy.
• ✅ Öğe sayısını sınırla.
• ✅ Batch boyutunu ölç.
• ✅ İşlem süresini alarm yap.
• ✅ Site iş yükünden izole et.

Retry, idempotency ve kuyruk

• ✅ Run ID üret.
• ✅ Idempotency anahtarı tanımla.
• ✅ Hataları geçici/kalıcı ayır.
• ✅ Backoff uygula.
• ✅ Jitter ekle.
• ✅ Retry bütçesi koy.
• ✅ DLQ sahibi ata.
• ✅ Replay prosedürü yaz.

Log, metric, alarm ve mutabakat

• ✅ Kaynak sayısını ölç.
• ✅ Parse sayısını ölç.
• ✅ Red oranını ölç.
• ✅ Mapping coverage ölç.
• ✅ Freshness ölç.
• ✅ Read-back yap.
• ✅ Fark toleransını yaz.
• ✅ Son başarılı run’ı göster.
• ✅ Schema drift alarmı kur.
• ✅ Audit değişikliklerini sakla.

Güvenlik

• ✅ Protokol allowlist’i uygula.
• ✅ DNS/IP doğrula.
• ✅ Loopback’i engelle.
• ✅ Private IP’yi engelle.
• ✅ Link-local IP’yi engelle.
• ✅ Redirect’i yeniden doğrula.
• ✅ TLS zincirini doğrula.
• ✅ Secret maskele.
• ✅ DTD kapalı testi yap.
• ✅ XXE negatif testi yap.
• ✅ Entity limitini test et.
• ✅ Gzip oranını sınırla.
• ✅ HTML’i sanitize et.
• ✅ Görsel fetch’i izole et.

SEO ve kullanıcı deneyimi

• ✅ Kopya açıklamayı zenginleştir.
• ✅ URL kimliğini kararlı tut.
• ✅ Stok dışı politikasını yaz.
• ✅ Varyant indekslemesini planla.
• ✅ Görsel alt bilgisini doğrula.
• ✅ Canlı fiyat tutarlılığını kontrol et.
• ✅ Yapılandırılmış veriyi ayrı yönet.

Hukuk ve ürün güvenliği

• ✅ Lisans kapsamını doğrula.
• ✅ Marka kullanımını doğrula.
• ✅ Üretici/ithalatçı bilgisini kontrol et.
• ✅ Türkçe uyarıyı kontrol et.
• ✅ Kategori mevzuatını incele.
• ✅ KVKK veri akışını çıkar.
• ✅ Yurt dışı aktarımı değerlendirin.

PoC, UAT ve canlıya geçiş

• ✅ Gerçek feed kullan.
• ✅ Bozuk feed kullan.
• ✅ Sınır değerleri test et.
• ✅ Güvenlik negatif testleri yap.
• ✅ Dry run raporu al.
• ✅ Canary ürün seç.
• ✅ Go/no-go toplantısı yap.
• ✅ Rollback prova et.
• ✅ İlk 24 saat nöbeti planla.
• ✅ 30 günlük trend incele.

Maliyet ve çıkış

• ✅ Lisansı ayrı hesapla.
• ✅ Mapping maliyetini hesapla.
• ✅ Altyapıyı hesapla.
• ✅ Bakımı hesapla.
• ✅ Manuel işi hesapla.
• ✅ Hata maliyetini hesapla.
• ✅ Export örneği al.
• ✅ Fesih silme kanıtı iste.

AI ve insan onayı

• ✅ AI önerisini güven skoruyla göster.
• ✅ Kaynağı öneriyle birlikte tut.
• ✅ Kimlik birleşmesini insana onaylat.
• ✅ Fiyatı insansız değiştirme.
• ✅ Kişisel veri kullanımını doğrula.

Sık Yapılan XML Entegrasyonu Hataları ve Kırmızı Bayraklar

• ⚠️ XML linkini yeterli entegrasyon sanmak.
• ⚠️ Şema ve veri sözleşmesi olmadan başlamak.
• ⚠️ Supplier SKU’yu değişmez sanmak.
• ⚠️ Barkodu sayısal saklayıp baştaki sıfırı kaybetmek.
• ⚠️ Null, sıfır ve eksik alanı aynı yorumlamak.
• ⚠️ Feed’de olmayan ürünü hemen silmek.
• ⚠️ Tedarikçi stoğunu doğrudan satışa açmak.
• ⚠️ KDV durumunu varsaymak.
• ⚠️ Para birimini varsaymak.
• ⚠️ Fiyat guardrail’i kullanmamak.
• ⚠️ Tedarikçi açıklamasını kontrolsüz yayınlamak.
• ⚠️ Görsel kullanım hakkını doğrulamamak.
• ⚠️ Harici görsel URL’sine kalıcı bağımlı olmak.
• ⚠️ Her dosyayı DOM’a yüklemek.
• ⚠️ Sıkıştırılmış dosya limitini belirlememek.
• ⚠️ HTTP 200’ü iş başarısı sanmak.
• ⚠️ Retry sırasında duplicate üretmek.
• ⚠️ Mutabakat yapmamak.
• ⚠️ Son başarılı import zamanını izlememek.
• ⚠️ Schema drift alarmı kurmamak.
• ⚠️ DTD ve external entity’yi açık bırakmak.
• ⚠️ XML URL’siyle SSRF yüzeyi oluşturmak.
• ⚠️ Redirect sonrası hedefi doğrulamamak.
• ⚠️ DNS/IP değişimini kontrol etmemek.
• ⚠️ TLS doğrulamasını kapatmak.
• ⚠️ Parolayı URL içinde taşımak.
• ⚠️ Secret’ı loglamak.
• ⚠️ Gömülü HTML’i sanitize etmemek.
• ⚠️ Tedarikçi değişikliğini sözleşmede düzenlememek.
• ⚠️ PoC’yi yalnız temiz dosyayla yapmak.
• ⚠️ Rollback olmadan canlıya çıkmak.
• ⚠️ Paket kapsamını doğrulamadan garanti yazmak.
• ⚠️ AI mapping önerisini test etmeden uygulamak.
• ⚠️ Full ve delta semantiğini karıştırmak.
• ⚠️ Kaynak üretim zamanı olmadan gerçek zamanlılık iddia etmek.
• ⚠️ Stok sıfırını ürün silme kabul etmek.
• ⚠️ Kampanya fiyatını tedarikçi fiyatıyla ezmek.
• ⚠️ Aynı GTIN’i koşulsuz birleştirmek.
• ⚠️ Parent stokunu bütün varyantlara kopyalamak.
• ⚠️ Kategori ile özelliği aynı mapping saymak.
• ⚠️ Birim dönüşümünde ondalık ayırıcıyı atlamak.
• ⚠️ 429 yanıtında sınırsız retry yapmak.
• ⚠️ DLQ’yu sahipsiz bırakmak.
• ⚠️ Kısmi dosyada toplu pasif yapmak.
• ⚠️ Read-back yapmadan yayını başarılı saymak.
• ⚠️ Run ID olmadan olayları ilişkilendirmek.
• ⚠️ Audit kaydı tutmamak.
• ⚠️ Ürün güvenliği alanını tedarikçiye tamamen devretmek.
• ⚠️ Vendor lock-in ve export’u sormamak.
• ⚠️ TCO’yu yalnız lisans kabul etmek.
• ⚠️ Görsel fetch için boyut/tür sınırı koymamak.
• ⚠️ Stale feed’de eski fiyatı sonsuza kadar kullanmak.
• ⚠️ Canary olmadan bütün kataloğu açmak.
• ⚠️ Mapping sürümünü rollback paketine almamak.

Sıkça Sorulan Sorular

E-ticaret XML entegrasyonu nedir?

Uçtan uca akış; kaynağa bağlanma, dosyayı indirme, XML sözdizimini güvenli biçimde ayrıştırma, şema ve iş kurallarını doğrulama, alanları işletmenin modeline eşleme, sonuçları staging alanında karşılaştırma, onaylanan değişiklikleri yayınlama ve canlı veriyi yeniden okuyarak mutabakat yapma adımlarından oluşur.

XML entegrasyonu nasıl çalışır?

Binlerce tedarikçi açıklamasını aynen yayınlamak düşük değerli ve birbirine benzeyen sayfalar oluşturabilir. Otomatik “kopya içerik cezası” gibi kesin bir iddia doğru değildir; asıl hedef kullanıcıya özgün, doğru ve yararlı ürün bilgisi sunmaktır.

Kısa Değerlendirme

XML formatı tek başına otomasyon, doğruluk veya güvenlik sağlamaz. Güvenilir e-ticaret XML entegrasyonu; kalıcı ürün kimliği, sürümlü mapping, stok ve fiyat semantiği, içerik hakkı, güvenli fetch ve parser, staging, guardrail, idempotency, rollback, read-back ve mutabakatı tek işletme modeli içinde birleştirir. İlk adım tedarikçiden gerçek örnek feed, alan sözlüğü, güncelleme takvimi ve değişiklik bildirimini yazılı istemektir. Ardından risk matrisi ve PoC hazırlanmalı; dry run ile farklar görülmeli, sınırlı canary ürün grubu yayınlanmalı ve ilk 24 saat, 7 gün ve 30 günlük izleme kapıları işletilmelidir.

SoloCommerce değerlendirilecekse ürün, stok ve fiyat yönetimi destekli e-ticaret paketini yalnız pazarlama vaadiyle değil; tedarikçi şeması, ürün hacmi, güncelleme sıklığı, mapping, staging, güvenlik, raporlama ve özel proje ihtiyacıyla birlikte karşılaştırın. İçerik ve görsel hakkı, ürün güvenliği, TCO ve çıkış planı doğrulanmadan bütün ürünleri otomatik yayına almayın. Doğru hedef “tek tıkla sıfır hata” değil; hatayı erken gören, değişikliği izleyen ve gerektiğinde güvenle geri alabilen sürdürülebilir veri hattıdır.