Teknik rehber
Entegrasyonlarda hata yönetimi ve güvenli tekrar işleme nasıl tasarlanır?
Güvenli tekrar işleme, hataları sınıflarına ayırmakla başlar: yalnız geçici teknik hatalar ve sonucu bilinmeyen durumlar otomatik tekrara uygundur; bu tekrarın zarar vermemesi için alıcı tarafın aynı işlemi ikinci kez uygulamaması gerekir. Kalıcı hatalar ve iş hataları ise insan kararına, kimin karar vereceği ise önceden yazılmış bir sınıra bağlanır.
- Hazırlayan Castintech
- Son doğrulama 23 Eylül 2026
- 10 dk okuma
- Kaynakça
Bu rehberde
Bölümler
Kapsam. Bu rehber ürüne özgü değildir. SAP® yazılımıyla kurulan entegrasyonlar dahil, sistemler arasında mesaj veya çağrıyla çalışan akışlar için genel bir mühendislik çerçevesidir. Kullanılacak ara katman, kuyruk ve izleme araçlarının yetenekleri ürün ve sürüme göre değişir; bu rehber belirli bir aracı anlatmaz. Buradaki ilkeler SAP’ye atfedilmez.
Hata sınıfları nasıl ayrılır?
Hatalar, tekrar denendiğinde ne olacağına ve kimin karar vermesi gerektiğine göre ayrılır. Aynı hata mesajı farklı sınıflara düşebilir; bu yüzden sınıflandırma, hata metnine değil, hatanın nedenine ve tekrarın sonucuna göre yapılır. Her akış için sınıflar ve her sınıfın ele alınış biçimi tasarım belgesinde yazılı olur.
| Sınıf | Örnek | Otomatik tekrar | Karar veren |
|---|---|---|---|
| Geçici teknik hata | Kısa ağ kesintisi, geçici kaynak yetersizliği, kilitli kayıt | Evet, sınırlı | Politika (otomatik) |
| Kalıcı teknik hata | Hatalı yapılandırma, geçersiz kimlik bilgisi, eksik alan eşlemesi | Hayır | Teknik ekip |
| İş hatası | Kapalı bir döneme kayıt, iş kuralına uymayan değer | Hayır | Süreç sahibi |
| Sonucu belirsiz durum | Zaman aşımı, bağlantının cevaptan önce kopması | Önce durum kontrolü; ancak idempotent ise tekrar | Politika, gerekirse teknik ekip |
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.
Teknik hata ile iş hatası neden ayrı ele alınır?
Çünkü sahipleri ve çözüm yolları farklıdır. Teknik hata, entegrasyonun kendisinde düzeltilir; iş hatası ise verinin veya sürecin kendisinde. İkisi karıştırıldığında ya iş hatası için anlamsız tekrarlar yapılır, ya da teknik ekip iş verisini kendi başına düzeltmeye başlar. İkinci durum, denetim ve sorumluluk açısından daha ciddi bir sorundur.
İş hatası mesajı, süreç sahibinin anlayacağı dilde yazılmalıdır: hangi kayıt, hangi kural, ne yapılması gerekiyor. Teknik ayrıntı kayıtta kalır, ancak iş kararı için gerekli bilgi ondan ayrı ve açık olarak gösterilir.
Idempotency nasıl sağlanır?
Idempotency, aynı isteğin birden fazla kez işlenmesinin tek sefer işlenmesiyle aynı amaçlanan etkiyi yaratmasıdır. HTTP standardı (RFC 9110) bu özelliği tanımlar ve idempotent olmayan isteklerin, gerçekten idempotent oldukları bilinmedikçe otomatik olarak yeniden denenmemesi gerektiğini belirtir [1]. Entegrasyonda bu özellik genellikle alıcı tarafta tasarlanır.
Kullanılan başlıca teknikler:
- İşlem kimliği: gönderen taraf her iş işlemine tekrarlarda değişmeyen bir kimlik verir; alıcı bu kimliği saklar ve aynı kimlik yeniden geldiğinde işlemi tekrarlamak yerine önceki sonucu döndürür.
- Doğal iş anahtarı: belge numarası gibi zaten benzersiz olan bir anahtar, alıcı tarafta çift kaydı engelleyen kural olarak kullanılır.
- Sürüm kontrolü: güncelleme mesajları kaydın sürümünü taşır; alıcı, beklediği sürümden eski bir değişikliği uygulamaz.
İşlem kimliğinin ne kadar süre saklanacağı da bir tasarım kararıdır. Süre, olası en geç tekrarın geleceği zamanı kapsamalıdır; kapsamazsa geç gelen bir tekrar yeni işlem gibi işlenebilir.
Sıra ve tekrar birlikte nasıl yönetilir?
Gerçekçi varsayım, bir mesajın “en az bir kez” teslim edileceğidir: tekrarlar beklenir ve tasarım buna göre yapılır. Sıra ise çoğu zaman bütün akış için değil, aynı iş nesnesi için önemlidir; örneğin aynı belgenin oluşturma ve değişiklik mesajları. Sıra gereksinimi bu düzeyde tanımlanırsa paralel işleme ile sıra koruma birlikte kurulabilir.
Sıra bozulduğunda bunun fark edilmesi için mesajlar bir sıra numarası veya sürüm bilgisi taşır. Alıcı, eski bir mesajı daha yeni bir durumun üzerine yazmak yerine reddeder veya bekletir. Bu kural yazılı değilse sıra hatası çoğu zaman yalnız veri tutarsızlığı fark edildiğinde, yani geç anlaşılır.
Yeniden deneme politikası nasıl belirlenir?
Yeniden deneme yalnız geçici teknik hatalar ve idempotent işlemler için uygulanır. Politika, karşı sistemin toparlanma süresine ve işin gecikmeye ne kadar dayanabileceğine göre belirlenir. Her tekrarın hemen yapılması, zaten zorlanan bir sisteme ek yük bindirir; bu yüzden denemeler arasındaki bekleme süresi giderek artırılır.
| Parametre | Neden gerekir | Karar sorusu |
|---|---|---|
| En fazla deneme sayısı | Sonsuz döngüyü önler | Kaç denemeden sonra insan bakmalı? |
| Artan bekleme süresi | Karşı sisteme toparlanma zamanı tanır | Karşı sistem genellikle ne kadar sürede toparlanıyor? |
| Rastgele sapma | Birçok mesajın aynı anda tekrar edilmesini önler | Aynı anda kaç mesaj tekrar kuyruğunda olabilir? |
| Toplam süre sınırı | İşin kabul edilebilir gecikmesini korur | İş, bu mesajın sonucunu en geç ne zaman görmeli? |
| Devre kesici | Karşı sistem çökmüşken tekrarları durdurur | Hangi hata oranında denemeler durdurulmalı? |
Sonucu belirsiz durumlarda önce durum kontrolü tercih edilir: karşı sisteme işlemin gerçekleşip gerçekleşmediği sorulur. Durum sorgulanamıyor ve işlem idempotent değilse otomatik tekrar yapılmaz; mesaj insan incelemesine ayrılır.
Otomatik tekrar hangi durumda durdurulur?
Otomatik tekrar, sorunu çözmediği açık olduğu anda durdurulmalıdır; aksi hâlde hem karşı sisteme yük bindirir hem de gerçek hatayı kayıtların arasında gizler. Durdurma ölçütleri, deneme politikasıyla birlikte önceden yazılır ve izleme ekranında görünür olur. Bir ölçüt tetiklendiğinde mesajlar kaybolmaz; insan kararı bekleyen duruma geçer.
Başlıca durdurma ölçütleri:
- deneme sayısı veya toplam süre sınırı aşıldı
- aynı mesaj her denemede aynı kalıcı hata sınıfını üretiyor
- karşı sistemde duyurulmuş bir bakım penceresi var
- belirli bir süre içindeki hata oranı devre kesici eşiğini geçti
- sıra kuralı ihlal edildi veya bir mesajın daha yeni bir durumu ezme riski oluştu
- veri bütünlüğünden şüphe edildi; örneğin aynı iş anahtarı için beklenmeyen ikinci bir kayıt görüldü
Durdurma kararının kendisi de kaydedilir: hangi ölçüt, ne zaman ve hangi mesajları etkiledi. Tekrar yeniden başlatılmadan önce ölçütü tetikleyen nedenin ortadan kalktığı doğrulanır.
Manuel müdahalenin sınırı nerede çizilir?
Manuel müdahale, otomatik politikanın bittiği yerde başlar ve kendi kurallarına sahip olur. Hata bekleyen bir mesajı kimin görebileceği, kimin düzeltebileceği, kimin yeniden gönderebileceği ve kimin iptal edebileceği ayrı ayrı tanımlanır. Her müdahale; kim, ne zaman, ne yaptı ve neden bilgisiyle kaydedilir.
Sınırı belirleyen kurallar:
- İş verisindeki düzeltmeler, veri tabanına doğrudan müdahaleyle değil, sistemin normal iş işlemleriyle yapılır.
- “Olduğu gibi yeniden gönder”, “düzelt ve yeniden gönder” ve “atla” ayrı işlemlerdir ve ayrı yetki gerektirebilir.
- Toplu yeniden gönderim, idempotency ve sıra koşulları doğrulanmadan yapılmaz; mümkünse önce küçük bir örnekle denenir.
- Atlanan veya iptal edilen her mesaj için iş tarafına bildirim yapılır.
Veri bütünlüğü nasıl korunur?
Bir iş işlemi birden fazla adımdan oluşuyorsa kısmi başarı mümkündür: ilk adım tamamlanmış, ikincisi başarısız olmuş olabilir. Tasarım, bu durumda sistemi tutarlı bir noktaya taşıyacak yolu tanımlar: kalan adımın tamamlanması veya tamamlanan adımın telafi edici bir işlemle geri alınması. Hangisinin seçileceği iş kuralına bağlıdır ve önceden yazılır.
Kayıt ile mesaj gönderiminin tutarlı kalması için, gönderilecek mesaj iş kaydıyla aynı işlem birimi içinde saklanıp ardından ayrı bir adımda gönderilebilir. Böylece kayıt oluştuğu hâlde mesajın hiç gönderilmemesi veya kayıt geri alındığı hâlde mesajın gitmesi önlenir.
Hiçbir tasarım bütün tutarsızlıkları önleyemez. Bu yüzden sistemler arasında düzenli bir mutabakat yapılır: belirli bir dönemdeki kayıtların sayısı, tutarı veya anahtarları iki tarafta karşılaştırılır. Mutabakat, hata kayıtlarında görünmeyen kayıpları ortaya çıkarır.
Güvenlik ve denetim izi nasıl kurulur?
Hata kayıtları ve bekleyen mesajlar çoğu zaman iş verisi içerir. Kişisel veya hassas veri log kayıtlarında maskelenir, saklama süresi belirlenir ve bu kayıtlara erişim yetkiyle sınırlanır. Yeniden gönderme yetkisi, veri değiştirme yetkisi kadar dikkatle verilir; çünkü yanlış bir yeniden gönderim de veriyi değiştirmekle aynı etkiyi yaratabilir.
Denetim izi en az şunları içerir: mesajın kimliği ve iş anahtarı, her durum değişikliği ve zamanı, otomatik tekrarlar, manuel müdahaleyi yapan kullanıcı, yapılan işlem ve gerekçesi. Bu iz, bir sorunun kök nedenini ararken de, bir denetim sorusunu cevaplarken de aynı kaynağı kullanmayı sağlar.
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 Tekrar işleme kararında hangi iletimin yeniden gönderildiği bu tür bir kayıtla gösterilir; denetim izi, mesaj kimliği ve korelasyon kimliği üzerinden kurulur.
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
Entegrasyonun işletimi operasyon ekibine nasıl devredilir?
Bir entegrasyon canlıya alındığında, onu tasarlayan ekip değil, işleten ekip ilk müdahaleyi yapar. Devir, işletim ekibinin tasarım belgesini okumadan da doğru karar verebileceği bir işletim notuyla yapılır. Not; hangi uyarının ne anlama geldiğini, ilk müdahale adımlarını, kime ne zaman haber verileceğini ve hangi işlemlerin yalnız teknik sahip veya süreç sahibi tarafından yapılabileceğini yazar.
Devir tek seferlik bir toplantı değildir. İlk haftalarda görülen her yeni hata türü işletim notuna eklenir ve hata sınıflarından birine bağlanır. Sınıfı belirlenemeyen hata tasarım ekibine geri döner. Böylece işletim bilgisi zamanla bir kişinin hafızasında değil, ortak bir belgede birikir.
Karar tablosu
| Sınıf | Otomatik tekrar | Tekrar koşulu | Sonraki adım | Kayıt |
|---|---|---|---|---|
| Geçici teknik | Evet | İşlem idempotent, deneme ve süre sınırı aşılmadı | Sınır aşılırsa teknik incelemeye ayır | Her deneme |
| Kalıcı teknik | Hayır | — | Teknik düzeltme, ardından kontrollü yeniden gönderim | Düzeltme ve gönderim |
| İş hatası | Hayır | — | Süreç sahibinin kararı; iş işlemiyle düzeltme | Karar ve düzeltme |
| Sonucu belirsiz | Koşullu | Önce durum kontrolü; idempotent değilse tekrar yok | Durum netleşene kadar beklet | Kontrol ve sonuç |
Sık yapılan yanlış varsayımlar
- “Her hata yeniden denenirse sonunda geçer.” Kalıcı hatalar ve iş hataları tekrarla geçmez; yalnız yük ve kayıt kalabalığı üretir.
- “Zaman aşımı, işlemin gerçekleşmediği anlamına gelir.” Gerçekleşmiş olabilir. Durum kontrol edilmeden yapılan tekrar çift kayıt üretebilir.
- “Mesajlar gönderildiği sırayla gelir.” Tekrarlar ve paralel işleme sırayı bozabilir; sıra gerekiyorsa tasarlanmalıdır.
- “Hata yoksa veri tutarlıdır.” Kaybolan bir mesaj hata kaydı bırakmayabilir; tutarlılık mutabakatla doğrulanır.
- “Toplu yeniden gönderim her zaman güvenlidir.” Idempotency ve sıra koşulları doğrulanmadan yapılan toplu gönderim, tek bir hatayı çok sayıda kayda yayabilir.
Kontrol listesi
- Her akış için hata sınıfları ve ele alınış biçimleri yazıldı
- İş hatası mesajları süreç sahibinin anlayacağı dilde tasarlandı
- Alıcı tarafta idempotency yöntemi ve işlem kimliği saklama süresi belirlendi
- Sıra gereksinimi iş nesnesi düzeyinde tanımlandı; eski mesaj kuralı yazıldı
- Yeniden deneme parametreleri (deneme sayısı, bekleme, sapma, süre sınırı, devre kesici) belirlendi
- Sonucu belirsiz durumlar için durum kontrolü yolu tanımlandı
- Otomatik tekrarı durdurma ölçütleri yazıldı ve izleme ekranında görünür
- Görüntüleme, düzeltme, yeniden gönderme ve iptal yetkileri ayrıldı
- Kısmi başarı için tamamlama veya telafi yolu yazıldı
- Düzenli mutabakat tanımlandı
- Log maskeleme, saklama süresi ve denetim izi alanları belirlendi
- İşletim notu hazırlandı; ilk haftalarda yeni hata türleriyle güncellenecek
Sınır notları
Bu rehber ürüne özgü olmayan genel mühendislik açıklamasıdır. İdempotent yöntem tanımı IETF RFC 9110’a dayanır; diğer ilkeler genel mühendislik bilgisi ve Castintech’in değerlendirme çerçevesidir ve SAP’ye atfedilmez. Kullanılacak araçların bu ilkeleri hangi ölçüde desteklediği ürün ve sürüm kapsamına göre doğrulanmalıdır. Belirli bir hata oranı veya kesinti süresi sonucu iddia etmiyoruz.
Sık sorulan sorular
Bir mesaj kaç kez yeniden denenmeli?
Her akış için doğru tek bir sayı yoktur. Sayı, karşı sistemin genellikle ne kadar sürede toparlandığına ve işin bu mesajın sonucunu en geç ne zaman görmesi gerektiğine göre belirlenir. Toplam süre sınırı, deneme sayısından daha anlamlı bir kontrol noktasıdır.
Hata bekleyen bir mesaj ne kadar bekleyebilir?
Bu süre iş tarafından belirlenir: sonucun gecikmesi hangi noktada bir iş sorunu yaratır? Bu süre, en eski bekleyen mesajın yaşı için bir uyarı sınırı olarak izlenir ve sınır aşıldığında sorumlu kişiye bildirim yapılır.
İş hatasını teknik ekip düzeltebilir mi?
Teknik ekip düzeltmeyi hazırlayabilir ve uygulayabilir; ancak verinin nasıl düzeltileceğine süreç sahibi karar verir. Düzeltme, sistemin normal iş işlemleriyle yapılır ve kaydı tutulur.
Bir entegrasyonun sağlıklı çalıştığı nasıl anlaşılır?
Hata sayısının düşük olması tek başına yeterli değildir. Bekleyen mesaj sayısı, en eski bekleyen mesajın yaşı, sınıfa göre hata dağılımı ve düzenli mutabakat sonuçları birlikte izlendiğinde sağlık hakkında güvenilir bir tablo oluşur.
Idempotency her akış için gerekli mi?
Otomatik tekrar veya toplu yeniden gönderim yapılacak her akış için gereklidir. Tekrarın hiç yapılmayacağı ve her hatanın insan kararıyla ele alınacağı akışlarda da, yanlışlıkla yapılan bir yeniden gönderimin etkisini sınırladığı için önerilir.
İlgili sayfalar ve rehberler
- Entegrasyon yaklaşımı: sistem sınırı, veri sahipliği ve entegrasyon kararlarının genel çerçevesi
- Dönüşüm öncesi teknik belirsizlikler: entegrasyonların dönüşüm planındaki yeri
- Performans incelemesinde kanıt toplama: entegrasyon gecikmelerinin ölçümle incelenmesi
- Tüm teknik rehberler
Kaynakça
Metindeki köşeli parantez içindeki numaralar aşağıdaki kaynaklara işaret eder.
- 1
RFC 9110: HTTP Semantics — IETF, Haziran 2022, bölüm 9.2.2 “Idempotent Methods”.
https://www.rfc-editor.org/rfc/rfc9110.html
Kaynak tarihi: Haziran 2022 Son doğrulama: 23.09.2026
Bu rehberdeki diğer ilkeler genel mühendislik bilgisidir; belirli bir ürün belgesine dayanmaz ve SAP’ye atfedilmez.
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.