Bir tedarikçi dosyası gece boyunca gelir. Satırların çoğu normal görünür, birkaçı tanımlayıcıları eksiktir ve bir fiyat sütununda ondalık biçim değişmiştir. Dosyanın açılıp açılmadığını kontrol etmekle yetinen bir iş akışı, bir veri sorununu hiç tereddüt etmeden bir satış sorunu haline getirecektir.
Magento katalogları üzerinde çalışmak, içe aktarma işlemlerini bir üretim yazılımı gibi ele almamı sağladı. Önemli olan sonuç, katalogda güvenilir bir değişiklik yapılmış olması ve bir satıcı eksik bir ürünle ilgili soru sorduğunda neler olduğunu açıklayabilecek yeterli kanıtın bulunmasıdır.
Verilerin alınmasını, yayınlanmasından ayırmak
Kaynak dosya ile canlı katalog arasında bir ara depolama alanı olmasını tercih ederim. Bir dosyanın alınması, kaynak adı, varış zamanı, sağlama toplamı ve şema sürümünü içeren bir içe aktarma işlemi oluşturmalıdır. Bu, ekibe tedarikçiden indirme işlemini yeniden çalıştırmadan araştırma yapabilecekleri, tanımlanabilir bir nesne sağlar.
Bir sonraki aşamada değerler kanonik bir biçime dönüştürülür. Para birimi, ondalık ayırıcılar, ölçü birimleri ve stok durum etiketleri için açık kurallar belirlenmelidir. Boş bir stok alanı, “bilinmiyor”, “değişmemiş” veya “sıfır” gibi tanımlanmış bir anlama sahip olmalıdır. Bu anlamlar, hiçbir şekilde bir tür dönüştürme sonucu tesadüfen seçilmemelidir.
Ancak normalleştirme işleminden sonra, iş akışı önerilen değerleri mevcut ürün durumuyla karşılaştırmalıdır. Bu sayede, olağan dışı büyüklükte bir güncelleme uygulanmadan önce bir değişiklik raporu gösterilebilir.
Doğrulama işlemini iş sürecine uygun hale getirin
Sözdizimsel olarak geçerli bir sayı bile tehlikeli bir fiyat olabilir. Geçerli bir SKU bile yanlış varyantı tanımlayabilir. Bu nedenle, doğrulama kurallarım birkaç farklı konuyu kapsamaktadır.
- Kimlik: Bu satır tam olarak tek bir ürün veya varyantla eşleştirilebilir mi?
- Yapı: Zorunlu alanlar mevcut mu ve doğru şekilde girilmiş mi?
- Anlam: Para birimi, birimler ve stok değerleri algılanıyor mu?
- Değişiklik boyutu: Önerilen güncelleme, işletmenin beklediği aralık içinde mi?
- İlişkiler: Üst ürünler, kategoriler ve varyant özellikleri mevcut mu?
Bu kuralların da bir eylemle desteklenmesi gerekir. Geçersiz bir resim URL’si, önceki resmin yerinde kalmasına neden olabilir. Belirsiz bir ürün tanımlayıcısı, o satırın herhangi bir değişikliğe yol açmamasını sağlamalıdır. Şüpheli bir fiyat düşüşü, etkilenen ürün grubunun tamamının gözden geçirilmesini gerektirebilir.
Doğru iş birimini karantinaya alın
Tek bir hatalı satırı reddetmek, binlerce alakasız geçerli satırı reddetmekten daha iyi olabilir. Ancak satır düzeyinde yalıtım her zaman güvenli değildir. Yapılandırılabilir bir ürün ve varyantlarının birlikte taşınması gerekebilir; bu nedenle doğrulama birimi ürün ailesi olmalıdır.
Bir karantina kaydı, kaynak satırı, normalleştirilmiş değerleri, başarısız olan kuralı ve anlaşılır bir açıklamayı içermelidir. “Doğrulama başarısız” ifadesi yeni bir inceleme süreci başlatır. “Tedarikçi fiyatı 49,95 için para birimi eksik” ifadesi ise bir kişiye düzeltme görevi verir.
Aynı kural, eksik satırlar için de geçerlidir. Besleme sözleşmesinde bunun tam bir anlık görüntü olduğu açıkça belirtilmedikçe, bu satırların eksikliği ürünlerin otomatik olarak silinmesine yol açmamalıdır. Kısmi beslemeler ve artımlı beslemeler o kadar yaygındır ki, silme işleminin bilinçli bir şekilde gerçekleştirilmesi gerekir.
İkinci üretim için tasarım
Güvenli bir içe aktarma işlemi tekrarlanabilir. Ben sabit dış tanımlayıcılar kullanıyorum ve yazma işleminden önce normalleştirilmiş değerleri karşılaştırıyorum. Değiştirilmemiş bir kaynağın yeniden çalıştırılması, katalogda beklenmedik değişikliklere yol açmamalıdır; başarısız bir çalıştırma ise kaydedilen ilerleme noktasından devam etmelidir.
Güncellemeleri uyguladıktan sonra, mağaza arayüzü veya ürün API’si aracılığıyla bir örneği doğrularım. Veritabanına yazma işlemi, indeksleme, önbellekleme ve aşağı akış beslemelerinin bu değişiklikleri yakaladığını kanıtlamaz. Çalışma raporu, kabul edilen satırları, değiştirilen ürünleri, reddedilen grupları ve aşağı akışta hâlâ bekleyen işleri birbirinden ayırmalıdır.
Adobe Commerce, kendi içe aktarma iş akışındaki bir doğrulama adımını belgelemektedir. Ben bunu, daha geniş kapsamlı bir sürecin içindeki bir kontrol noktası olarak değerlendiriyorum. Tedarikçi sözleşmeleri, anomali tespiti ve kurtarma işlemleri hâlâ entegrasyon sürecinin bir parçasıdır.
İthalat raporunun yanıtlamasını istediğim operasyonel soru şudur: Hangi ürünler değişti, neden değişti ve kaynak hatalıysa önceki duruma nasıl geri dönebiliriz?
25 Eylül 2026 tarihinde güncellenmiştir.