Kurumsal Entegrasyon ve Ara Katman Mimarisi Rehberi

Kurumsal entegrasyon: ara katman mimarisi neden şart?

Kurumsal entegrasyon, şirketinizdeki ERP, CRM, e-ticaret sitesi, depo yönetimi (WMS), e-Fatura özel entegratörü, banka API’leri ve son dönemde yapay zekâ servisleri arasında verinin doğru, zamanında ve izlenebilir biçimde akmasını sağlayan mimari disiplindir. Sorun çoğu zaman aynı şekilde başlar: önce iki sistem doğrudan bağlanır, sonra üçüncüsü eklenir, birkaç yıl içinde kimsenin tamamını bilmediği bir “gece çalışan script’ler” ağı oluşur. Sipariş ERP’ye düşmez, fatura iki kez kesilir, banka mutabakatı Excel’de elle yapılır.

Bu rehber; birden fazla iş sistemini birbirine bağlamak zorunda kalan BT yöneticileri, ürün sahipleri ve teknik liderler için yazıldı. Noktadan noktaya bağlantı, API Gateway, mesaj kuyruğu (RabbitMQ), olay akışı (Kafka), ESB ve iPaaS seçeneklerini karşılaştırıyor; kanonik veri modeli, sürümleme, güvenlik, gözlemlenebilirlik ve sahiplik konularını somutlaştırıyor. Not: Burada anlattığımız ara katman, web isteklerini karşılayan uygulama middleware’i değildir; o konuyu middleware nedir yazımızda ayrıca ele aldık.

Kısaca

• Ara katman, sistemleri birbirine doğrudan değil ortak bir katman üzerinden bağlar; yeni bir sistem eklemek tüm ağı yeniden örmeyi gerektirmez.
• Senkron ihtiyaçlar (fiyat sorgusu, stok kontrolü) için API Gateway; asenkron işler (sipariş, fatura, mutabakat) için kuyruk veya olay akışı uygundur.
• Kanonik veri modeli ve açık sözleşmeler, sistem sayısı arttıkça dönüşüm maliyetini kontrol altında tutar.
• OAuth2, mTLS ve merkezi secret yönetimi olmadan entegrasyon katmanı en zayıf güvenlik halkası olur.
• Correlation id, dağıtık iz (trace), dead-letter kuyruğu ve yazılı runbook olmadan hiçbir entegrasyon “bitti” sayılmamalıdır.

• • •

Kurumsal entegrasyon ara katmanı nedir, neyi çözer?

Ara katman (integration middleware), iş sistemleri arasındaki tüm konuşmaların geçtiği, kuralları yazılı ve izlenebilir bir “trafik merkezidir”. Görevleri dört başlıkta toplanır: bağlantı (protokol ve kimlik doğrulama), dönüşüm (bir sistemin veri biçimini diğerinin anlayacağı biçime çevirme), yönlendirme (hangi mesaj hangi sisteme gider) ve güvenilirlik (yeniden deneme, sıralama, hata kuyruğu). Bu işler her uygulamanın içine dağıldığında aynı mantık defalarca yazılır ve hiçbiri aynı biçimde izlenmez.

Tipik sistem envanteri

Orta ölçekli bir üretici veya dağıtıcıda sık gördüğümüz tablo şudur: ERP (sipariş, stok, cari), CRM (müşteri, teklif), e-ticaret veya bayi portalı, WMS ya da depo uygulaması, e-Fatura ve e-Arşiv için özel entegratör, bir veya birkaç bankanın ödeme ve ekstre servisleri, kargo firması API’leri ve raporlama için bir veri ambarı. Son iki yılda bunlara belge sınıflandırma, e-posta özetleme veya müşteri asistanı gibi yapay zekâ servisleri eklendi. Her birinin kimlik doğrulama yöntemi, hata kodları ve hız sınırı farklıdır.

Ne zaman ayrı bir ara katman gerekir?

Projelerde en sık gördüğümüz sinyaller şunlardır: aynı müşteri kaydının üç sistemde üç farklı hâli var; bir entegrasyon hata verdiğinde bunu müşteri şikâyetinden öğreniyorsunuz; yeni bir pazaryeri bağlamak aylar sürüyor; “bu script’i kim yazdı?” sorusunun cevabı yok. Bu sinyallerden ikisi varsa, sorun tek tek bağlantılarda değil mimaridedir ve ara katman yatırımı geri dönüşü en hızlı adımlardan biridir.

• • •

Hangi entegrasyon modeli ne zaman seçilir?

Tek bir “doğru” teknoloji yoktur; doğru olan, iş akışının doğasına uyan modeldir. Aşağıdaki seçenekler birbirinin alternatifi olmaktan çok, aynı mimaride farklı katmanlarda birlikte kullanılır.

Noktadan noktaya bağlantı

İki sistem arasında doğrudan API çağrısı veya dosya aktarımıdır. İki üç sistem ve düşük hacim için hızlı ve ucuzdur. Ancak her yeni sistem, mevcut tüm sistemlerle ayrı bir bağlantı demektir; bağlantı sayısı sistem sayısıyla birlikte hızla büyür ve sonunda kimsenin haritasını çıkaramadığı bir ağ ortaya çıkar.

API Gateway

Microsoft’un Azure Architecture Center rehberine göre API Gateway, istemciler ile servisler arasında merkezi bir giriş noktası olarak çalışan bir ters vekil sunucudur; kimlik doğrulama, SSL sonlandırma, karşılıklı TLS (mTLS) ve hız sınırlama gibi ortak işleri servislerden alıp tek yerde toplayabilir. Bayi portalının stok sorgusu veya mobil uygulamanın fiyat çağrısı gibi senkron istek/yanıt trafiği için doğru araçtır; uzun süren işleri taşımak için değil.

Mesaj kuyruğu (RabbitMQ)

Gönderen mesajı kuyruğa bırakır, alıcı hazır olduğunda işler. RabbitMQ dokümantasyonu, tüketici onayları (acknowledgement) ve yayıncı onayları (publisher confirm) kullanıldığında en az bir kez teslim garantisi verildiğini, onaylar olmadan ise mesaj kaybının mümkün olduğunu belirtir. Sipariş oluşturma, fatura isteği, e-posta gönderimi gibi “bir kez yapılması gereken iş” komutları için idealdir.

Olay akışı (Kafka)

Apache Kafka, olayları topic’lerde kalıcı olarak saklayan dağıtık bir olay akışı platformudur. Kafka dokümantasyonuna göre olaylar tüketildikten sonra silinmez, saklama süresi topic bazında ayarlanır; aynı anahtara sahip olaylar aynı partition’a yazılır ve o partition’ı okuyan tüketici olayları yazıldıkları sırayla okur. Aynı “sipariş onaylandı” olayını ERP, WMS, raporlama ve AI servisinin bağımsız olarak dinlemesi gerektiğinde ya da geçmişi yeniden oynatmak istediğinizde güçlü bir seçenektir.

ESB (Enterprise Service Bus)

ESB, dönüşüm, yönlendirme ve orkestrasyonu merkezi bir veri yolunda toplar. Güçlüdür, fakat James Lewis ve Martin Fowler’ın 2014 tarihli mikroservis makalesi, iş kurallarının iletişim katmanına gömülmesine karşı çıkarak “akıllı uç noktalar, aptal borular” (smart endpoints and dumb pipes) ilkesini öne çıkarır. Pratikte ESB’nin riski, tüm değişikliklerin tek bir ekipten ve tek bir üründen geçmek zorunda kalmasıdır.

iPaaS (Integration Platform as a Service)

IBM’in tanımıyla iPaaS, farklı ortamlardaki uygulama ve veri kaynaklarını entegre etmek için kullanılan, bulut tabanlı ve self-servis araçlar bütünüdür; hazır konnektörler ve görsel eşleme araçlarıyla hızlı sonuç verir. Ağırlıklı olarak SaaS uygulamaları bağlıyorsanız mantıklıdır; ancak akış başına veya hacim bazlı fiyatlama, verinin hangi ülkede işlendiği ve platforma bağımlılık keşifte mutlaka sorulmalıdır.

Model	En uygun olduğu durum	Güçlü yanı	Dikkat edilmesi gereken
Noktadan noktaya	2–3 sistem, düşük hacim, kısa ömürlü ihtiyaç	Hızlı ve ucuz başlangıç	Sistem sayısı arttıkça bakımı katlanır
API Gateway	Senkron sorgular, dışa açılan API’ler	Güvenlik ve trafik politikası tek kapıda	Uzun süren işler için uygun değildir
Mesaj kuyruğu (RabbitMQ)	Komutlar, iş kuyrukları, fatura/sipariş işleme	Onaylı teslim, esnek yönlendirme, dead-letter	Tüketiciler tekrar eden mesajlara hazır olmalı
Olay akışı (Kafka)	Çok tüketicili olaylar, yüksek hacim, yeniden oynatma	Kalıcı log, partition bazında sıralama	Operasyon bilgisi ve şema yönetimi ister
ESB	Merkezi dönüşüm gerektiren eski (legacy) sistemler	Zengin dönüşüm ve protokol desteği	Tek ekip ve tek ürün darboğazı
iPaaS	SaaS ağırlıklı ortam, hazır konnektör ihtiyacı	Hızlı devreye alma, düşük kod	Maliyet modeli, veri konumu, bağımlılık

Bizim sık önerdiğimiz başlangıç düzeni şudur: dış dünyaya ve portallara açılan senkron trafik için bir API Gateway; sistemler arası iş akışları için bir mesaj kuyruğu; birden fazla tüketicinin aynı olaya ihtiyaç duyduğu noktada ise olay akışı. Hacim ve ekip olgunluğu arttıkça Kafka’nın payı büyüyebilir; ilk günden her şeyi olay akışına taşımak çoğu zaman gereksiz operasyon yüküdür.

• • •

Kanonik veri modeli ve dönüşüm nasıl tasarlanır?

Her sistemin “müşteri”, “ürün” ve “sipariş” tanımı farklıdır: ERP’de cari kodu, CRM’de e-posta, e-ticarette üye numarası birincil anahtar olabilir. Kanonik veri modeli, hiçbir uygulamaya ait olmayan ortak bir mesaj biçimi tanımlayıp her sistemin yalnızca bu biçime çevrilmesini önerir. Enterprise Integration Patterns kitabının ilgili bölümündeki örnek çarpıcıdır: altı uygulamanın birbirine doğrudan çevrildiği bir yapıda 30 dönüştürücü gerekirken, kanonik modelle bu sayı 12’ye iner.

Mapping ve dönüşüm kuralları

Eşleme kuralları kodun içinde kaybolmamalı; alan alan yazılı bir eşleme tablosu (kaynak alan, hedef alan, dönüşüm, zorunluluk, örnek değer) iş birimiyle birlikte onaylanmalıdır. Para birimi, KDV oranı, birim çevrimi ve tarih/saat dilimi gibi alanlar en sık hata çıkan yerlerdir. Dönüşüm katmanının birim testleri, gerçek sistemlerden alınmış anonimleştirilmiş örnek mesajlarla yazılmalıdır.

Sözleşme ve sürümleme

Ara katman, sistemler arasında bir sözleşme yayınlar. Yeni alan eklemek genellikle geriye uyumludur; alan silmek, anlamını değiştirmek veya zorunlu hâle getirmek ise kırıcı değişikliktir ve yeni bir sürümle (örneğin v2 topic’i veya uç noktası) yayınlanmalıdır. Sürümleme stratejisini ve uyumluluk kurallarını API tasarımında sözleşme ve uyumluluk yazımızda ayrıntılı anlattık. e-Fatura tarafında format güncellemeleri geldiğinde değişikliğin yalnızca adaptörde kalması da bu disiplinin ödülüdür; güncel örnek için GİB UBL-TR güncellemesi ve e-Fatura entegrasyonu yazısına bakabilirsiniz.

• • •

Entegrasyon güvenliği: OAuth2, mTLS ve secret yönetimi nasıl kurgulanır?

Entegrasyon katmanı, şirketin en hassas verilerinin (cari bilgiler, banka hareketleri, fatura içerikleri) geçtiği yerdir; bu nedenle kullanıcı arayüzünden daha sıkı korunmalıdır. Sistemden sisteme çağrılarda kullanıcı oturumu yoktur; kimlik, OAuth 2.0 istemci kimlik bilgileri ve kısa ömürlü erişim token’larıyla taşınmalıdır.

Karşılıklı TLS (mTLS)

Bankalar ve kritik iş ortaklarıyla yapılan bağlantılarda yalnızca sunucunun değil istemcinin de sertifikayla kendini kanıtladığı mTLS sık tercih edilir. IETF’nin 2020 tarihli RFC 8705 standardı, OAuth istemcilerinin mTLS ile kimlik doğrulamasını ve erişim token’larının istemci sertifikasına bağlanmasını tanımlar; böylece çalınan bir token başka bir makineden kullanılamaz.

Secret yönetimi ve en az yetki

• API anahtarları ve sertifikalar kodda veya yapılandırma dosyasında değil, bir secret kasasında tutulur; dönüşüm (rotasyon) takvimi yazılıdır.
• Her entegrasyonun kendi servis hesabı vardır; tek bir “admin” hesabın tüm sistemlere bağlanması kabul edilmez.
• Kişisel veri içeren alanlar loglarda maskelenir; hangi verinin hangi sisteme aktarıldığı KVKK envanterine yansıtılır.
• Dışa açılan uç noktalarda hız sınırı ve IP izin listesi API Gateway’de uygulanır.

• • •

Gözlemlenebilirlik ve hata yönetimi nasıl kurulur?

“Entegrasyon çalışıyor mu?” sorusunun cevabı bir panelde görülmüyorsa, cevap genellikle hayırdır. Her mesaj ve istek, uçtan uca izlenebilir bir kimlik taşımalıdır: correlation id. OpenTelemetry dokümantasyonu, varsayılan yayıcının W3C TraceContext spesifikasyonundaki traceparent başlığını kullandığını ve bu sayede servisler arası çağrıların aynı iz (trace) altında birleştirilebildiğini anlatır. Kuyruk mesajlarında da aynı bağlam, mesaj başlıklarında taşınmalıdır.

Dead-letter kuyruğu (DLQ)

Bazı mesajlar hiçbir zaman işlenemez: eksik zorunlu alan, kapatılmış bir cari, geçersiz vergi numarası. Enterprise Integration Patterns bu durumu Dead Letter Channel olarak tanımlar. RabbitMQ’da bir mesaj; tüketici tarafından yeniden kuyruğa alınmadan reddedildiğinde, TTL süresi dolduğunda, kuyruk uzunluk sınırı aşıldığında veya quorum kuyruklarda teslim sınırı geçildiğinde dead-letter exchange’e yönlendirilebilir. DLQ bir çöp kutusu değil, sahibi ve alarmı olan bir iş listesi olmalıdır.

Yeniden deneme ve idempotency

Ağ hataları ve geçici kesintiler kaçınılmazdır; yeniden deneme şarttır, ama kontrolsüz yeniden deneme aynı faturanın iki kez kesilmesi demektir. Üstel geri çekilme, jitter, idempotency anahtarı ve transactional outbox desenlerini outbox pattern, idempotency ve retry rehberimizde kod örnekleriyle anlattık. Metrik, log ve iz üçlüsünün kurulumu için de kurumsal uygulamalarda gözlemlenebilirlik yazımıza göz atabilirsiniz.

• • •

Sahiplik, runbook ve yapay zekâ servisleri

Entegrasyonlar teknik olarak doğru kurulsa bile sahipsiz kaldığında çürür. Her akışın bir iş sahibi (örneğin muhasebe müdürü) ve bir teknik sahibi olmalıdır. Runbook; akışın amacını, bağlı sistemleri, olası hata türlerini, DLQ’daki mesajın nasıl inceleneceğini ve yeniden işleneceğini, hangi durumda kimin aranacağını adım adım anlatır. Gece 02.00’de nöbetçinin ihtiyacı olan şey mimari şema değil, bu sayfadır.

Yapay zekâ servisleri bu tabloya yeni bir boyut ekler: yanıt süreleri değişkendir, maliyet çağrı başına oluşur ve çıktı her zaman deterministik değildir. Bu nedenle AI çağrılarını da ara katmandan geçirmek, kota, maliyet takibi, kişisel veri maskeleme ve yedek modele geçiş gibi politikaları tek yerde uygulamayı sağlar. Konunun üretim tarafını yapay zekâ ajanlarını üretime almak yazımızda ele aldık.

Noktadan noktaya bağlantılar zamanla bu panele benzer: çalışır, ama hangi kablonun nereye gittiğini kimse bilmez.

Fatura, mutabakat ve banka hareketleri: entegrasyon hatasının en pahalıya patladığı muhasebe masası.

Akış sahipleri, hata senaryoları ve runbook’lar canlıya geçişten önce birlikte çizilir.

• • •

Kurumsal entegrasyon projesi nasıl planlanır, ne kadar sürer?

Süreyi teknoloji değil, bağlanacak sistemlerin sayısı ve hazırlığı belirler. Karşı tarafın test ortamı var mı, API dokümantasyonu güncel mi, erişim izinleri kaç haftada çıkıyor? Bu soruların cevabı takvimin en uzun kolunu oluşturur. Tek bir akışla (örneğin e-ticaret siparişinin ERP’ye aktarılması) başlayan bir pilot, birkaç sprintte canlıya alınabilir; çok sistemli bir programın ise aşamalara bölünmesi gerekir.

1. Keşif: sistem envanteri, akış haritası, hacimler, hata senaryoları ve sahipler.
2. Pilot akış: en çok acı veren tek akış uçtan uca; izleme ve DLQ dahil.
3. Platformlaştırma: ortak kimlik doğrulama, kanonik model, şablon adaptörler.
4. Yaygınlaştırma: kalan akışların öncelik sırasıyla taşınması ve eski script’lerin kapatılması.

Kontrol listesi: entegrasyona başlamadan önce

• Bağlanacak tüm sistemler, sahipleri ve test ortamları listelendi mi?
• Her akış için senkron mu asenkron mu olacağı ve kabul edilebilir gecikme yazıldı mı?
• Müşteri, ürün, sipariş ve fatura için kanonik alanlar ve eşleme tablosu onaylandı mı?
• Kimlik doğrulama yöntemi (OAuth2, mTLS, API anahtarı) ve secret saklama yeri belirlendi mi?
• Correlation id, dağıtık iz ve temel metrikler (kuyruk derinliği, hata oranı, gecikme) tasarımda var mı?
• Yeniden deneme politikası, idempotency anahtarı ve DLQ süreci tanımlandı mı?
• Sözleşme sürümleme kuralları ve kırıcı değişiklik bildirimi süreci yazıldı mı?
• Her akış için runbook, nöbet ve destek seviyesi (SLA) kararlaştırıldı mı?

• • •

Aksiyon Soft nasıl yardımcı olur?

API ve entegrasyon hizmetimizde ERP, CRM, e-ticaret, WMS, e-Fatura özel entegratörü, banka ve yapay zekâ servisleri arasındaki akışları tek bir ara katmanda topluyoruz. Daha geniş bir dönüşüm programının parçasıysa, entegrasyon katmanını kurumsal yazılım çözümleri kapsamında portal ve operasyon ekranlarıyla birlikte ele alıyoruz. Mimari örneği API ve veri entegrasyon platformu çözüm sayfamızda inceleyebilirsiniz.

Çalışma modelimiz nettir: keşifte sistem envanteri ve akış haritası çıkarılır; en kritik akışla MVP kurulur; her sprint sonunda çalışan entegrasyon demo edilir; canlıya geçişten sonra hypercare dönemi ve ardından SLA’lı bakım gelir. Merkezimiz Samsun’dadır; Türkiye genelindeki ekiplerle uzaktan çalışıyor, projenin gerektirdiği kabul ve canlıya geçiş adımlarında planlı ziyaret yapıyoruz.

Sık sorulan sorular

Kurumsal entegrasyon için mutlaka Kafka gerekir mi?

Hayır. Hacim orta düzeydeyse ve her mesajın tek bir tüketicisi varsa, RabbitMQ gibi bir mesaj kuyruğu çoğu zaman daha basit ve yeterlidir. Kafka; aynı olayı birden fazla sistemin dinlediği, yüksek hacimli veya geçmişin yeniden oynatılması gereken senaryolarda öne çıkar.

ESB artık kullanılmıyor mu?

Kullanılıyor; özellikle eski protokollerle çalışan sistemlerin bulunduğu kurumlarda ESB hâlâ iş görür. Asıl risk, iş kurallarının veri yoluna gömülmesi ve her değişikliğin tek bir ekipten geçmek zorunda kalmasıdır. Yeni projelerde kuralları uç noktalarda tutan daha hafif bir ara katman genellikle daha sürdürülebilirdir.

iPaaS mı, özel geliştirilmiş ara katman mı?

Bağlayacağınız sistemlerin çoğu hazır konnektörü olan SaaS ürünleriyse iPaaS hızlı sonuç verir. Yerel ERP’ler, özel entegratörler, sahaya özgü iş kuralları ve veri konumu gereksinimleri ağır basıyorsa özel ara katman daha esnektir. Keşifte iki seçeneğin toplam sahip olma maliyetini yan yana koymak en sağlıklı yoldur.

Entegrasyon katmanında kişisel veriler nasıl korunur?

Aktarılan alanlar veri envanterinde işaretlenir, gereksiz kişisel veri hiç taşınmaz, loglarda maskeleme uygulanır ve sistem hesapları en az yetki ilkesiyle tanımlanır. Bağlantılar TLS ile, kritik iş ortaklarında mTLS ile korunur.

Mevcut script’leri bir anda kapatmak gerekir mi?

Gerekmez ve önermeyiz. Yeni ara katman önce en kritik akışı devralır; eski script bir süre gölge modda çalışıp sonuçlar karşılaştırılır, tutarlılık doğrulandığında kapatılır. Bu kademeli geçiş, canlı operasyonu riske atmadan modernizasyon sağlar.

Bir entegrasyon akışını canlıya almak ne kadar sürer?

Tek bir akış için, karşı sistemin test ortamı ve erişimleri hazırsa birkaç sprint yeterli olabilir. En büyük gecikme kaynağı genellikle teknik geliştirme değil, dış taraf erişimleri ve test verisidir; bu yüzden takvim keşif sonrasında yazılı varsayımlarla paylaşılır.

Projenizi konuşalım

Sistemleriniz arasında elle taşınan veri, tekrar eden fatura hataları veya kimsenin sahiplenmediği script’ler varsa, kısa bir keşif görüşmesiyle başlayalım. İletişim formundan bağlanacak sistemleri ve en çok sorun çıkaran akışı yazmanız yeterli; size uygun ara katman mimarisini ve ilk pilot akışı birlikte netleştirelim.

Kaynaklar

• Enterprise Integration Patterns — Canonical Data Model (Gregor Hohpe, Bobby Woolf)
• Enterprise Integration Patterns — Dead Letter Channel
• martinfowler.com — James Lewis, Martin Fowler: Microservices (25 Mart 2014)
• Apache Kafka — Introduction
• RabbitMQ — Reliability Guide
• RabbitMQ — Dead Letter Exchanges
• Microsoft Learn, Azure Architecture Center — API gateways
• IETF — RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (2020)
• OpenTelemetry — Context propagation
• IBM — What is iPaaS? (güncelleme: 6 Nisan 2026)