🇬🇧 English: Read this in English →

Envanter senkronizasyonu, WooCommerce-ERP entegrasyonundaki en kritik veri akışıdır. Yanlış yaparsan ürünleri fazla satarsın, müşterileri hayal kırıklığına uğratırsın ve güveni sarsarsın. Doğru yaparsan mağazan gerçeği yansıtır — her zaman. Açık konuşayım: bu tek akış, bir ERP entegrasyonunun geri kalan her şeyinden daha çok geceyi mahvetme potansiyeli taşır.

Toplu senkronizasyon sorunu

Birçok WooCommerce mağazası cron tabanlı yaklaşımla başlar: her 15 dakikada bir, ERP’den envanteri çek ve WooCommerce’i güncelle. Bu işe yarar, ta ki yaramayıncaya kadar.

Düşün: ERP’in 10:01’de 50 birimlik bir sevkiyat alıyor. Senkronizasyonun 10:00 ve 10:15’te çalışıyor. 14 dakika boyunca, deponda rafta 50 birim varken web siten “Stokta Yok” gösteriyor. Bu kayıp gelir demektir.

Tersi daha kötü: bir müşteri 10:02’de son birimi sipariş ediyor, ama 10:15’teki senkronizasyon henüz ERP sayısını azaltmadı. Başka bir müşteri 10:10’da aynı “son” birimi sipariş ediyor. Fazla satış yapmış oldun.

Gerçek zamanlı senkronizasyon her iki senaryoyu da ortadan kaldırır.

Mimari seçenekleri

Seçenek 1: Webhook + Queue

ERP (stok değişikliği) --> Webhook --> Message Queue --> Sync Worker --> WooCommerce API
WooCommerce (sipariş)  --> Webhook --> Message Queue --> Sync Worker --> ERP API

Message queue (RabbitMQ, AWS SQS veya Redis), webhook alıcısını işleme mantığından ayırır. WooCommerce geçici olarak çöktüyse, queue güncellemeleri geri dönene kadar tutar.

Seçenek 2: Change Data Capture (CDC)

İlişkisel veritabanı destekli ERP’ler için, CDC araçları (Debezium, AWS DMS) envanter tablosundaki değişiklikleri izler ve güncellemeleri WooCommerce’e gönderir. Bu, değişikliklerin nasıl yapıldığına bakılmaksızın — API, manuel giriş veya toplu içe aktarma — yakalar.

Seçenek 3: Delta tespiti ile polling

ERP’in webhook veya CDC desteklemiyorsa, kısa aralıklarla (her 60 saniyede) yokla ama sadece son yoklamadan beri değişen kayıtları işle. Çoğu ERP’de envanter kayıtlarında modified_at zaman damgası bulunur.

// Delta polling pattern
async function syncInventory() {
  const lastSync = await getLastSyncTimestamp();
  const changes = await erp.getInventoryChanges({ since: lastSync });

  for (const item of changes) {
    await woocommerce.updateProduct(item.sku, {
      stock_quantity: item.quantity,
      stock_status: item.quantity > 0 ? 'instock' : 'outofstock'
    });
  }

  await setLastSyncTimestamp(new Date());
}

Çakışma çözümü

WooCommerce ve ERP stok seviyelerinde anlaşmazlığa düştüğünde ne olur?

Kural 1: ERP mutlak stok seviyeleri için gerçeğin kaynağıdır. ERP depoda fiziksel olarak ne olduğunu bilir. WooCommerce çevrimiçi olarak neyin sipariş edildiğini bilir. ERP kazanır.

Kural 2: WooCommerce azaltmaları olaylardır, durumlar değil. Bir WooCommerce siparişi verildiğinde, ERP’ye “X kadar azalt” mesajı gönder — “stoğu Y’ye ayarla” değil. Bu yarış koşullarını önler.

Kural 3: Senkronizasyonun bekleyen bir siparişi üzerine yazmasına asla izin verme. Bir WooCommerce siparişi “işleniyor” durumundaysa ve henüz ERP’ye gönderilmediyse, ERP’nin stok sayısı bunu hesaba katmaz. Senkronizasyonun bekleyen siparişleri ERP sayısından çıkarmalıdır.

Görüntülenen Stok = ERP Stoğu - Henüz ERP'de Olmayan Bekleyen WooCommerce Siparişleri

Ürün varyantlarını yönetme

WooCommerce varyasyonları ve ERP SKU’ları genellikle farklı yapılara sahiptir. Bir WooCommerce değişken ürün “T-Shirt”ün varyasyonları (Küçük/Kırmızı, Orta/Mavi, vb.) vardır ve her birinin kendi stoğu bulunur. ERP’in bunları düz SKU’lar olarak saklayabilir.

Eşleme tablosu:

WooCommerce ERP
Product ID: 1234 (parent)
Variation ID: 1235 (S/Red) SKU: TSH-S-RED
Variation ID: 1236 (M/Blue) SKU: TSH-M-BLU

Entegrasyon katmanında bir SKU eşleme tablosu tut. Asla ürün adlarını eşleştirmeye güvenme — bunlar değişir. SKU’lar senin stabil tanımlayıcın.

Hata yönetimi

Envanter senkronizasyon hataları iş açısından kritiktir. Bu koruma önlemlerini oluştur:

  • Dead letter queue: Başarısız senkronizasyon mesajları manuel inceleme için ayrı bir queue’ya gider
  • Uyarı: Senkronizasyon başarısız olduğunda veya stok tutarsızlığı eşiği aştığında Slack/email bildirimi
  • Üstel geri çekilme ile yeniden deneme: 1s, 2s, 4s, 8s, sonra dead letter
  • Circuit breaker: ERP çöktüyse, onu dövmeyi bırak. Güncellemeleri queue’ya al ve kurtulduğunda işle
  • Audit log: Her stok değişikliği — kaynak, eski değer, yeni değer, zaman damgası

Idempotency: aynı olayı iki kez işlemek

Şimdi çoğu rehberin atladığı ama üretimde seni en sinsi şekilde ısıran konuya gelelim: aynı olayın iki kez gelmesi. Webhook’lar ve message queue’lar “en az bir kez teslimat” garantisi verir — yani bir mesaj bazen iki kez teslim edilir. Ağ bir ACK’yi kaçırır, kaynak sistem güvenli tarafta kalmak için tekrar gönderir, ve senin sync worker’ın aynı “5 birim azalt” olayını iki kez işler. Kural 2’yi (azaltmalar olaydır, durum değil) doğru uyguladıysan, bu tam da o olayı tehlikeli kılan şeydir — çünkü olaylar toplanır. İki kez işlenen bir azaltma, stoğunu sessizce 5 birim yanlışa çeker, ve bunu ancak fiziksel sayımda fark edersin.

İlaç idempotency: her olaya benzersiz bir kimlik ver (kaynak sistemin olay ID’si ya da sipariş ID’si + satır kalemi) ve işlenmiş kimlikleri bir yerde tut. Bir olay gelince önce “bunu daha önce gördüm mü” diye bak; gördüysen sessizce at. Bu, kodun birkaç satırı ama envanter doğruluğunun bel kemiği. Ben olsam bunu en baştan yazardım, “sonra eklerim” listesine değil — çünkü bu hatanın belirtisi haftalar sonra, kimsenin sebebini hatırlamadığı bir stok kaymasıdır ve o noktada ayıklaması on kat pahalıdır.

WooCommerce API değerlendirmeleri

WooCommerce’in REST API’sinin göz önünde bulundurulması gereken oran limitleri ve performans özellikleri vardır:

  • Batch endpoint: POST /wp-json/wc/v3/products/batch istek başına 100 ürüne kadar günceller
  • Varyasyon güncellemeleri URL’de ana ürün ID’sini gerektirir
  • Stok durumu stock_quantity ile birlikte güncellenmelidir — bunlar bağımsız alanlardır
  • Webhook güvenilirliği: Sunucun 5 saniye içinde 200 ile yanıt vermezse WooCommerce webhook’ları sessizce başarısız olabilir

Senkronizasyonunu izleme

Bu metrikleri takip et:

Metrik Hedef Uyarı eşiği
Senkronizasyon gecikmesi < 30 saniye > 2 dakika
Başarısız senkronizasyon / saat 0 > 5
Stok tutarsızlığı 0 öğe > 10 öğe
Queue derinliği < 100 > 1,000

Sonuç

Gerçek zamanlı envanter senkronizasyonu ciddi WooCommerce mağazaları için isteğe bağlı değildir. Seçeceğin mimari ERP’inin yeteneklerine bağlıdır, ancak ilkeler evrenseldir: ERP’yi gerçeğin kaynağı olarak değerlendir, azaltmaları olay olarak ele al, aynı olayı iki kez işlemeye karşı idempotency kur, sağlam hata yönetimi oluştur ve her şeyi izle. ERP’in destekliyorsa webhook odaklı senkronizasyonla başla; desteklemiyorsa delta tespiti ile yüksek frekanslı yoklamaya geri dön. Otuz yıldır aynı gerçeği görüyorum: veriyi doğru yerde, doğru anda, tek bir gerçeğin kaynağından besleyen sistem kazanıyor — gerisi süsleme.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Close Search Window