SAP Business One, orta büyüklükteki işletmeler için en yaygın kullanılan ERP sistemlerinden biridir. Bunu WooCommerce’e bağlamak güçlü bir kombinasyon oluşturur: SAP’nin sağlam back-office yetenekleri ile WooCommerce’in esnek e-ticaret ön yüzü. Ancak entegrasyon basit değildir. İşte doğru yapma yöntemi. Baştan söyleyeyim: burada zorluk kod değil, iki sistemin dünyayı farklı görmesidir — ve o farkı hafife alan her proje bir yerde duvara toslar.

Neden SAP + WooCommerce?

SAP B1 kullanan ve e-ticaretlerini WooCommerce’e başlatan veya taşıyan şirketler genellikle şunlara ihtiyaç duyar:

  • Envanterin perakende ve online kanallar arasında gerçek zamanlı senkronizasyonu
  • WooCommerce’den gelen siparişlerin SAP’de otomatik olarak satış siparişi olarak oluşturulması
  • Müşteri verilerinin her iki sistemde birleştirilmesi
  • Ürün kataloğunun SAP’de yönetilmesi, WooCommerce’de görüntülenmesi
  • Fiyatlandırma kurallarının (hacim indirimleri, müşteriye özel) SAP tarafından kontrol edilmesi

Bu listeye bakınca aklında tutmanı istediğim tek şey şu: SAP burada patron. Şirket zaten SAP’ye milyonluk yatırım yapmış ve iş süreçlerini oraya gömmüş durumda. WooCommerce güzel bir vitrin, ama muhasebenin, stoğun ve fiyatın gerçeği SAP’de yaşıyor. Bu hiyerarşiyi kabul edersen mimarinin yarısı kendiliğinden çözülür.

Mimari: Middleware Yaklaşımı

WooCommerce’i asla doğrudan SAP’nin veritabanına bağlama. SAP B1, uygun entegrasyon noktası olan bir Service Layer (REST benzeri API) sunar.

WooCommerce REST API <--> Middleware (Node.js/Python) <--> SAP Service Layer
                              Message Queue
                              Error Handling
                              & Audit Log

Middleware her iki sistem arasında durur ve şunları yönetir:

  • Veri dönüşümü (SAP’nin alan adlarından WooCommerce şemasına)
  • Oran sınırlama ve toplu işleme
  • Hata kurtarma ve yeniden deneme mantığı
  • Loglama ve izleme

“Doğrudan DB’ye bağlanma” uyarısını kalın harflerle tekrarlıyorum, çünkü kariyerimde bu kestirmeyi seçip verisini bozmuş birden fazla ekip gördüm. SAP’nin iş mantığı uygulama katmanında yaşıyor; DB’ye elle yazdığın an o mantığı baypas edersin ve muhasebe bir gün açığı fark edip kapına dayanır.

SAP Service Layer Temelleri

// Authenticate with SAP B1 Service Layer
const login = await fetch('https://sap-server:50000/b1s/v1/Login', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    CompanyDB: 'YOUR_DB',
    UserName: 'manager',
    Password: 'password'
  })
});

// Session cookie for subsequent requests
const sessionId = login.headers.get('set-cookie');

// Fetch items (products)
const items = await fetch('https://sap-server:50000/b1s/v1/Items?$select=ItemCode,ItemName,QuantityOnStock&$filter=SalesItem eq \'Y\'', {
  headers: { 'Cookie': sessionId }
});

Veri Haritalama

Çoğu entegrasyonun bozulduğu yer burasıdır. SAP ve WooCommerce temelde farklı veri modellerine sahiptir. Bence bir projede en çok zaman ayırman gereken tablo tam da aşağıdakiler; kod değil, bu eşleme kararları belirler işin kaderini.

Ürünler

SAP B1 AlanıWooCommerce AlanıNotlar
ItemCodeskuBirincil tanımlayıcı
ItemNamename
QuantityOnStockstock_quantityDepolar arası toplam
ItemPrices (Price List)regular_priceSAP’de çoklu fiyat listeleri
SalesItem (Y/N)statusY = yayınla, N = taslak
Pictureimages[0].srcSAP yol saklar, URL dönüşümü gerekir
ItemGroupcategoriesSAP gruplarını WC kategorilerine eşle

Siparişler

WooCommerce AlanıSAP B1 ObjesiNotlar
order.idDocEntry (ref)WC sipariş ID’sini SAP’nin açıklamalarında sakla
line_itemsDocumentLinesSKU’ya göre eşle
billing addressAddressExtensionBillTo adresi
shipping addressAddressExtensionShipTo adresi
customer emailBusinessPartnerEşleştir veya BP oluştur
payment_methodPayment TermsWC gateway’i SAP şartlarına eşle

Müşteriler

WooCommerce AlanıSAP B1 AlanıNotlar
emailEmailAddressBenzersiz tanımlayıcı
first_name + last_nameCardNameBirleştir
billing.companyCardNameB2B ise
billing.address_1AddressesSAP’de adres objesi
CardCodeSAP’de otomatik oluşturulan

Senkronizasyon Akışları

Ürün Senkronizasyonu (SAP → WooCommerce)

Sıklık: Her 5 dakikada bir veya değişiklik webhook’unda

  • Son senkronizasyondan beri değişen öğeler için SAP’yi sorgula
  • Her öğe için SKU’nun WooCommerce’de var olup olmadığını kontrol et
  • Varsa: stok, fiyat ve durumu güncelle
  • Yeniyse: WooCommerce’de tam detaylarla ürün oluştur
  • Senkronizasyon sonucunu logla

Kritik değerlendirme: SAP’nin fiyat listeleri müşteri grubu özelinde fiyatlandırmayı destekler. SAP fiyat listelerini WooCommerce’in rol tabanlı fiyatlandırma plugin’lerine veya özel meta alanlarına eşle. Açık konuşayım: B2B satan bir müşteride en çok kan kaybettiren yer burasıdır. SAP tarafında beş ayrı fiyat listesi varsa, bunun WooCommerce’de nasıl görüneceğini gün bir’de karara bağla; sonradan eklenen fiyat mantığı hep yara izi bırakır.

Sipariş Senkronizasyonu (WooCommerce → SAP)

Tetikleyici: order.created üzerinde WooCommerce webhook’u

  • Webhook payload’ını al
  • SAP’de BusinessPartner bul veya oluştur (e-posta ile eşleştir)
  • Satır öğelerini SAP ItemCode’larına eşle (SKU’ya göre)
  • SAP’de Sales Order oluştur
  • SAP DocEntry’sini WooCommerce sipariş meta’sında sakla
  • WooCommerce sipariş notunu güncelle: “SAP’ye senkronize edildi: SO-{DocEntry}”

Envanter Senkronizasyonu (SAP → WooCommerce)

Tetikleyici: SAP UDF veya eklenti stok değişikliğinde tetiklenir, veya her 60 saniyede yokla

  • SAP’den stok seviyelerini al (tüm depolar veya belirli olanlar)
  • Satışa uygun miktarı hesapla: OnHand - Committed
  • Toplu endpoint üzerinden WooCommerce’i güncelle
  • Çoklu depo işlemi: topla veya belirli depo seç

Şu OnHand - Committed hesabını gözden kaçırma; bence envanter entegrasyonlarının en sinsi hatası burada saklı. Ham stok değil, satılabilir stok gösterirsen, aynı ürünü iki kez satmaktan kurtulursun — ve overselling, bir e-ticaret müşterisini en hızlı sinirlendiren şeydir.

Hata Yönetimi

SAP entegrasyonları özellikle hata eğilimlidir çünkü:

  • SAP Service Layer oturumları 30 dakika hareketsizlikten sonra sona erer
  • SAP alan doğrulaması katıdır (yanlış UoM, eksik zorunlu alanlar = reddetme)
  • Middleware ve SAP sunucusu arasındaki ağ güvenilmez olabilir

Yeniden deneme stratejisi:

async function sapRequest(endpoint, options, retries = 3) {
  for (let i = 0; i < retries; i++) {
    try {
      await ensureSession(); // Re-login if session expired
      const response = await fetch(`${SAP_URL}${endpoint}`, options);
      if (response.status === 401) {
        await login(); // Session expired
        continue;
      }
      return await response.json();
    } catch (error) {
      if (i === retries - 1) throw error;
      await sleep(Math.pow(2, i) * 1000);
    }
  }
}

Bu kodun kalbi şu 401 kontrolü. SAP oturumun her an sessizce ölebilir, ve iyi yazılmış bir bağlayıcı bunu bir felaket değil, sıradan bir olay gibi karşılar: yeniden giriş yap, işi tekrarla, devam et. Ben olsam bu yeniden deneme sarmalayıcısını yazmadan tek bir SAP çağrısı bile yapmazdım.

Üretimden Öğrenilenler

  • Her zaman SAP’nin Service Layer’ını kullan, asla doğrudan DB sorguları yapma. SAP’nin iş mantığı uygulama katmanında yaşar. Bunu atlamak verilerini bozacaktır.
  • SAP’nin oturum yönetimini dikkatli bir şekilde ele al. Service Layer’ın eş zamanlı oturum sınırı vardır. Oturumları havuzla ve yeniden kullan.
  • SAP’nin üretime benzer verilerle test et. SAP demo veritabanları basit yapılara sahiptir. Gerçek müşteri SAP kurulumları, naif entegrasyonları bozan özel alanlar, kullanıcı tanımlı tablolar ve onay iş akışlarına sahiptir.
  • SAP yükseltmeleri için plan yap. SAP B1 güncellemeleri Service Layer davranışını değiştirebilir. Entegrasyonunu sürüm kilidine al ve her SAP güncellemesinden sonra test et.
  • SAP lisans kullanımını izle. Her Service Layer oturumu bir SAP lisansı tüketir. Müşterinin lisansının entegrasyon oturumlarını desteklediğini onayla.

Ben Olsam: Canlıya Geçmeden Önceki Sıra

Bir SAP entegrasyonunu bir hafta sonunda “hadi açalım” diye canlıya almak, benim gördüğüm en pahalı hatalardan biri. Ben olsam şu sırayı sabırla izlerdim — sıkıcıdır, ama sıkıcı olması tam olarak istediğin şey:

  1. Müşterinin gerçek SAP kopyasıyla başla. Demo veritabanı yalan söyler; asıl özel alanları, UDF’leri ve onay akışlarını ancak gerçek kurulumda görürsün.
  2. Önce tek yönü, tek varlığı çalıştır. Sadece ürün senkronizasyonunu (SAP → WooCommerce) doğrula. Bir yön sağlam oturmadan siparişe geçme.
  3. Eşleme tablolarını müşteriye onaylat. Fiyat listesi ve depo kararları teknik değil, ticari kararlardır; bunları geliştirici tek başına vermemeli.
  4. Kuru çalıştır: yaz ama işleme. Sipariş akışını SAP’ye gerçek yazma yapmadan bir gün boyunca logla, çıktıyı muhasebeyle karşılaştır.
  5. Küçük bir kanaldan aç. Tüm katalog yerine birkaç SKU ile canlıya çık, bir hafta izle, sonra ölçekle.

Bu sıralamanın hiçbir adımı heyecan verici değil. Ama gece 3’te overselling alarmı yerine sakin bir go-live istiyorsan, heyecan zaten aradığın şey değil.

Sonuç

SAP-WooCommerce entegrasyonu bir middleware problemidir, plugin problemi değil. Hazır bağlayıcılar mevcuttur ancak özel alanlar, çoklu fiyat listeleri ve depo konfigürasyonları olan gerçek SAP implementasyonlarının karmaşıklığını nadiren ele alırlar. Uygun middleware mimarisine, kapsamlı veri haritalamasına ve sağlam hata yönetimine yatırım yap. Getiri — otomatik sipariş akışı, gerçek zamanlı envanter ve birleşik müşteri verisi — mühendislik yatırımına değer. Ben olsam bu işe kestirme arayan değil, sıkıcı ama sağlam olanı seçen bir gözle girerdim; SAP dünyasında kahramanlık değil, öngörülebilirlik kazandırır.

Bir yanıt yazın

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

Close Search Window