K
Kerem Kırlı
Misafir
Misafir
SAP Integration Suite’de tenant, bir BTP subaccount’una bağlı; kendi mesaj kotası, kullanıcı/rol yapısı ve runtime’ı olan bağımsız bir abonelik birimidir. Kurumsal ölçekte önerilen standart yaklaşım, Dev, Test ve Prod için ayrı BTP subaccount’ları üzerinde ayrı tenant’lar kurmak ve içerik akışını bu tenant’lar arasında kontrollü şekilde taşımaktır.
SAP Integration Suite’e geçen ekiplerin çoğu, önce “kaç tenant’a ihtiyacımız var?” sorusuyla karşılaşır. Tek tenant’ta geliştirme, test ve canlı süreci bir arada yürütmek başta pratik görünse de, test ortamındaki küçük bir hata canlı sipariş veya fatura akışını doğrudan etkileyebilir. SAP Integration Suite’de standart yaklaşım, Dev, Test ve Prod için ayrı BTP subaccount’ları üzerinde ayrı tenant’lar kurmak ve içerik akışını (iFlow, mapping, güvenlik materyali) bu tenant’lar arasında kontrollü şekilde taşımaktır. Bu yazıda, klasik 3 katmanlı landscape modelini, daha küçük organizasyonlar için alternatif yaklaşımları, tenant’lar arası içerik taşıma (transport) yöntemlerini ve bir landscape kurgularken gözden kaçırılmaması gereken noktaları ele alıyoruz.
Bir proof-of-concept veya pilot proje için tek tenant üzerinde geliştirme, test ve canlı kullanımı bir arada yürütmek maliyet açısından cazip görünür. Ancak bu kurgu, iş yükü izolasyonu (workload isolation) sağlamaz.
Test amaçlı devreye alınan veya hâlâ üzerinde çalışılan bir iFlow, aynı tenant’ta çalışan canlı bir sürecin performansını ya da doğruluğunu etkileyebilir. Test ortamında yapılan bir hata, gerçek sipariş, fatura veya master data akışını bozabilir.
Bu risk, tenant sayısı arttıkça değil, ortamlar birbirinden ayrıştıkça azalır. Bu nedenle SAP de dahil olmak üzere entegrasyon mimarları, en azından Dev ve Prod’un ayrı tenant’larda barındırılmasını öneriyor.
SAP Integration Suite’de tenant, bir BTP subaccount’una bağlı, kendi mesaj kotasına, kendi kullanıcı/rol yapısına ve kendi runtime’ına sahip bağımsız bir abonelik birimidir. SAP PI/PO’daki “tek sistem, çoklu client” mantığından farklı olarak, her tenant kendi başına ayrı bir hizmet örneğidir.
Bu noktada önemli bir maliyet gerçeği var: SAP, prod olmayan bir tenant için de prod tenant ile aynı ücreti talep eder. Yani “test tenant’ı daha ucuza gelir” varsayımı doğru değildir; landscape kararı sadece teknik değil, bütçesel bir karardır.
Fatura otomasyonu gibi mesaj hacmi yüksek senaryolarda tenant başına mesaj kotasının nasıl hesaplandığını
Kurumsal ölçekte önerilen standart yaklaşım, üç ayrı BTP subaccount’u ve bunların her birinde ayrı bir Integration Suite tenant’ı çalıştırmaktır:
Her tenant, kendi backend bağlantısına (Cloud Connector üzerinden ilgili Dev/QA/Prod SAP sistemine) sahiptir. Bu sayede test ortamındaki bir hata, canlı sistemin verisine hiçbir şekilde dokunmaz.
Büyük organizasyonlarda bu model iş birimi (business unit) bazında da tekrarlanabilir: örneğin finans, üretim ve perakende birimleri için ayrı ayrı Dev-Test-Prod landscape’leri kurulabilir. Bu yaklaşım özerklik sağlar, ancak yönetişimin (governance) merkezi ve tutarlı kalmasını da gerektirir.
Her şirketin üç ayrı tenant’ı işletecek bütçesi ya da entegrasyon hacmi olmayabilir. Bu durumda iki yaygın alternatif kullanılır:
2 katmanlı landscape: Dev ve Test tek bir tenant’ta birleştirilir, Prod ise mutlaka ayrı tutulur. Bu, maliyeti düşürürken canlı ortamı yine de izole eder.
Tek tenant, dinamik konfigürasyon: Küçük ölçekli veya düşük riskli senaryolarda, tek bir tenant üzerinde çalışan iFlow’lar; ortam bilgisini (DEV/TEST/PROD) dışsallaştırılmış bir parametre üzerinden okuyup bağlantıyı buna göre değiştirebilir. Bu yaklaşım tek bir iFlow kopyasının bakımını kolaylaştırır, ancak iş yükü izolasyonu sağlamadığı için önem taşıyan canlı süreçler için önerilmez.
Hangi modelin uygun olduğu; entegrasyon hacmine, ekip büyüklüğüne ve canlı sistemin ne denli hassas olduğuna göre değişir.
Bir iFlow’u Dev’de geliştirdikten sonra Test’e ve ardından Prod’a taşımak, SAP PI/PO’daki transport request mantığından farklı çalışır. SAP Integration Suite’te iki yaygın yöntem kullanılır:
Content Agent + Cloud Transport Management (CTMS): Content Agent servisi, kaynak tenant’taki seçili paket veya artefaktları toplar; Cloud Transport Management ise bunları tanımlı Dev → Test → Prod transport node’ları üzerinden hedef tenant’lara aktarır. Bu, merkezi ve denetlenebilir bir transport sürecidir.
Git tabanlı yaklaşım: iFlow’lar Git push/pull/import özellikleriyle merkezi bir repository’de versiyonlanır; onaylanan versiyon buradan Test ve Prod tenant’larına aktarılır. Bu yöntem, değişiklik geçmişini ve karşılaştırmayı native olarak destekler.
Hangi yöntem seçilirse seçilsin, şu üç prensip landscape’in sağlığı açısından önem taşır:
Bir landscape tasarımı yaparken göz önünde bulundurulması gereken başlıca noktalar şunlardır:
SAP Integration Suite’in bu alandaki yetenekleri düzenli olarak gelişiyor; platformdaki güncel özellikleri
Farklı ülkelerde faaliyet gösteren, merkezi bir SAP S/4HANA sistemine sahip bir şirketi düşünelim. Entegrasyon ekibi başlangıçta tek bir tenant üzerinde hem geliştirme hem test yapıyor, canlıya alım da aynı tenant üzerinden gerçekleşiyor olsun.
Hacim arttıkça ve yeni ülkeler sürece dahil oldukça, test amaçlı devreye alınan bir mapping değişikliği canlı sipariş akışını geçici olarak durdurabilir. Bu noktada ekip; Dev, Test ve Prod için üç ayrı subaccount ve tenant kurar, Content Agent ve Cloud Transport Management ile merkezi bir transport hattı oluşturur.
Sonuç olarak geliştirme ekibi Dev’de özgürce çalışmaya devam ederken, Prod ortamı yalnızca onaylı ve Test’te doğrulanmış içerikle güncellenir; canlı süreçler geliştirme çalışmalarından tamamen izole olur.
Sıfırdan ya da mevcut bir kurgudan geçiş yaparken izlenebilecek adımlar:
Bu adımların her biri mevcut SAP BTP hesap yapınıza ve entegrasyon olgunluğunuza göre şekillenir; bu yüzden landscape kararını vermeden önce deneyimli bir entegrasyon ekibiyle mevcut durumu değerlendirmek uzun vadede zaman ve maliyet kazandırır.
SAP Integration Suite’de kaç tenant’a ihtiyacım var?
Standart öneri en az iki tenant’tır: biri Prod, diğeri Prod-dışı (Dev/Test birleşik). Kurumsal ölçekte ve önem taşıyan süreçlerde üç ayrı tenant (Dev, Test, Prod) önerilir.
Test tenant’ı, Prod tenant’ından daha mı ucuza gelir?
Hayır. SAP, prod olmayan bir tenant için de prod tenant ile aynı ücreti uygular. Maliyet avantajı, gereksiz tenant sayısını azaltmaktan gelir; tenant tipinden değil.
iFlow’ları Dev’den Prod’a nasıl taşırım?
İki ana yöntem vardır: Content Agent servisi ile Cloud Transport Management üzerinden kontrollü transport, ya da Git push/pull/import ile versiyon kontrollü bir akış. İkisi de manuel indirme/yükleme yerine izlenebilir bir süreç sağlar.
Tek tenant’ta Dev, Test ve Prod’u birlikte yönetmek mümkün mü?
Teknik olarak evet; dışsallaştırılmış parametrelerle tek bir iFlow’un farklı ortamlara bağlanması sağlanabilir. Ancak bu yaklaşım iş yükü izolasyonu sunmadığından, önem taşıyan canlı süreçler için önerilmez.
SAP Integration Suite’de tenant stratejisi, tek bir doğru cevabı olan bir konu değil; entegrasyon hacmine, ekip yapısına ve risk toleransına göre şekillenen bir mimari karardır. Sabit olan tek şey, test ve canlı ortamların birbirinden izole edilmesi gerektiğidir.
MDP Group olarak
SAP Integration Suite’e geçen ekiplerin çoğu, önce “kaç tenant’a ihtiyacımız var?” sorusuyla karşılaşır. Tek tenant’ta geliştirme, test ve canlı süreci bir arada yürütmek başta pratik görünse de, test ortamındaki küçük bir hata canlı sipariş veya fatura akışını doğrudan etkileyebilir. SAP Integration Suite’de standart yaklaşım, Dev, Test ve Prod için ayrı BTP subaccount’ları üzerinde ayrı tenant’lar kurmak ve içerik akışını (iFlow, mapping, güvenlik materyali) bu tenant’lar arasında kontrollü şekilde taşımaktır. Bu yazıda, klasik 3 katmanlı landscape modelini, daha küçük organizasyonlar için alternatif yaklaşımları, tenant’lar arası içerik taşıma (transport) yöntemlerini ve bir landscape kurgularken gözden kaçırılmaması gereken noktaları ele alıyoruz.
Neden Tek Bir Integration Suite Tenant’ı Yeterli Değil?
Bir proof-of-concept veya pilot proje için tek tenant üzerinde geliştirme, test ve canlı kullanımı bir arada yürütmek maliyet açısından cazip görünür. Ancak bu kurgu, iş yükü izolasyonu (workload isolation) sağlamaz.
Test amaçlı devreye alınan veya hâlâ üzerinde çalışılan bir iFlow, aynı tenant’ta çalışan canlı bir sürecin performansını ya da doğruluğunu etkileyebilir. Test ortamında yapılan bir hata, gerçek sipariş, fatura veya master data akışını bozabilir.
Bu risk, tenant sayısı arttıkça değil, ortamlar birbirinden ayrıştıkça azalır. Bu nedenle SAP de dahil olmak üzere entegrasyon mimarları, en azından Dev ve Prod’un ayrı tenant’larda barındırılmasını öneriyor.
SAP Integration Suite’de “Tenant” Kavramı Ne Anlama Gelir?
SAP Integration Suite’de tenant, bir BTP subaccount’una bağlı, kendi mesaj kotasına, kendi kullanıcı/rol yapısına ve kendi runtime’ına sahip bağımsız bir abonelik birimidir. SAP PI/PO’daki “tek sistem, çoklu client” mantığından farklı olarak, her tenant kendi başına ayrı bir hizmet örneğidir.
Bu noktada önemli bir maliyet gerçeği var: SAP, prod olmayan bir tenant için de prod tenant ile aynı ücreti talep eder. Yani “test tenant’ı daha ucuza gelir” varsayımı doğru değildir; landscape kararı sadece teknik değil, bütçesel bir karardır.
Fatura otomasyonu gibi mesaj hacmi yüksek senaryolarda tenant başına mesaj kotasının nasıl hesaplandığını
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
yazımızda detaylı inceledik; landscape planlarken bu kotaları da hesaba katmak gerekir.Dev, Test ve Prod İçin Klasik 3 Katmanlı Landscape
Kurumsal ölçekte önerilen standart yaklaşım, üç ayrı BTP subaccount’u ve bunların her birinde ayrı bir Integration Suite tenant’ı çalıştırmaktır:
- Dev tenant: Geliştiricilerin iFlow, mapping ve güvenlik materyalini oluşturduğu, sık değişikliğin olduğu ortam.
- Test/QA tenant: İş birimlerinin ve test ekiplerinin senaryoları gerçek veriye yakın koşullarda doğruladığı ortam.
- Prod tenant: Canlı iş süreçlerinin çalıştığı, değişikliklerin yalnızca onaylı içerikle güncellendiği ortam.
Her tenant, kendi backend bağlantısına (Cloud Connector üzerinden ilgili Dev/QA/Prod SAP sistemine) sahiptir. Bu sayede test ortamındaki bir hata, canlı sistemin verisine hiçbir şekilde dokunmaz.
Büyük organizasyonlarda bu model iş birimi (business unit) bazında da tekrarlanabilir: örneğin finans, üretim ve perakende birimleri için ayrı ayrı Dev-Test-Prod landscape’leri kurulabilir. Bu yaklaşım özerklik sağlar, ancak yönetişimin (governance) merkezi ve tutarlı kalmasını da gerektirir.
Daha Küçük Organizasyonlar İçin Alternatif Yaklaşımlar
Her şirketin üç ayrı tenant’ı işletecek bütçesi ya da entegrasyon hacmi olmayabilir. Bu durumda iki yaygın alternatif kullanılır:
2 katmanlı landscape: Dev ve Test tek bir tenant’ta birleştirilir, Prod ise mutlaka ayrı tutulur. Bu, maliyeti düşürürken canlı ortamı yine de izole eder.
Tek tenant, dinamik konfigürasyon: Küçük ölçekli veya düşük riskli senaryolarda, tek bir tenant üzerinde çalışan iFlow’lar; ortam bilgisini (DEV/TEST/PROD) dışsallaştırılmış bir parametre üzerinden okuyup bağlantıyı buna göre değiştirebilir. Bu yaklaşım tek bir iFlow kopyasının bakımını kolaylaştırır, ancak iş yükü izolasyonu sağlamadığı için önem taşıyan canlı süreçler için önerilmez.
Hangi modelin uygun olduğu; entegrasyon hacmine, ekip büyüklüğüne ve canlı sistemin ne denli hassas olduğuna göre değişir.
İçerik Nasıl Taşınır? Tenant’lar Arası Transport Stratejisi
Bir iFlow’u Dev’de geliştirdikten sonra Test’e ve ardından Prod’a taşımak, SAP PI/PO’daki transport request mantığından farklı çalışır. SAP Integration Suite’te iki yaygın yöntem kullanılır:
Content Agent + Cloud Transport Management (CTMS): Content Agent servisi, kaynak tenant’taki seçili paket veya artefaktları toplar; Cloud Transport Management ise bunları tanımlı Dev → Test → Prod transport node’ları üzerinden hedef tenant’lara aktarır. Bu, merkezi ve denetlenebilir bir transport sürecidir.
Git tabanlı yaklaşım: iFlow’lar Git push/pull/import özellikleriyle merkezi bir repository’de versiyonlanır; onaylanan versiyon buradan Test ve Prod tenant’larına aktarılır. Bu yöntem, değişiklik geçmişini ve karşılaştırmayı native olarak destekler.
Hangi yöntem seçilirse seçilsin, şu üç prensip landscape’in sağlığı açısından önem taşır:
- İsimlendirme standardı: Paket ve artefakt ID’lerinde DEV_/QA_/PROD_ gibi önekler kullanmak, hangi içeriğin hangi ortama ait olduğunu net tutar.
- Dışsallaştırılmış parametreler: Backend URL’i, kimlik bilgisi adı gibi ortama özgü değerler iFlow içine gömülmek yerine parametre olarak tanımlanmalı.
- Rol bazlı erişim: Dev ortamında geliştiriciye tanınan yetki, Prod ortamında sınırlı ve onay sürecine bağlı olmalıdır.
Tenant Stratejisi Kurgularken Dikkat Edilmesi Gerekenler
Bir landscape tasarımı yaparken göz önünde bulundurulması gereken başlıca noktalar şunlardır:
- İş yükü izolasyonu: Test ve canlı süreçler asla aynı tenant’ta çalışmamalı.
- Mesaj kotası planlaması: Her tenant’ın kendi kotası vardır; Prod tenant’ı kota aşımına karşı ayrı izlenmelidir.
- Backend bağlantı yönetimi: Her tenant, kendi Cloud Connector ve hedef sistem eşlemesine sahip olmalıdır.
- Versiyon kontrolü: İçerik geçmişi izlenebilir olmalı; hangi versiyonun hangi ortamda çalıştığı her zaman bilinmeli.
- Maliyet governance’ı: Prod olmayan tenant’lar da aynı ücrete tabi olduğundan, tenant sayısı iş ihtiyacına göre gerekçelendirilmeli.
SAP Integration Suite’in bu alandaki yetenekleri düzenli olarak gelişiyor; platformdaki güncel özellikleri
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
yazımızdan takip edebilirsiniz.Örnek Senaryo: Çok Uluslu Bir Şirkette Landscape Kurgusu
Farklı ülkelerde faaliyet gösteren, merkezi bir SAP S/4HANA sistemine sahip bir şirketi düşünelim. Entegrasyon ekibi başlangıçta tek bir tenant üzerinde hem geliştirme hem test yapıyor, canlıya alım da aynı tenant üzerinden gerçekleşiyor olsun.
Hacim arttıkça ve yeni ülkeler sürece dahil oldukça, test amaçlı devreye alınan bir mapping değişikliği canlı sipariş akışını geçici olarak durdurabilir. Bu noktada ekip; Dev, Test ve Prod için üç ayrı subaccount ve tenant kurar, Content Agent ve Cloud Transport Management ile merkezi bir transport hattı oluşturur.
Sonuç olarak geliştirme ekibi Dev’de özgürce çalışmaya devam ederken, Prod ortamı yalnızca onaylı ve Test’te doğrulanmış içerikle güncellenir; canlı süreçler geliştirme çalışmalarından tamamen izole olur.
SAP Integration Suite Tenant Stratejinizi Nasıl Kurarsınız?
Sıfırdan ya da mevcut bir kurgudan geçiş yaparken izlenebilecek adımlar:
- Mevcut/hedef entegrasyon hacminin değerlendirilmesi: Mesaj hacmi, iş birimi sayısı ve hassasiyet seviyesi landscape büyüklüğünü belirler.
- Landscape modelinin seçimi: 3 katmanlı, 2 katmanlı veya iş birimi bazlı model arasında karar verilir.
- Transport mekanizmasının kurulması: Content Agent + Cloud Transport Management ya da Git tabanlı akış seçilir ve yapılandırılır.
- İsimlendirme ve rol standartlarının belirlenmesi: Paket, artefakt ve kullanıcı rolleri için kurumsal bir standart oluşturulur.
- Pilot ile doğrulama: Yeni landscape, sınırlı sayıda entegrasyon senaryosuyla test edilip ardından tüm sürece yaygınlaştırılır.
Bu adımların her biri mevcut SAP BTP hesap yapınıza ve entegrasyon olgunluğunuza göre şekillenir; bu yüzden landscape kararını vermeden önce deneyimli bir entegrasyon ekibiyle mevcut durumu değerlendirmek uzun vadede zaman ve maliyet kazandırır.
Sıkça Sorulan Sorular
SAP Integration Suite’de kaç tenant’a ihtiyacım var?
Standart öneri en az iki tenant’tır: biri Prod, diğeri Prod-dışı (Dev/Test birleşik). Kurumsal ölçekte ve önem taşıyan süreçlerde üç ayrı tenant (Dev, Test, Prod) önerilir.
Test tenant’ı, Prod tenant’ından daha mı ucuza gelir?
Hayır. SAP, prod olmayan bir tenant için de prod tenant ile aynı ücreti uygular. Maliyet avantajı, gereksiz tenant sayısını azaltmaktan gelir; tenant tipinden değil.
iFlow’ları Dev’den Prod’a nasıl taşırım?
İki ana yöntem vardır: Content Agent servisi ile Cloud Transport Management üzerinden kontrollü transport, ya da Git push/pull/import ile versiyon kontrollü bir akış. İkisi de manuel indirme/yükleme yerine izlenebilir bir süreç sağlar.
Tek tenant’ta Dev, Test ve Prod’u birlikte yönetmek mümkün mü?
Teknik olarak evet; dışsallaştırılmış parametrelerle tek bir iFlow’un farklı ortamlara bağlanması sağlanabilir. Ancak bu yaklaşım iş yükü izolasyonu sunmadığından, önem taşıyan canlı süreçler için önerilmez.
SAP Integration Suite’de tenant stratejisi, tek bir doğru cevabı olan bir konu değil; entegrasyon hacmine, ekip yapısına ve risk toleransına göre şekillenen bir mimari karardır. Sabit olan tek şey, test ve canlı ortamların birbirinden izole edilmesi gerektiğidir.
MDP Group olarak
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
kapsamında landscape tasarımından transport stratejisine kadar bu tür yapılandırma projelerini uçtan uca yürütüyoruz. SAP PI/PO’dan Integration Suite’e geçiş sürecinde landscape kararlarının nasıl şekillendiğini merak ediyorsanız
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
da göz atabilirsiniz.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.