ERP–E-Ticaret Entegrasyonu: Stok ve Sipariş Senkronizasyonu

ERP–e-ticaret entegrasyonu neden bu kadar sık ağrıyor?

Çünkü iki sistem iki farklı dünyada yaşar: ERP, tutarlılığı ve toplu işlemeyi sever; e-ticaret, anlıklığı ve kesintisizliği. Entegrasyon mimarisinin görevi bu iki ritmi, veri kaybetmeden ve müşteri deneyimini bozmadan eşleştirmektir. Bu yazı; stok, fiyat ve sipariş akışları için kanıtlanmış desenleri ve en sık yapılan hataları derler.

Akış bazlı gereksinim haritası

Sipariş akışı: kayıp yok, çift kayıt yok

Entegrasyonun en kritik hattı sipariştir; iki hata affedilmez: siparişin kaybolması ve iki kez işlenmesi. Çözüm iki desenin birleşimidir. Outbox: sipariş, e-ticaret veritabanına yazılırken aynı işlem (transaction) içinde bir outbox tablosuna da yazılır; ayrı bir yayıncı bu tabloyu okuyup kuyruğa basar — böylece 'DB'ye yazıldı ama mesaj gitmedi' aralığı kapanır. Idempotency: ERP tarafındaki tüketici, sipariş numarasını anahtar kabul eder; aynı mesaj ikinci kez gelirse yeni kayıt açmaz, mevcut sonucu döner. Bu iki desen kurulduğunda yeniden deneme (retry) güvenli hale gelir — ve güvenli retry, entegrasyonun sigortasıdır.

Stok: delta yayını + tam uzlaştırma çifti

Stokta iki mekanizma birlikte çalışmalıdır. Sürekli hat: ERP'deki hareketlerin delta/olay olarak yayınlanması ve e-ticaretin dakikalar içinde güncellenmesi. Emniyet hattı: günde en az bir tam uzlaştırma (reconciliation) — iki sistemin stok görüntüsünün karşılaştırılıp farkların raporlanması ve düzeltilmesi. Delta hattı kaçınılmaz olarak olay kaçırır (ağ, sıra, yeniden başlatma); uzlaştırma olmadan bu kaçaklar birikir ve 'stokta görünüyordu' iadelerine dönüşür. Kritik eşik davranışı da tasarlanmalıdır: son birkaç adede düşen üründe satışın durdurulması veya rezervasyon modeli, aşırı satışın (oversell) maliyetinden ucuzdur.

Ritim uyumsuzluğu: ERP'nin penceresi, sitenin 7/24'ü

ERP'lerin bakım pencereleri, toplu işlem saatleri ve kapasite sınırları vardır; e-ticaret ise gece kampanyasında zirve yapar. Ara katman (kuyruk + tampon depo) bu uyumsuzluğun amortisörüdür: site, ERP'ye doğrudan senkron bağımlı olmamalı; sipariş kuyruğu ERP kapalıyken birikmeli, açıldığında kontrollü hızda boşalmalıdır. Aynı ilke tersine de geçerlidir: ERP'den gelen dev toplu güncellemeler, storefront'u boğmadan kademeli uygulanmalıdır (hız sınırı, parça parça işleme).

Hata yönetimi: ölü mektup, alarm ve tekrar oynatma

Entegrasyonda hata istisna değil, işletme koşuludur. Asgari set: işlenemeyen mesajların ölü mektup kuyruğuna (DLQ) düşmesi; DLQ'nun boyutunun alarma bağlanması; mesajların içerikleriyle birlikte incelenebilmesi ve düzeltme sonrası güvenle tekrar oynatılabilmesi (replay). Tekrar oynatma, idempotency kurulmuşsa risksizdir — kurulmamışsa felakettir; desenlerin sırası bu yüzden önemlidir. Tüm akışlarda korelasyon kimliği (sipariş no, mesaj id) uçtan uca loglanmalı; 'bu sipariş nerede takıldı?' sorusu dakikalar içinde cevaplanabilmelidir.

Sözleşme ve sürümleme: entegrasyonun uzun ömrü

ERP tarafı da e-ticaret tarafı da yaşayan sistemlerdir; alan ekler, tip değiştirir. Entegrasyon sözleşmesi (şema) açıkça sürümlenmeli, geriye uyumluluk kuralı yazılı olmalıdır: yeni alan eklemek serbest, alan silmek/tip değiştirmek yeni sürüm ister. Şema doğrulaması tüketici tarafında zorunlu olmalı; 'sessizce yanlış parse etme', 'gürültüyle reddetme'den daha tehlikelidir.

İş etkisi: entegrasyon, müşteri vaadinizin altyapısıdır

'Stokta var' etiketi, teslim tarihi sözü ve sipariş durumu bildirimi — müşteriye verilen her vaat, bu entegrasyonun doğruluğuna yaslanır. Aşırı satış iade ve itibar maliyeti üretir; kayıp sipariş doğrudan ciro kaybıdır; manuel düzeltme operasyon ekibini büyütür. Doğru desenlerle kurulan entegrasyon ise ölçülebilir kazanım verir: uzlaştırma farklarının sıfıra yaklaşması, DLQ'nun boş kalması ve operasyon müdahalesinin istisnalaşması — bunlar hem mühendislik hem yönetim panosunun metrikleridir.

Sık sorulan sorular

Gerçek zamanlı mı, toplu mu senkronize etmeliyim?

Akış bazında karar verin: sipariş ve kritik stok anlık-yakın ister; fiyat ve ana veri planlı toplu ile daha sağlıklıdır. Tek cevap yoktur; tablo yukarıdadır.

ERP API'si zayıfsa ne yapmalı?

Ara katman güçlendirilir: dosya/staging tablosu tabanlı alışveriş bile, kuyruk + idempotency + uzlaştırma ile güvenilir hale getirilebilir. Desenler taşıyıcıdan bağımsızdır.

iPaaS ürünü mü, özel geliştirme mi?

Az sayıda standart akışta iPaaS hız kazandırır; karmaşık iş kuralları ve yüksek hacimde özel katman kontrolü geri verir. Karışım da meşrudur: taşıma iPaaS'te, iş kuralı sizde.

Senkronizasyon gecikmesini müşteriye nasıl yansıtmalıyım?

Dürüst tasarımla: son birimlerde 'sınırlı stok' gösterimi, sipariş sonrası 'onaylandı' ayrımı ve durum bildirimleri, gecikmeyi deneyim sorununa dönüşmeden yönetir.

Entegrasyon kontrol listesi

1. Akış bazlı tazelik ihtiyaçları ve desenler tablolandı

2. Sipariş hattında outbox + idempotent tüketici kurulu

3. Stokta delta hattı + günlük tam uzlaştırma çalışıyor

4. Kuyruk tamponu ERP pencerelerini emiyor; hız sınırları tanımlı

5. DLQ, alarm ve güvenli replay süreci mevcut

6. Korelasyon kimliği uçtan uca loglanıyor

7. Şema sürümleme ve geriye uyumluluk kuralı yazılı

SSH Yazılım, ERP–e-ticaret entegrasyonlarını desen temelli ve ölçülebilir güvenilirlikle kurar. Sipariş ve stok hatlarınızı birlikte sağlamlaştıralım.