SAP Commerce ve S/4HANA Entegrasyonu: Akışlar ve Mimari

Commerce ↔ S/4HANA entegrasyonunda başarıyı ne belirler?

Teknoloji seçiminden önce akış sahipliği: hangi verinin efendisi (master) hangi sistem, hangi akış gerçek zamanlı olmak zorunda, hangisi gecikmeye toleranslı? Bu üç sorunun cevabı yazılmadan yapılan entegrasyon, iki güçlü sistemi birbirine kelepçeler — ve kampanya günü Commerce, ERP'nin hızına mahkûm olur. Bu yazı, ERP entegrasyon serimizdeki genel desenleri SAP-SAP hattının özeline indirir: akış akış mimari, senkron/asenkron kararları ve uzlaştırma.

Akış haritası: kim efendi, hangi yönde, hangi hızda?

Fiyat mimarisi: replikasyon mu, canlı sorgu mu?

B2B'nin en çetin sorusu budur, çünkü müşteriye özel fiyat S/4'ün koşul tekniğinde (condition) yaşar. İki işleyen model vardır. Replikasyon: fiyat listeleri ve koşullar periyodik olarak Commerce'e taşınır — katalog gezinme ve arama hızlıdır, kampanya trafiğinde ERP'ye yük binmez; bedeli, karmaşık koşul mantığının sadeleştirilerek taşınması ve tazelik penceresidir. Canlı sorgu: kritik anlarda (sepet/checkout) fiyat S/4'ten anlık alınır — doğruluk tamdır; bedeli, ERP'ye trafik bağımlılığı ve gecikmedir. Pratik standardımız hibrittir: listeleme replikasyonla, sepet-checkout canlı sorguyla (önbellek + kısa TTL + dayanıklılık desenleriyle korunmuş) — ve hangi fiyat farkının 'kabul edilebilir' olduğu iş tarafıyla yazılı anlaşmaya bağlanır.

Stok ve ATP: kampanya gününün sınavı

ATP (available-to-promise) sorgusu doğruluğun altın kaynağıdır ama her ürün kartında ERP'ye gitmek, yüksek trafikte intihar reçetesidir. Katmanlı model: listelerde Commerce'teki tamponlanmış stok durumu (var/az/yok seviyesinde, kısa TTL); ürün detayında önbellekli sayı; sepete ekleme ve checkout'ta gerçek ATP kontrolü; kampanya ürünlerinde ise flash sale yazımızdaki rezervasyon deseni (Commerce tarafında atomik düşüm, S/4'e asenkron bildirim + uzlaştırma). Kritik kural: 'stok yok' yalancı negatifi satış kaybıdır, 'stok var' yalancı pozitifi iptal maliyetidir — hangi hatanın hangi üründe daha ucuz olduğu iş kararıdır ve tampon stratejisi buna göre ayarlanır.

Sipariş akışı: asenkron, idempotent, izlenebilir

Sipariş hattının kuralı ERP entegrasyon yazımızdan değişmeden gelir: Commerce siparişi kabul eder ve kuyruğa yazar (outbox ile atomik); S/4'e iletim asenkron tüketiciyle yapılır; iletim idempotent'tir (Commerce sipariş numarası iş anahtarıdır — S/4 tarafında çift kayıt üretilmez); hata sınıfları ayrılır (geçici → backoff'lu retry; veri hatası → DLQ + operasyon ekranı); ve her siparişin entegrasyon durumu sorgulanabilir (alındı → ERP'ye iletildi → ERP onayı → faturalandı). S/4 tarafındaki karşılıklar (IDoc/servis arayüzleri hangi biçim seçildiyse) sözleşme olarak sürümlenir. Bu kurgunun ticari değeri nettir: ERP bakım penceresi veya yavaşlığı, sipariş almayı asla durdurmaz.

Teknik kanal seçimi ve orta katman sorusu

SAP dünyasında kanal seçenekleri bilinir: IDoc tabanlı klasik akışlar, OData/servis arayüzleri ve olay tabanlı yaklaşımlar; araya orta katman (SAP'nin entegrasyon süiti veya kurumun mevcut ESB/iPaaS'ı) konup konmayacağı ise mimari karardır. Pratik kuralımız: nokta-noktayı iki sistemle sınırlı tutun — Commerce ↔ S/4 hattı doğrudan kurulabilir; ama aynı veriyi üçüncü-dördüncü sistemler de tüketiyorsa (WMS, BI, pazaryerleri), olay/orta katman mimarisi tekrarlanan nokta-nokta hatların toplam maliyetinden ucuzlar. Karar tabloya dökülür: tüketici sayısı, dönüşüm ihtiyacı, izleme gereksinimi.

Uzlaştırma ve ortam disiplini

Dağıtık tutarlılık yazımızın sigortası burada zorunlu ekipmandır: gün sonu sipariş sayısı/tutar karşılaştırması, askıda kalan (Commerce'te var, S/4'te yok) kayıtların otomatik raporu ve düzeltme runbook'u. Ortam disiplini de entegrasyonun parçasıdır: Commerce test ortamları S/4 test sistemine (gerçekçi ana veriyle) bağlı olmalıdır — 'entegrasyonu canlıda test eden' proje, go-live haftasını olay yönetimiyle geçirir. Test verisi yenileme ritmi ve maskelenmiş üretim kopyası politikası (KVKK uyumlu) baştan kurulur.

Sık sorulan sorular

ECC'den S/4'e geçiş sürecindeyiz; Commerce entegrasyonu nasıl etkilenir?

Akış sahipliği haritası aynı kalır; kanal ve arayüz karşılıkları değişebilir. Doğru pratik, Commerce tarafında entegrasyonu sözleşme arkasına almaktır (anticorruption katmanı) — böylece ERP geçişi, Commerce iç modeline dokunmadan arayüz uyarlamasıyla yönetilir.

Gerçek zamanlı stok her yerde gösterilemez mi?

Teknik olarak mümkün, ekonomik olarak anlamsızdır: listeleme trafiğinin tamamını ERP'ye taşımak, en pahalı sisteminizi en ucuz soruya harcamaktır. Katmanlı model, doğruluğu kritik ana taşır.

Müşteriye özel fiyatların Commerce'te önbelleklenmesi güvenli mi?

Kullanıcı/hesap bazlı anahtarlama ve yetki filtresiyle evet — önbellek yazımızdaki kişisel veri kuralları burada fiyat gizliliği için de geçerlidir: bir müşterinin özel fiyatı, ortak anahtarda asla yaşamaz.

Entegrasyon testleri nasıl otomatikleştirilir?

Sözleşme testleri (arayüz şemaları) + kayıttan oynatma (örnek IDoc/servis yükleri) + uçtan uca smoke senaryoları (sipariş → ERP → durum dönüşü). CI'da koşan bu set, 'ERP tarafı değişti, kimse haber vermedi' sürprizlerini yakalar.

Commerce ↔ S/4 kontrol listesi

1. Akış sahipliği haritası (efendi/yön/hız) iş onaylı

2. Fiyat modeli seçildi: hibrit replikasyon + kritik anda canlı sorgu

3. Stok katmanları ve yalancı pozitif/negatif politikası yazılı

4. Sipariş hattı: outbox + idempotent iletim + durum izleme

5. Kanal/orta katman kararı tüketici sayısıyla gerekçeli

6. Günlük uzlaştırma + askıda kayıt raporu + runbook çalışıyor

7. Test ortamları gerçekçi S/4 bağlantılı; veri maskeleme kurulu

SSH Yazılım, SAP Commerce ↔ S/4HANA entegrasyonlarını akış tasarımından uzlaştırma disiplinine uçtan uca kurar. ERP hattınızı satışın freni olmaktan birlikte çıkaralım.