Yazar: Mahsun AK | SAP Basis Teknoloji Danışmanı
Çoğu SAP dönüşümü teknolojiden değil, diyagramları karar sanmamızdan dolayı başarısız olur.
Toplantılarda “mimari” dediğimiz şey çoğu zaman sadece bir resim. Ortasında S/4HANA, yanında CPI/PO, etrafında birkaç bulut sistem… Slayt güzel olunca herkes kendini güvende hissediyor. Fakat durum sadece bundan mı ibaret?
Ama gerçek hayat böyle değil. Sistemler gece 02:00’de down oluyor, sertifikalar bayram tatilinde expire oluyor, yanlış kurgulanmış tek bir retry mekanizması bütün tedarik zincirini durdurabiliyor. Gerçek mimari diyagram değildir; kararların, sorumlulukların ve operasyonel disiplinin yaşayan bütünüdür.
Bu yazıda kendi projelerimizde gördüklerimi paylaşmak istiyorum:
- SAP ortamları neden güçlü görünürken kırılgan davranıyor?
- Diyagramların bize asla söylemediği şeyler nelerdir?
- Gerçek mimari hangi katmanlardan oluşmalı?
- Dayanıklı bir SAP ekosistemi nasıl tasarlanır?
1. Diyagram Yanılgısı – Toplantılarda Gördüğümüz Manzara
- Güzel bir mimari sunumu açılır
- Oklar S/4’ten CPI/PO’ya, oradan HR/SuccessFactors’a akar
- Sonunda biri: “Mimari onaylandı.” der
Peki:
- Bir interface 10 dakika gecikirse ne olur?
- CPI kuyrukları dolarsa kim temizleyecek?
- Gerçek bir retry ve idempotency stratejimiz var mı?
- SAP customizing bu akışla gerçekten uyumlu mu?
Diyagram bunların hiçbirine cevap vermez. Sadece kutucukları ifade eder.
Gösterdiğimiz vs Yaşadığımız
[İş Süreci]
|
[Entegrasyon]
|
[Uygulamalar]
Görünmeyen gerçek: sahiplik, retry, monitoring, güvenlik, operasyon
2. Bizim İçin Mimari = Kararlar
Bir SAP ortamının sağlamlığını belirleyen konular genelde gösterişli değildir:
- Entegrasyon desenleri belirgindir.
- Hata sahipliği olmalıdır
- Veri yönetişimi belirlenmelidir.
- Monitoring yaklaşımı kurgulanmalıdır.
- Günlük operasyon prosedürleri belirlenmelidir.
Kutular istikrar yaratmaz – kararlar yaratır.
3. Bazı Olası Vakalar
Vaka 1 – Retry Fırtınası
Bir projede “esneklik olsun” diye tüm IDoc’lar CPI üzerinden geçirildi. Idempotency yoktu, back-pressure yoktu, circuit breaker yoktu. Küçük bir fonksiyonel hata dakikalar içinde 200.000’den fazla retry üretti. SMQ2 kuyrukları kilitlendi, lojistik saatlerce durdu. Herkes önce Basis’e baktı; asıl kök neden ise iş mantığının içinde saklıydı. Tek bir fiyatlandırma hatası günlere neden oldu.
Ders: Entegrasyonlar ERP’yi korumalıdır. Yönetişim yoksa CPI/PO kendi sistemine karşı silaha dönüşür.
Vaka 2 – Sertifika Krizi
Bir entegrasyondaki OAuth sertifikası Cuma gecesi süresi doldu. Prosedür yok, alarm yok, sahibi belli değil. Kritik replikasyon günlerce çalışmadı ve sorun çok geç fark edildi.
Ders: Sertifika yaşam döngüsü teknik detay değil, iş sürekliliğinin kalbidir.
Vaka 3 – Sahibi Olmayan Kuyruk
Büyük bir migrasyon sonrası inbound kuyruklar doldu. Fonksiyonel ekip “Basis problemi” dedi, Basis “interface mantığı” dedi, entegrasyon ekibi “SAP standardı” dedi. Saatler sadece sahiplik tartışmasıyla geçti. Sahiplenecek kişi izne ayrıldı ve ekibini durumdan bir haber bıraktı.
Ders: Sorumluluk almak/alabilmek her araçtan daha önemlidir.
Vaka 4 – Clean Core Hayali
Lanscape temiz kalsın diye birçok validasyon BTP’ye taşındı. Fakat CPI iFlow’ları ile S/4 sürümleri arasında versiyon uyumu kurgulanmamıştı. İlk upgrade sonrası uzantıların yarısı uyumsuz hale geldi, kuyrukların temizlenmesi günler aldı. Hatta akışı durdurmak ve yeni sürüme uyumlu hale getirmek gerekti.
Ders: Geliştirme tüm detayı ile tamamlanmadıkça entegrasyonlar kendine savaş açar.
Hataların Gerçek Meydanı
Tasarım → Geliştirme → Go-Live → Operasyon
↑
asıl savaş alanı
4. Basis & BTP Gözünden Mimari
Bizim Basis ve BTP perspektifimizle mimari şu somut sorulara cevap vermeli:
Transport & Yaşam Döngüsü
- CPI iFlow versiyonları S/4 transportlarıyla nasıl hizalanıyor?
- Bir transport yeni mapping gerektirirse ne olacak?
- Sistemler arası rollback tanımlı mı?
Runtime Yönetişimi
- CPI/PO’yu gerçek üretim ortamı gibi kim işletiyor?
- Kuyruk eşikleri ve housekeeping kuralları ne?
Güvenlik Operasyonu
- Kesintisiz sertifika rotasyonu var mı?
- RFC user kontrol ediliyor mu?
- OAuth ve secret yönetimi yapılıp belgeleniyor mu?
Upgrade Dayanıklılığı
- S/4 upgrade’lerinin BTP uzantılarına etkisi araştırıldı mı, Geliştirmeler buna uyumlu mu?
- Interface regresyon testleri yapıldı mı?
- Decoupling stratejisi çıkarıldı mı?
Monitoring – Günlük Gerçek
- SM58/SMQ2’den CPI’a uçtan uca izleme yapılıyor mu? Alert mekanizması aktif mi?
- Birleşik alarm yapısı doğru kişilere iletiliyor mu?
Bunlar tanımlı değilse, diyagram ne kadar modern olursa olsun ortam kırılgandır. Bazen en küçük kurgu eklenmesinde ya da yeni bir yama yüklenmesinde büyük sorunlara sebep olur.
Ek Bilgi Kaynağı
SAP Basis’te checklist’lerin ötesine geçin. Sahadan tecrübelerle “çalışan” değil, dayanıklı bir sistem inşa etmenin sırlarını ve uzmanlık ipuçlarını keşfedin.
5. Dayanıklı Mimari
Katmanlı Bakış
- İş Yetkinliği – değer, etki, RPO/RTO
- Süreç – sahiplik & fallback
- Entegrasyon – kontratlar & idempotency
- Uygulama – clean core sınırları
- Altyapı – HA/DR & sertifikalar
6. Reçetemiz
Adım 1 – Karar Logu
Her entegrasyon için olması gerekenler:
- Sync/Async gerekçesi nelerdir? Etkisi test edildi mi? Gerçekten ihtiyaç var mı?
- Retry politikası belirli mi?
- Veri sahibi müdahale edemeyeceği durumlarda kendisini yedekledi mi?
- Payload limitleri nelerdir?
- Monitoring yaklaşımı var mı?
Adım 2 – Operasyon Senaryoları
- CPI down müdahalesine hazır mı?
- Kuyruk dolu sorunları ne kadar sürede belirlenebilir?
- Toplu veri hatası çözümü kim sahiplenebilir?
- DR geçişi uygulanıp test edildi mi?
Adım 3 – Gözlemlenebilirlik
- Business log
- Alarm matrisi
- KPI’lar
Adım 4 – Clean Core
- Custom sınırları
- BTP uzantıları
- Upgrade etkisi
7. Mimari Nedir, Ne Değildir?
Bizim için mimari;
ne bir diyagram dosyasıdır,
ne bir CPI iFlow listesi,
ne de bir T-code kataloğudur.
Mimari, gerçek dünya vurduğunda sistemi ayakta tutan kararlar bütünüdür.
Diyagram bugün kaybolsa, sistem yaşamaya devam eder mi?
Eğer cevap hayırsa, elimizde mimari değil, sadece güzel bir resim vardır.
Dayanıklı bir SAP ortamı; yedekleme, HA/DR, güvenlik sahipliği, veri sorumluluğu, geliştirme senaryoları ve izleme mekanizmalarının birlikte düşünülmesiyle mümkün olur.
Mimari, kutucuklardan değil; insanlar, senaryolar ve müdahale planlarından oluşur.