Bayi portalı, saha satış uygulaması ya da müşteri self-servis ekranı… ERP'nin önünde çalışan bu uygulamaların çoğu SAP OData servisleri üzerinden SAP ile konuşur. Laravel gibi bir PHP çatısıyla bu entegrasyonu kurmak zor değildir; zor olan, onu canlıda yıllarca sorunsuz çalışacak biçimde kurmaktır.
OData nedir, neden tercih edilir?
OData, REST prensiplerine dayanan ve sorgulama (filtreleme, sıralama, alan seçimi, sayfalama) için standart kurallar tanımlayan bir protokoldür. SAP Gateway ve S/4HANA, iş nesnelerini (satış siparişi, müşteri, malzeme) OData servisleri olarak sunar. Böylece doğrudan veritabanına erişmeden, SAP'nin iş kuralları ve yetki kontrolleri devredeyken veri okunup yazılabilir.
Okuma: az ve öz isteyin
- Alan seçimi: Yalnızca gereken alanları isteyin; gereksiz alanlar yanıtı büyütür ve yavaşlatır.
- Filtreleme: Filtreyi uygulamada değil sunucuda yapın; binlerce kaydı çekip PHP'de süzmek hem yavaş hem risklidir.
- Sayfalama: Büyük listeleri sayfalar hâlinde çekin.
- Önbellek: Sık değişmeyen veriyi (malzeme listesi, ödeme koşulları) kısa süreli önbelleğe alın.
Yazma: güvenlik ve tutarlılık
SAP OData servislerinde değişiklik istekleri için genellikle önce bir CSRF token alınır, ardından aynı oturumla POST, PATCH ya da DELETE isteği gönderilir. Laravel'in HTTP istemcisinde bu akışı tek bir servis sınıfında toplamak, uygulamanın geri kalanını SAP ayrıntılarından korur.
- Kimlik doğrulama: Teknik kullanıcı yerine mümkünse OAuth veya sertifika tabanlı yöntemler; kimlik bilgileri yalnızca sunucu ortam değişkenlerinde.
- Yetki: Entegrasyon kullanıcısının SAP yetkileri yalnızca gereken nesnelerle sınırlanır; görevler ayrılığı ilkesi entegrasyon kullanıcıları için de geçerlidir.
- Doğrulama: Veri SAP'ye gitmeden önce uygulamada doğrulanır; SAP'den dönen hata mesajları kullanıcıya anlaşılır biçimde aktarılır.
Sağlamlık: kuyruk, yeniden deneme, idempotency
- Kuyruk: Sipariş oluşturma gibi işlemler kullanıcı isteği içinde değil, bir kuyruk işi olarak çalıştırılır. SAP geçici olarak yanıt vermezse kullanıcı beklemez.
- Yeniden deneme: Geçici hatalarda artan beklemeyle birkaç kez yeniden denenir; kalıcı hatalar (ör. doğrulama) yeniden denenmez.
- Idempotency: Aynı sipariş iki kez gönderilirse SAP'de iki sipariş oluşmamalıdır. Uygulamanın ürettiği tekil bir referans (ör. harici sipariş no) SAP'de saklanır ve gönderimden önce kontrol edilir.
- Kayıt: Her istek ve yanıt, kişisel veriler maskelenerek kayıt altına alınır; sorun analizinde en değerli bilgi budur.
Performans
ERP entegrasyonlu uygulamalarda yavaşlığın kaynağı çoğunlukla ağ gidiş-dönüşleridir. Toplu istek (batch) kullanmak, paralel çağrıları sınırlı tutmak ve ekranı SAP yanıtını beklemeden kısmen göstermek kullanıcı deneyimini belirgin biçimde iyileştirir. Genel web performansı ilkeleri için web performans yazısına bakabilirsiniz.
Test
SAP servisleri için bir sahte (mock) katman hazırlamak, geliştirme ve otomatik testleri SAP test sisteminin müsaitliğinden bağımsız kılar. Ancak son doğrulama mutlaka gerçek SAP test sisteminde, gerçek belge ve muhasebe akışıyla yapılmalıdır.
İyi bir entegrasyon görünmezdir: kullanıcı yalnızca işinin hızlandığını fark eder. ERP bilgisini yazılım uzmanlığıyla birleştirmek, bu görünmezliğin anahtarıdır.
