Bir tedarikçi dosyası gece boyunca ulaşır. Satırların çoğu normal görünür, birkaçı tanımlayıcı içermez ve bir fiyat sütunundaki ondalık biçim değişmiştir. Dosyanın açılıp açılmadığını kontrol etmekle yetinen bir iş akışı, veri sorununu hiç tereddüt etmeden bir müşteri deneyimi sorununa dönüştürür.
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 olmasıdır; bu sayede bir satıcı eksik bir ürün hakkında soru sorduğunda, ne olduğunu açıklayacak yeterli kanıt bulunmalı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, standart bir temsil biçimine 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 zaman bir tür dönüştürme işlemi sonucunda tesadüfen seçilmemelidir.
Ancak normalleştirme işlemi tamamlandıktan 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, birim ve stok durumu değerleri tanınır mı?
- Boyutu değiştir: Önerilen güncelleme, işletmenin beklediği aralık içinde mi?
- İlişkiler: Ana ürünler, kategoriler ve varyant özellikleri mevcut mu?
Bu kuralların da bir eyleme dönüştürülmesi 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 incelenmesini 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” mesajı yeni bir inceleme başlatır. “Tedarikçi fiyatı 49,95 için para birimi eksik” mesajı 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 eksik olması ü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şlemi kasıtlı olarak gerçekleştirilmelidir.
İkinci üretim için tasarım
Güvenli bir içe aktarma işlemi tekrarlanabilir. Ben sabit harici 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 oynatılması, katalogda beklenmedik değişikliklere yol açmamalıdır; başarısız olan 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 bir yazma işlemi, indeksleme, önbellekleme ve aşağı akış beslemelerinin bu değişiklikleri yakaladığını kanıtlamaz. Çalıştırma 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 yerel içe aktarma iş akışı. Bunu, daha geniş kapsamlı bir sürecin içindeki tek bir kontrol noktası olarak değerlendiriyorum. Tedarikçi sözleşmeleri, anormallik tespiti ve kurtarma işlemleri hâlâ entegrasyon sürecinin bir parçasıdır.
İthalat raporunun yanıtlamasını istediğim operasyonel soru basit: Hangi ürünler değişti, neden değişti ve kaynak yanlışsa önceki duruma nasıl geri dönebiliriz?
25 Eylül 2026 tarihinde güncellenmiştir.