Konu sayfası
SAP® yazılımı entegrasyonlarında bağlantıdan önce netleşmesi gerekenler
Bir entegrasyonun kalıcı maliyeti çoğu zaman bağlantının kendisinde değil, bağlantı kurulmadan önce verilmeyen kararlarda ortaya çıkar. Bu sayfa, SAP® yazılımı ile diğer sistemler arasında veri ve süreç akışı tasarlanırken hangi soruların önce cevaplanması gerektiğini ve Castintech kurumsal ekibinin bu soruları nasıl ele aldığını açıklar.
- Hazırlayan Castintech
- Son doğrulama 23 Eylül 2026
- 7 dk okuma
- Kaynakça
Bu sayfada
Bölümler
Bu içerik genel teknik açıklamadır; belirli bir ürün sürümü veya kurulum için uygulama talimatı değildir.
Bu alanda birlikte çalışabileceğimiz konular
Castintech, kurumsal sistemlerle ilgili teknik soruları bağımsız bir teknik danışmanlık çalışması olarak ele alır. Çalışmanın kapsamı, sistemin mevcut durumu ve elimizdeki kanıt birlikte belirlenir.
- Entegrasyon tasarımı ve mevcut arayüzlerin gözden geçirilmesi
- Özel kod envanteri ve teknik borç değerlendirmesi
- Performans incelemesi ve ölçüm kanıtının hazırlanması
- Dönüşüm öncesi teknik hazırlık ve açık soruların listelenmesi
- Teknik kararlar için seçeneklerin ve etkilerinin yazılı hâle getirilmesi
Teknik konuyu görüşelim İlk görüşme, konunun kapsamını ve hangi kanıtın gerektiğini birlikte netleştirmek içindir.
Entegrasyon neden yalnız bağlantı kurmak değildir?
Bağlantı, iki sistemin birbirine mesaj iletebildiğini gösterir; entegrasyonun doğru çalıştığını göstermez. Asıl iş, hangi verinin hangi sistemde doğru kabul edileceğini, bir mesaj kaybolduğunda veya iki kez geldiğinde ne olacağını ve bir hatayı kimin, hangi bilgiyle çözeceğini önceden ve yazılı olarak kararlaştırmaktır.
Test ortamında başarılı olan bir çağrı; canlı ortamdaki yükü, zaman aşımlarını, aynı kayda eşzamanlı güncellemeleri ve kısmi başarı durumlarını göstermez. Bu durumlar tasarım aşamasında tanımlanmazsa, kararlar çoğu zaman sorun yaşandığı anda ve bilgi eksikken verilir. Yönetim açısından sonuç; mutabakata harcanan emek, gecikmiş süreçler ve sorumlusu belirsiz hatalardır.
Sistem sınırı ve veri sahipliği nasıl belirlenir?
Her veri için tek bir doğru kaynak belirlenir: kayıt hangi sistemde oluşur, hangi sistemde değiştirilebilir ve diğer sistemler bu kaydın kopyasını mı tutar, yoksa gerektiğinde mi sorar? Bu kararlar yazılı olmadan kurulan entegrasyon, iki sistemin aynı veriyi farklı değerlerle doğru saymasına yol açabilir.
Uygulama öncesinde şu konular netleşmelidir:
- ana veri ve hareket verisi için hangi sistemin sahip olduğu
- aynı kaydın birden fazla sistemde değiştirilip değiştirilemeyeceği
- çakışma olduğunda hangi değerin geçerli sayılacağı
- silme ve iptalin diğer sistemlere nasıl yansıyacağı
- belge numarası gibi iş anahtarlarının sistemler arasında nasıl eşleştirileceği
Senkron mu, asenkron mu çalışmalı?
Karar, teknik tercihten önce iş gereksinimine dayanır: çağıran taraf cevabı beklemeden işine devam edebiliyor mu? Sonucun hemen gerektiği durumlarda senkron çağrı uygundur; ancak karşı sistem yavaşladığında veya erişilemediğinde çağıran sürecin de duracağı kabul edilmelidir. Asenkron akış bu bağımlılığı azaltır, buna karşılık durum takibi gerektirir.
| Soru | Senkron yönünde | Asenkron yönünde |
|---|---|---|
| Kullanıcı sonucu hemen görmeli mi? | Evet | Hayır, sonradan bildirim yeterli |
| Karşı sistem erişilemezse ne olmalı? | İşlem durabilir | İşlem bekleyip sonra işlenebilir |
| Mesaj sırası önemli mi? | Tek çağıran için sıra daha kolay korunur | Sıra ayrıca tasarlanmalıdır |
| Yük dalgalanıyor mu? | Karşı sistemin kapasitesine bağlı kalır | Bekleme alanı yükü zamana yayabilir |
Hangi hata sınıfları ayrı ele alınmalıdır?
En az dört sınıf ayrılmalıdır: tekrar denendiğinde geçebilecek geçici teknik hatalar, düzeltme yapılmadan geçmeyecek kalıcı teknik hatalar, verinin iş kuralına uymadığı iş hataları ve sonucun bilinmediği zaman aşımları. Her sınıfın otomatik olarak mı, yoksa insan kararıyla mı ele alınacağı ayrı ayrı belirlenir.
Zaman aşımı özellikle önemlidir: çağıran taraf cevap alamadığında, karşı sistemdeki işlemin gerçekleşip gerçekleşmediğini bilemez. Bu belirsizlik, tekrar işleme tasarımını doğrudan etkiler. Hata sınıfları, yeniden deneme politikası ve manuel müdahalenin sınırı Entegrasyonlarda hata yönetimi ve güvenli tekrar işleme rehberinde ayrıntılı olarak ele alınmıştır.
Diyagramın metin açıklaması
Başlangıç: tekrarlarda değişmeyen bir işlem kimliği taşıyan gelen mesaj. Karar noktası 1: hata sınıfı; hata metnine değil, nedenine ve tekrarın sonucuna göre dört sınıf ayrılır. Üst katman otomatik politikadır. Sonucu belirsiz durumda önce durum kontrolü yapılır; işlem gerçekleşmişse tekrar yoktur ve mesaj işlendi sayılır. Gerçekleşmemişse veya sorgulanamıyorsa, geçici teknik hatayla birlikte karar noktası 2'ye gelir: işlem idempotent mi? Evetse sınırlı otomatik tekrar döngüsü çalışır: en fazla deneme sayısı, artan bekleme ve rastgele sapma, toplam süre sınırı. Döngü 1, 2, …, n sayacıyla sınırlıdır. Sonuç alınırsa işlendi: aynı işlem kimliği ikinci kez uygulanmaz. n'ye ulaşılırsa veya bir ölçüt tetiklenirse döngü durur: deneme ya da süre sınırı, aynı kalıcı hatanın tekrarı, bakım penceresi, hata oranı eşiği, sıra ihlali veya veri bütünlüğü şüphesi; durdurma kararı kaydedilir. İşlem idempotent değilse otomatik tekrar yapılmaz. Bu iki yol, kalıcı teknik hata ve iş hatası katman sınırının altındaki insan kararı katmanına iner: insan kararı bekleyen durum; mesaj kaybolmaz. Kalıcı teknik hatada teknik ekip, iş hatasında süreç sahibi karar verir. Üç eylem vardır: düzelt ve kontrollü yeniden gönder (idempotency ve sıra doğrulanır; toplu gönderim önce küçük bir örnekle), tamamla veya telafi et (kısmi başarıda, önceden yazılmış iş kuralına göre), atla veya iptal et (iş tarafına bildirilir). Sınır: iş verisi normal iş işlemleriyle düzeltilir, veri tabanına doğrudan müdahale edilmez. Bitişte denetim izi mesaj kimliği ve iş anahtarını, her durum değişikliğini, otomatik tekrarları, durdurma kararını ve müdahaleyi kaydeder; düzenli mutabakat iki taraftaki sayı, tutar veya anahtarları karşılaştırarak hata kayıtlarında görünmeyen kayıpları ortaya çıkarır. Diyagramdaki tek döngü otomatik tekrar döngüsüdür ve sınırlıdır. Mobilde diyagram dört sıralı panelde okunur: 1/4 mesaj ve hata sınıfı, 2/4 durum kontrolü ve idempotency, 3/4 sınırlı tekrar ve durdurma, 4/4 insan kararı, denetim izi ve mutabakat. Künye: Castintech, D3, Eylül 2026; teknik anlatım diyagramı, SAP® ürün arayüzü değildir.
Tekrar işleme ve idempotency neden birlikte düşünülür?
Bir mesaj yeniden gönderildiğinde alıcı sistemin aynı işlemi ikinci kez uygulamaması gerekir. Idempotency, aynı isteğin birden fazla kez işlenmesinin tek sefer işlenmesiyle aynı etkiyi yaratması demektir. Bu özellik tasarlanmadan eklenen otomatik yeniden deneme, çift kayıt ve bu kayıtları düzeltmek için ek iş üretebilir.
Bunun için her iş işleminin tekrarlarda da değişmeyen bir kimliği olur ve alıcı sistem bu kimliği daha önce işleyip işlemediğini kontrol edebilir. Sıranın önemli olduğu akışlarda, eski bir mesajın daha yeni bir durumun üzerine yazılmasını engelleyen kural da ayrıca tanımlanır.
İzlenebilirlik için neler kaydedilmelidir?
Bir iş kaydının hangi sistemden çıktığı, hangi adımlardan geçtiği ve nerede durduğu, teknik log okumadan da cevaplanabilmelidir. Bunun için her mesaj bir ilişkilendirme kimliği ve iş anahtarı taşır, durum geçişleri zaman bilgisiyle kaydedilir ve hata kaydı düzeltmeyi yapacak kişinin anlayacağı bilgiyi içerir.
Asgari kayıt alanları:
- ilişkilendirme kimliği ve iş anahtarı
- kaynak ve hedef sistem
- durum ve durumun değiştiği zaman
- deneme sayısı
- hata sınıfı ve anlaşılır hata açıklaması
- müdahale eden kullanıcı ve yapılan işlem
Kişisel veya hassas verinin log ve izleme kayıtlarına gereksiz yere taşınmaması da izlenebilirlik tasarımının parçasıdır.
Gerçek ürün ekranı
Ekranı okumak için yatay kaydırın ya da görseli seçip tam boyutta açın.
Ekranda görülen Entegrasyon platformunun izleme ekranında tek bir mesajın işleme kaydı: durum (“Message processing completed successfully”), mesaj ve korelasyon kimliği, entegrasyon akışının adı ve günlük düzeyi.
Açıkladığı karar İzlenebilirlik için hangi alanların kaydedileceğine karar verilirken bu kayıttaki alanlar örnek alınabilir: mesaj kimliği tek bir iletimi, korelasyon kimliği ilişkili iletimleri birlikte izlemeyi sağlar.
Veri durumu Kayıt, SAP belgesindeki örnek entegrasyon akışına aittir; kaynak belgeye göre akış kukla (“dummy”) bir yükle çağrılır. Görünen kimlikler test kimlikleridir; müşteri ya da iş işlemi verisi yoktur.
Ürün: SAP Integration Suite (Cloud Integration) Kaynak: SAP-docs/btp-integration-suite © 2022-2023 SAP SE or an SAP affiliate company and btp-integration-suite contributors Lisans: CC BY 4.0, değiştirilmeden kullanılmıştır
Güvenlik ve yetki sınırları nerede çizilir?
Her entegrasyon kullanıcısı yalnız kendi akışının gerektirdiği işlemleri yapabilmelidir. Teknik kullanıcıya geniş yetki vermek kurulumu hızlandırır; ancak bir hata veya kötüye kullanım durumunda etkinin sınırını ortadan kaldırır. Yetki tasarımı; kimlik doğrulama yöntemini, kimlik bilgilerinin saklanmasını ve yeniden gönderim yetkisini birlikte kapsar.
- teknik kullanıcılar akış bazında ayrılır
- kimlik bilgileri kodda veya yapılandırma dosyasında açık metin olarak tutulmaz
- kimlik bilgisi yenileme sürecinin bir sahibi olur
- hata bekleyen mesajı görüntüleme, düzeltme ve yeniden gönderme yetkileri ayrı değerlendirilir
- verinin aktarım sırasında ve saklandığı yerde nasıl korunacağı belirlenir
Yaşam döngüsü ve değişiklik etkisi nasıl yönetilir?
Entegrasyon, iki tarafı da değişmeye devam eden bir sözleşmedir. Bir tarafta yapılan alan değişikliği, sürüm yükseltmesi veya süreç değişikliği diğer tarafı etkileyebilir. Bu nedenle her arayüzün sürümü, sahibi, tüketicileri ve değişiklik bildirimi yolu baştan kayda alınır; böylece bir değişiklik planlandığında kimlerin etkileneceği önceden görülür.
Hangi arayüzün kullanıldığı, yükseltme etkisini doğrudan belirler. SAP’nin clean core genişletme modelinde, yalnız yayımlanmış (released) arayüzleri ve genişletme noktalarını kullanan genişletmeler en üst seviyede (Level A) sınıflandırılır [2][3]. Bu model SAP Cloud ERP Private bağlamında tanımlanmıştır [3]; kendi ortamınıza nasıl uygulanacağı ürün ve sürüm kapsamına göre doğrulanmalıdır. Ayrıntı: Clean Core yaklaşımında genişletme kararı.
Ortamınıza göre neler doğrulanmalıdır?
Entegrasyonda kullanılabilecek araçlar ve servisler; kurulu ürüne, sürüme ve lisans kapsamına göre değişir. Bu nedenle bir aracın her ortamda bulunduğu varsayılmaz. Tasarıma başlamadan önce hangi arayüzlerin kullanılabilir olduğu, hangi ara katmanın kullanılacağı ve bu katmanı kimin işleteceği doğrulanır; doğrulanamayan kapsam ayrıca kayda geçirilir.
Örneğin SAP, SAP Business Technology Platform (SAP BTP) ürününü uygulama ve süreçleri entegre etmek, otomatikleştirmek ve genişletmek için bir platform olarak tanımlar [1]. Bir ortamda SAP BTP kullanılıp kullanılmayacağı ise kurumun ürün kapsamına, mimari kararlarına ve işletim modeline bağlıdır; her kurulumda bulunan bir bileşen değildir.
Uygulama öncesinde hangi belirsizlikler giderilmelidir?
Aşağıdaki sorulardan cevabı “bilmiyoruz” olanlar, uygulama başlamadan karar kaydına alınmalıdır:
- Her verinin doğru kaynağı hangi sistem?
- Akış senkron mu, asenkron mu; bu tercih neye dayanıyor?
- Aynı mesaj iki kez gelirse ne olur?
- Mesaj sırası önemli mi; bozulursa nasıl fark edilir?
- Zaman aşımında işlemin sonucu nasıl öğrenilir?
- Hangi hata otomatik olarak, hangisi insan kararıyla ele alınır?
- Hata bekleyen mesajları kim izler ve hangi yetkiyle müdahale eder?
- Hangi arayüz kullanılıyor; yükseltmede nasıl etkilenir?
- Kimlik bilgileri nerede tutuluyor ve kim yeniliyor?
- Bir tarafta değişiklik olduğunda diğer taraf nasıl haberdar oluyor?
Bu sayfa neyi iddia etmiyor?
Bu sayfa genel teknik açıklamadır. Belirli bir ürün sürümü, lisans kapsamı veya kurulum için uygulama talimatı değildir. Anlatılan yaklaşımın belirli bir süre, maliyet veya performans sonucu sağlayacağını iddia etmiyoruz. Ürüne ve sürüme bağlı bilgiler kaynak ve son doğrulama tarihiyle verilmiştir; kendi ortamınızda ayrıca doğrulanmalıdır.
Sık sorulan sorular
Entegrasyon tasarımına hangi belgeyle başlanmalı?
Akış bazında bir karar kaydıyla: hangi veri, hangi yönde, hangi tetikleyiciyle ve hangi sahiplik kuralıyla taşınıyor. Teknik şartname bu kaydın üzerine yazılır. Sıra tersine döndüğünde iş kuralları kodun içinde dağınık kalır ve sonradan bulunması zorlaşır.
Her entegrasyon asenkron mu olmalı?
Hayır. Asenkron yapı sistemler arasındaki bağımlılığı azaltır; ancak durum takibi, sıra yönetimi ve kullanıcıya sonradan bildirim gerektirir. Sonucun hemen görülmesi gereken ve karşı sistemin erişilebilirliğinin kabul edilebilir olduğu durumlarda senkron çağrı daha sade bir çözüm olabilir.
Hata bekleyen mesajları kim yönetmeli?
Teknik ekip mesajın neden durduğunu görebilir; ancak iş hatasında verinin nasıl düzeltileceğine çoğu zaman süreç sahibi karar verir. Bu yüzden hata kuyruğunun teknik sahibi ile iş kararının sahibi ayrı ayrı belirlenir.
Yükseltmenin entegrasyonları etkileyip etkilemeyeceği önceden anlaşılabilir mi?
Tamamen değil, ancak belirsizlik azaltılabilir. Kullanılan arayüzlerin listesi, her arayüzün yayımlanmış olup olmadığı ve tüketicileri biliniyorsa, yükseltme testlerinin nereye odaklanacağı önceden belirlenebilir.
Bu yaklaşım SAP dışındaki sistemlerde de geçerli mi?
Veri sahipliği, hata sınıfları, idempotency ve izlenebilirlik ilkeleri üründen bağımsızdır. Ürüne özgü olan kısım; kullanılabilecek arayüzler, araçlar ve bunların sürüme göre kapsamıdır.
İlgili rehberler ve sayfalar
- Entegrasyonlarda hata yönetimi ve güvenli tekrar işleme: hata sınıfları, yeniden deneme ve manuel müdahale sınırının ayrıntısı
- Clean Core yaklaşımında genişletme kararı: arayüz seçiminin yükseltme etkisi
- Dönüşüm öncesi teknik belirsizlikler: entegrasyonların dönüşüm planındaki yeri
- Özel kod envanteri ve teknik borç yaklaşımı
- Çalışma yaklaşımımız
Kaynakça
Metindeki köşeli parantez içindeki numaralar aşağıdaki kaynaklara işaret eder.
- 1
SAP Business Technology Platform — sap.com ürün sayfası.
https://www.sap.com/products/technology-platform.html
Kaynak tarihi: sayfada belirtilmemiş Son doğrulama: 23.09.2026
- 2
Extensibility — help.sap.com, SAP Cloud ALM uygulama yardımı.
https://help.sap.com/docs/cloud-alm/applicationhelp/extensibility
Kaynak tarihi: sayfada belirtilmemiş Son doğrulama: 23.09.2026
- 3
Clean core extensibility: Creating scalable, upgrade-ready extensions for the Autonomous Enterprise — SAP beyaz kitabı, bölüm 3.3 (s. 19–22).
https://www.sap.com/docs/download/2024/09/20aece06-d87e-0010-bca6-c68f7e60039b.pdf
Kaynak tarihi: belgede açık yayın tarihi yok; s. 52’de “(08/26)” ve “© 2026” ibaresi var Son doğrulama: 23.09.2026
Son doğrulama: 23 Eylül 2026
SAP is the trademark or registered trademark of SAP SE or its affiliates in Germany and in other countries.
Bu içerik Castintech tarafından bağımsız olarak hazırlanmıştır.
Bağımsızlık notu
- Castintech, SAP SE ile ortaklık, yetkilendirme, onay veya sponsorluk ilişkisi iddia etmez.
- SAP ve bu sayfada geçen SAP ürün adları, SAP SE’nin veya iştiraklerinin ticari markalarıdır.
- Castintech’in sunduğu çalışma, bağımsız teknik danışmanlık ve destek kapsamındadır.