XML entegrasyonu ne işe yarar?
XML entegrasyonu, ürün bilgilerinin belirli bir dosya veya veri formatı üzerinden başka sisteme aktarılmasıdır.
Pazaryeri tarafında ürün adı, fiyat, stok, barkod, kategori ve görsel gibi alanlar doğru eşleşmelidir.
Basit görünen tarafı ürünleri toplu aktarmaktır; asıl zor taraf ise her pazaryerinin farklı kural, zorunlu alan, kategori, batch ve onay süreçlerine uyum sağlamaktır.
Neden proje bazlı değerlendirilir?
Her pazaryerinin istediği veri alanı, kategori mantığı ve hata mesajı farklı olabilir.
Bu yüzden entegrasyon fiyatı ürün sayısına, veri kalitesine, stok/fiyat senkronizasyonuna ve bakım ihtiyacına göre değişir.
Aynı XML dosyası bir pazaryerinde sorunsuz çalışırken başka bir pazaryerinde marka, kategori, barkod, attribute veya panel onayı yüzünden takılabilir.
Gerçek projede hedef neydi?
Amaç XML kaynak ürün verisini pazaryerlerine mümkün olduğunca eksiksiz aktarmak ve sonrasında bu akışı otomatik çalışır hale getirmekti.
XML'de olup pazaryerinde olmayan ürünlerin açılması, XML'de olup pazaryerinde olan ürünlerin stok/fiyat güncellenmesi, XML'de artık olmayan ürünlerin stok 0 veya pasif hale getirilmesi planlandı.
Müşterinin fiyat formülü de sisteme işlendi: bayi fiyatına sabit maliyet ekleniyor, komisyon katsayısı uygulanıyor ve son satış fiyatı otomatik hesaplanıyordu.
Stok kodu ve barkod eşleşmesi neden kritiktir?
Pazaryeri entegrasyonlarında ürünleri doğru eşleştirmek için genellikle stok kodu veya barkod anahtar olarak kullanılır.
Eğer aynı ürün farklı prefixlerle veya farklı barkod evrenleriyle pazaryerine yüklenmişse sistem aynı ürünü yeni ürün sanabilir ya da yanlış kaydı güncellemeye çalışabilir.
Bu yüzden entegrasyonda ilk işlerden biri XML'de var / pazaryerinde var, XML'de var / pazaryerinde yok, XML'de yok / pazaryerinde var ayrımlarını net raporlamaktır.
n11 tarafında ne öğrenildi?
n11 tarafında ilk yaklaşım katalog ID odaklı ilerlemekti; fakat bazı ürünlerde katalog bulunamadığında süreç duruyordu.
Daha başarılı çözüm, XML'de olup n11'de olmayan ürünleri bulup kategori adaylarını sırayla deneyen bir ürün açma akışı kurmak oldu.
Kategori uyumsuzluğu geldiğinde sistem tamamen durmak yerine sonraki kategori adayına geçecek şekilde planlandı. Böylece tek hata tüm ürün aktarımını kesmedi.
Fiyat güncellemede de pazaryerinin aşırı indirim ve minimum fiyat kuralları dikkate alındı; bazı ürünlerde özel fiyat override ihtiyacı oluşabileceği görüldü.
Trendyol tarafında attribute ve marka yönetimi
Trendyol'da marka, kategori ve zorunlu attribute alanları ürün açma sürecinin merkezindedir.
Projede marka ID'si API üzerinden doğrulandı, Beden ve Materyal gibi zorunlu alanlar payload'a doğru şekilde eklendi.
Aynı attributeId iki kez gönderildiğinde validasyon hatası oluştuğu için statik ve dinamik attribute çakışmalarında son değer kazansın mantığı kuruldu.
Aynı barkodlu ürün hataları da her zaman başarısızlık sayılmadı; bazı durumlarda ürün zaten sisteme girmiş olduğu için create yerine mevcut kayıt mantığıyla düşünmek gerekti.
Pazarama neden zorlayıcıydı?
Pazarama tarafında panelde görünen ürün sayısı ile API'de görünen ürün sayısı farklı davranabildi.
Approved false ürünler API'de var gibi görünse de pratikte satışa çıkmış ürün anlamına gelmedi. Bu yüzden eksik ürün sayımı sadece ham API cevabına göre yapılamadı.
Aynı ürünün farklı prefixlerle tekrar yüklenmesi duplicate sorununa yol açtı. Çözüm olarak keeper seçme, kopyaları stok 0 yapma ve create kodunu tekrar tekrar aynı ürünü yüklemeyecek şekilde koruma yaklaşımı kuruldu.
Fiyat ve stok güncellemede doğru endpointlerin v2 olduğu görüldü; batch/dataId sonuçlarını ayrıca kontrol etmek gerekti.
PTTAVM tarafında prefixli barkod farkı
PTTAVM entegrasyonunda ilk denemelerde XML barkodlarıyla güncelleme yapılmak istendiğinde işlenecek ürün sayısı 0 dönebildi.
Asıl kritik fark, pazaryeri tarafındaki gerçek update barkodunun PTT prefixli olmasıydı.
Bu yüzden XML koduyla eşleşme yapılsa bile update payload'ında pazaryerinin beklediği prefixli barkod kullanılmalıydı.
Ayrıca trackingId ile sonucun tamamlanıp tamamlanmadığını takip etmek, sadece ilk HTTP cevabına güvenmemek gerekti.
Cron ve flock neden önemli?
Entegrasyonun sürdürülebilir olması için işlemler manuel tetiklemeye bağlı bırakılmadı.
30 dakikada bir çalışan cron yapısı kuruldu ve flock kullanılarak bir önceki çalışma bitmeden yenisinin başlaması engellendi.
Bu özellikle yavaş API cevapları, batch işlemleri ve pazaryeri onay süreçleri olan sistemlerde önemlidir. Aksi halde aynı ürün için üst üste create/update denemeleri yapılabilir.
Bu tür entegrasyonlarda bakım neden gerekir?
Pazaryerleri kategori, attribute, endpoint, rate limit, panel davranışı ve onay süreçlerini zaman içinde değiştirebilir.
Bugün çalışan fiyat/stok akışı yarın yeni bir zorunlu alan, marka kuralı veya batch hata cevabı yüzünden kontrol isteyebilir.
Bu nedenle pazaryeri entegrasyonu tek seferlik kod yazma işi gibi değil, izleme ve gerektiğinde güncelleme isteyen teknik operasyon işi gibi ele alınmalıdır.
Sık sorulanlar
XML entegrasyonu ile API entegrasyonu aynı şey mi?+
Hayır. XML genelde belirli formatta veri aktarımıdır; API ise daha kontrollü ve çift yönlü işlem akışları sağlayabilir.
Pazaryeri entegrasyonu tek seferlik iş midir?+
Çoğu projede bakım gerekir. Pazaryerlerinin alanları, kuralları ve hata durumları zamanla değişebilir.