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 |
|---|---|---|
| ItemCode | sku | Birincil tanımlayıcı |
| ItemName | name | |
| QuantityOnStock | stock_quantity | Depolar arası toplam |
| ItemPrices (Price List) | regular_price | SAP’de çoklu fiyat listeleri |
| SalesItem (Y/N) | status | Y = yayınla, N = taslak |
| Picture | images[0].src | SAP yol saklar, URL dönüşümü gerekir |
| ItemGroup | categories | SAP gruplarını WC kategorilerine eşle |
Siparişler
| WooCommerce Alanı | SAP B1 Objesi | Notlar |
|---|---|---|
| order.id | DocEntry (ref) | WC sipariş ID’sini SAP’nin açıklamalarında sakla |
| line_items | DocumentLines | SKU’ya göre eşle |
| billing address | AddressExtension | BillTo adresi |
| shipping address | AddressExtension | ShipTo adresi |
| customer email | BusinessPartner | Eşleştir veya BP oluştur |
| payment_method | Payment Terms | WC gateway’i SAP şartlarına eşle |
Müşteriler
| WooCommerce Alanı | SAP B1 Alanı | Notlar |
|---|---|---|
| EmailAddress | Benzersiz tanımlayıcı | |
| first_name + last_name | CardName | Birleştir |
| billing.company | CardName | B2B ise |
| billing.address_1 | Addresses | SAP’de adres objesi |
| — | CardCode | SAP’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:
- 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.
- Ö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.
- 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.
- 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.
- 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.
Last modified: Ağustos 2, 2026
United States / English
Slovensko / Slovenčina
Canada / Français
Türkiye / Türkçe