SAP Integration Suite'de Lokal ve Global Data Store Kullanımı: Hangisi, Ne Zaman Kullanılır?

SAP Integration Suite'de Data Store, iFlow'lar arasında veya bir iFlow içinde mesajları geçici olarak saklamanızı sağlayan güçlü bir yapıdır. Burada kritik karar noktası şudur: Data Store'un kapsamı (Visibility) "Local" mi yoksa "Global" mi olmalı? Cevap basit ama çoğu zaman yanlış verilir: Verinizi yalnızca aynı iFlow tekrar kullanacaksa Local, başka iFlow'lar da erişecekse Global seçilmelidir. Yanlış seçim, hem performans problemlerine hem de tenant'ınızdaki 32 GB'lık veri limiti nedeniyle ileride ciddi baş ağrılarına yol açabilir.Bu yazıda Lokal ve Global Data Store'un farklarını, hangi senaryoda hangisini seçmeniz gerektiğini, dikkat etmeniz gereken sınırları ve sahadan öğrendiğimiz pratik ipuçlarını paylaşacağız. Yazının sonunda, kendi entegrasyon akışlarınızda doğru kararı verebilecek netliğe ulaşacaksınız.

Data Store Nedir ve Neden İhtiyacımız Var?

Data Store, SAP Cloud Integration (CPI) tenant'ında SAP ASE veritabanı üzerinde mesajları geçici olarak depolayan bir bileşendir. Bir veritabanı tablosu gibi düşünmek doğru değildir; daha çok mesaj kuyruğu ile veritabanı arası bir yapı olarak değerlendirmek gerekir.Data Store dört temel operasyonla çalışır:

• Write: Mesajı belirli bir Entry ID ile saklar.
• Get: Belirli bir Entry ID ile tek bir mesajı çeker (çekildikten sonra silinebilir).
• Select: Toplu olarak birden fazla mesajı çeker.
• Delete: Mesajı manuel olarak siler.

Bu yapı; asenkron işlemler, retry senaryoları, batch processing ve cross-iFlow veri paylaşımı gibi durumlarda hayat kurtarır.

Lokal Data Store Nedir?

Lokal Data Store, yalnızca tanımlandığı iFlow tarafından erişilebilen bir veri saklama alanıdır. Yani aynı tenant üzerinde başka bir iFlow, bu Data Store'a bakamaz, içeriğini okuyamaz ve değiştiremez.Lokal kapsamda Data Store'un ismi otomatik olarak iFlow'un teknik ismiyle ilişkilendirilir. Bu sayede aynı isimli birden fazla Data Store tanımlasanız bile çakışma yaşanmaz.

Lokal Data Store Ne Zaman Tercih Edilmeli?

Aşağıdaki durumlarda Lokal seçim doğru tercih olur:

• iFlow içinde retry mekanizması kuruyorsanız: Hatalı mesajları saklayıp aynı iFlow'un başka bir branch'inde tekrar denemek istediğinizde.
• Tek bir iFlow'un içinde aşamalı işlem yapıyorsanız: Örneğin önce başlık (header) bilgisini saklayıp sonra satırlarla birleştirmek gibi.
• Veriniz başka entegrasyonları ilgilendirmiyorsa: İzolasyon ve güvenlik açısından Lokal her zaman daha temizdir.
• Aynı isimle birden fazla Data Store kullanmak istiyorsanız: Farklı iFlow'larda aynı ismi rahatça kullanabilirsiniz.

Lokal Data Store Örneği

Bir sipariş entegrasyonu düşünün: Sender sisteminden gelen siparişler önce validasyondan geçiyor. Validasyonu geçemeyen kayıtları geçici olarak saklayıp bir saat sonra otomatik retry yapmak istiyorsunuz. Bu durumda Lokal Data Store ideal çözümdür: Veri sadece bu iFlow'a ait, başka süreçlerin görmesine gerek yok.

Global Data Store Nedir?

Global Data Store, tenant seviyesinde tanımlanır ve aynı tenant'taki tüm iFlow'lar tarafından erişilebilir. Bir iFlow Write işlemiyle veri yazar, başka bir iFlow Get veya Select işlemiyle bu veriyi okur.Global kapsamda Data Store'un ismi tüm tenant'ta tek olmak zorundadır. Aynı isimde iki farklı Global Data Store tanımlanamaz.

Global Data Store Ne Zaman Tercih Edilmeli?

Aşağıdaki senaryolarda Global Data Store hayat kurtarır:

• Decoupling pattern (gevşek bağlama) uyguluyorsanız: Bir iFlow veriyi alır ve saklar, başka bir iFlow farklı bir tetikleyiciyle (örneğin Timer) bu veriyi işler.
• Fallback / hata yönetimi tasarlıyorsanız: Ana entegrasyon başarısız olduğunda yedek bir iFlow Data Store'daki son geçerli veriyi okuyabilir.
• Asenkron işlem zincirleri kurguluyorsanız: Bir iFlow uzun süren bir işi başlatır, sonucu Data Store'a yazar; çağıran iFlow daha sonra polling ile sonucu alır.
• Batch processing yapıyorsanız: Bir iFlow gün boyu kayıtları toplar, başka bir iFlow gece toplu olarak işler.

Global Data Store Örneği

Bir e-ticaret platformuyla entegrasyon düşünelim. Web mağazasına çok fazla istek atmamak için günde bir kez ürün ve müşteri yorumlarını çeken bir iFlow kurguladık. Bu iFlow tüm yorumları Global Data Store'a yazıyor. Müşteri hizmetlerinin kullandığı ikinci iFlow ise bu verileri okuyup CRM sistemine aktarıyor. İki iFlow tamamen bağımsız çalışıyor ama aynı veri havuzunu kullanıyor. 

Bu klasik bir producer-consumer desenidir ve Global Data Store olmadan yapılamaz.

Lokal ve Global Data Store Arasındaki Temel Farklar

Karar verirken aşağıdaki tabloya bakmanız işinizi kolaylaştırır:

Performans ve Limit Konusunda Dikkat Edilecekler

Data Store kullanırken çok önemli iki sınır vardır ve bunları görmezden gelmek production'da ciddi sorunlara yol açar:32 GB tenant limiti: Tenant başına toplam Data Store kapasitesi 32 GB'tır. Lokal de olsa Global de olsa bu havuzdan yer kaplar. Eski kayıtları temizlemek (Retention Threshold ayarı veya Delete operasyonu) önemlidir.Retention Threshold ayarı: Write işleminde mutlaka "Retain Until" alanını anlamlı bir değere ayarlayın. Aksi takdirde sonsuza dek duran kayıtlar tenant'ınızı şişirir.Encryption seçeneği: Hassas veri saklıyorsanız (kişisel veri, finansal bilgi) Write operasyonunda "Encrypt Stored Message" seçeneğini aktif edin. Bu seçenek özellikle Global Data Store'da kritiktir çünkü diğer iFlow'lardan da erişilebiliyor olması farkındalık gerektirir.Transaction Handling: Data Store operasyonları transaction'a dahildir. iFlow'unuzun transaction yönetimini "Required for JDBC" olarak ayarlamayı unutmayın; aksi takdirde yarım kalan işlemler tutarsızlık yaratabilir.

Sahadan Pratik Öneriler

Birçok entegrasyon projesinde gördüğümüz yaygın hata, gereksiz yere Global Data Store kullanılmasıdır. Geliştiriciler "ileride başka bir iFlow da kullanır" diye baştan Global tanımlıyor, sonra hiç paylaşılmıyor ama isim çakışmaları ve gereksiz görünürlük yaratıyor.Pratik kural: Şüphedeyseniz Lokal başlayın. İleride başka bir iFlow gerçekten ihtiyaç duyduğunda Global'e geçirmek bir refactor işidir ama tersi (Global'i sınırlamak) çok daha zordur.Bir diğer öneri: Naming convention kullanın. Global Data Store'larda "GDS_OrderArchive_DEV", "GDS_CustomerReview_PROD" gibi isimlendirme yaparsanız hem ortamı hem amacı kolayca ayırt edersiniz.Son olarak, monitoring'i ihmal etmeyin. SAP Integration Suite'in Monitor uygulamasında "Manage Data Stores" bölümünden tüm Data Store'larınızın doluluğunu, mesaj sayısını ve süresini düzenli olarak kontrol edin.

Sonuç

SAP Integration Suite'de Data Store, doğru kullanıldığında entegrasyon mimarinizi çok daha esnek ve dayanıklı hale getirir. Anahtar karar şu sade kuralda saklıdır: Veri yalnız mı kalacak, yoksa paylaşılacak mı? Yalnız kalacaksa Lokal, paylaşılacaksa Global. Bu basit ayrım, hem performans hem de bakım açısından size büyük kazançlar sağlar.32 GB limitini, retention sürelerini ve encryption ihtiyacını her zaman göz önünde bulundurun. Şüphedeyseniz Lokal'den başlayın ve gerçek bir ihtiyaç doğduğunda Global'e geçin.Entegrasyon projelerinizde Data Store dışında Variable, JMS Queue veya Aggregator gibi yapıların da karşılaştırmalı bir analizini görmek ister misiniz? Bir sonraki yazımızda bu yapılar arasındaki farkları ve seçim kriterlerini ele alacağız.