Sistem Entegrasyonu: POS, E-ticaret, Banka ve E-fatura Rehberi

Entegrasyon Mimarisi Temelleri

Birbirinden habersiz çalışan sistemleri tek bir omurgada buluşturan yapı

Sistem entegrasyonu mimarisi, ayrı ayrı tasarlanmış yazılımların birbiriyle veri ve işlem paylaşmasını mümkün kılan teknik iskelettir. Pratikte bu iskelet birkaç parçadan oluşur:

Mimari Bileşenler

• Kaynak sistemler (Source): Veriyi üreten sistemler (POS, e-ticaret, üretim)
• Hedef sistemler (Target): Veriyi tüketen sistemler (ERP, muhasebe, raporlama)
• Entegrasyon katmanı: Sistemler arasında veri taşıma, dönüştürme ve yönetme
• Veri formatları: JSON, XML, CSV, EDIFACT gibi standartlar
• İletişim protokolleri: HTTP/HTTPS, FTP/SFTP, AS2, AMQP, MQTT

Entegrasyon Topolojileri

1. Point-to-Point (Noktadan Noktaya)

Her sistem birbirine doğrudan bağlanır. Bir avuç sistemle uğraşırken pratiktir, ama sistem sayısı arttıkça iş çığırından çıkar: N sistem için N*(N-1)/2 bağlantı bakmanız gerekir.

2. Hub-and-Spoke (Merkez ve Kol)

Tüm sistemler merkezi bir hub’a, yani middleware’e bağlanır. Yönetim rahatlar; ama o hub tek arıza noktasına dönüşür. Merkez düşerse her şey birden durur.

3. Enterprise Service Bus (ESB)

Dağıtık bir mimari üzerinden mesaj yönlendirme, dönüşüm ve orkestrasyon sağlar. Büyük ölçekli kurumsal sistemlerin işini görür.

4. Event-Driven Architecture (EDA)

Sistemler olay yayınlar ve birbirinin olaylarını dinler. Geniş çapta ölçeklenebilirlik ve gevşek bağlılık getirir.

API Entegrasyonu: REST, SOAP, GraphQL

Modern entegrasyonun büyük kısmı API’lerin üzerinde yükselir

API, sistemlerin birbirleriyle programatik olarak konuşmasını sağlayan arabirimdir. Her senaryonun tercih ettiği API türü de farklıdır:

REST API

REST, HTTP üzerine kurulu, durum tutmayan (stateless) bir yaklaşımdır. Bugün en sık karşılaştığınız API tipi budur.

• HTTP metodları: GET (okuma), POST (oluşturma), PUT/PATCH (güncelleme), DELETE (silme)
• Veri formatı: Genellikle JSON, bazen XML
• Avantajlar: Basitlik, yaygın destek, kolay debug
• Kullanım alanları: E-ticaret, mobil uygulamalar, SaaS entegrasyonları

SOAP API

SOAP, XML tabanlı ve kuralları katı bir protokoldür. Kurumsal sistemlerde ve bankacılıkta hâlâ karşınıza çıkar.

• Veri formatı: XML (WSDL ile tanımlı)
• Güvenlik: WS-Security ile gelişmiş güvenlik
• Avantajlar: Transaction desteği, ACID uyumluluk, sıkı güvenlik
• Kullanım alanları: Banka entegrasyonları, kurumsal ERP sistemleri

GraphQL

Facebook’un geliştirdiği bir sorgu dili ve çalışma ortamı. Burada veriyi hangi alanlarıyla istediğine istemci karar verir.

• Özellik: Tek endpoint, esnek sorgular
• Avantajlar: Over-fetching/under-fetching önleme, versiyon yönetimi kolaylığı
• Kullanım alanları: Modern frontend uygulamaları, mobil API’ler

API Entegrasyonu En İyi Pratikleri

• Her zaman HTTPS kullanın, HTTP asla
• API anahtarları veya OAuth 2.0 ile kimlik doğrulama yapın
• Rate limiting (hız sınırlaması) uygulayarak istismarı önleyin
• Versiyon yönetimi ile geriye dönük uyumluluk sağlayın (v1, v2)
• Kapsamlı hata kodları ve mesajları döndürün
• API dokümantasyonunu güncel tutun (OpenAPI/Swagger)

Middleware (Ara Katman) Mimarisi

Sistemler arası trafiği düzenleyen köprü: middleware

Middleware, kaynak ve hedef sistemlerin arasına oturan; veri dönüşümü, yönlendirme ve orkestrasyon işlerini üstlenen yazılım katmanıdır. Peki neden bu kadar önemli?

Middleware Avantajları

• Gevşek bağlılık (Loose Coupling): Sistemlerin birbirini doğrudan tanıması gerekmez
• Veri dönüşümü: Farklı formatlar arası çeviri (JSON – XML – CSV)
• Protokol çevirisi: HTTP – SFTP – AS2 – MQ arası geçiş
• Kuyruk yönetimi: Asenkron işlem ve yük dengeleme
• Hata yönetimi: Retry, dead letter queue, circuit breaker
• İzleme ve loglama: Merkezi gözlem noktası

Middleware Türleri

1. Message Broker

Mesaj kuyruğunu yönetir. Sistemler mesaj üretir (producer) ve tüketir (consumer). Apache Kafka, RabbitMQ ve Azure Service Bus bu gruba girer.

2. Enterprise Service Bus (ESB)

Mesaj yönlendirme, dönüşüm, orkestrasyon ve protokol çevirisini bir arada sunar. MuleSoft, IBM Integration Bus ve WSO2 örnek verilebilir.

3. iPaaS (Integration Platform as a Service)

Bulut tabanlı entegrasyon platformu. Hazır konektör, görsel tasarımcı ve yönetilen altyapı paketle birlikte gelir. Zapier, Make (Integromat), Boomi ve Workato bu türdendir.

Middleware Seçim Kriterleri

• Sistemlerinizin ölçeği ve karmaşıklığı
• Teknik ekip yetkinliği
• On-premise mi bulut mu tercih ettiğiniz
• Bütçe ve lisans modeli
• Hazır konektör sayısı ve kalitesi
• İzleme ve debug yetenekleri

Real-time vs Batch Entegrasyon

Zamanlamayı doğru kurmak, entegrasyonun kaderini belirler

Entegrasyon mimarisinde en kritik kararlardan biri, verinin ne zaman aktarılacağıdır. Karşınızda iki temel yaklaşım var:

Real-time (Gerçek Zamanlı) Entegrasyon

Veri, olay gerçekleştiği anda aktarılır.

Avantajları:

• Anlık veri tutarlılığı
• Hızlı iş süreçleri
• Kullanıcı deneyiminde iyileşme

Dezavantajları:

• Sistem yükü artar
• Hedef sistem kesintilerinde veri kaybı riski
• Daha karmaşık hata yönetimi

Kullanım Alanları:

• POS satışlarının ERP’ye anında yansıması
• E-ticaret sipariş bildirimleri
• Stok seviyesi alarmları
• Ödeme işlemleri

Batch (Toplu) Entegrasyon

Veri, belirli aralıklarla (saatlik, günlük) topluca aktarılır.

Avantajları:

• Sistem yükünü azaltır
• Hata toleransı (retry imkanı)
• Büyük veri hacimleri için verimli
• Daha basit hata yönetimi

Dezavantajları:

• Veri gecikmesi (latency)
• Geçici tutarsızlık

Kullanım Alanları:

• Günlük stok senkronizasyonu
• Muhasebe kapanış işlemleri
• Raporlama veri güncelleme
• Ana veri (master data) aktarımı

Hibrit Yaklaşım

Kurumsal sistemlerin çoğunda ikisi bir arada kullanılır:

• Kritik işlemler (sipariş, ödeme) real-time
• Yoğun veri hacimleri (raporlama, arşiv) batch
• Near real-time (yakın gerçek zaman) ara çözüm (temsili: 5-15 dakika aralık)

Webhook ve Event-Driven Patterns

Olay tabanlı entegrasyonun bel kemiği webhook’lardır

Webhook, bir sistemde olay gerçekleştiğinde başka bir sisteme otomatik olarak HTTP POST isteği fırlatan mekanizmadır. Durmadan sorgulamak (polling) yerine, veriyi karşıya itme (push) mantığıyla çalışır.

Webhook Nasıl Çalışır?

1. Hedef sistem bir URL (endpoint) oluşturur ve kaynak sisteme kaydeder
2. Kaynak sistemde tanımlı olay gerçekleşir (örneğin yeni sipariş)
3. Kaynak sistem, hedef URL’ye HTTP POST isteği gönderir
4. Hedef sistem isteği alır, işler ve onay (200 OK) döndürür

Webhook Avantajları

• Kaynak verimliliği: Sürekli sorgulama yerine yalnızca olay olduğunda iletişim
• Anında bildirim: Gerçek zamanlı entegrasyon
• Basitlik: Standart HTTP protokolü

Webhook Zorluklar

• Teslimat garantisi: Hedef sistem cevap vermezse ne olur?
• Sıralama: Mesajlar sırasıyla mı ulaşıyor?
• Idempotency: Aynı mesaj birden fazla gelirse?
• Güvenlik: Webhook istekleri doğrulanmalı

Webhook En İyi Pratikleri

• Her webhook isteği için benzersiz ID kullanın (idempotency key)
• HMAC imzası ile webhook doğrulama yapın
• Başarısız teslimatlar için retry mekanizması kurun (exponential backoff)
• Webhook loglarını saklayın ve izleyin
• Timeout süreleri belirleyin (temsili: 30 saniye)

Event-Driven Architecture Patterns

Event Sourcing

Durum değişiklikleri birer olay olarak kaydedilir; mevcut durum bu olayların tekrar oynatılmasıyla türetilir. Audit trail ve zamansal sorgular için biçilmiş kaftandır.

CQRS (Command Query Responsibility Segregation)

Okuma ve yazma işlemleri ayrı modeller kullanır. Performansı iyileştirir, ölçeklenmeyi kolaylaştırır.

Saga Pattern

Dağıtık transaction yönetimi. Mikroservis mimarisinde tutarlılığı korumak için kullanılır.

EDI Standartları ve Kullanım Alanları

B2B entegrasyonların köklü ayaklarından biri: EDI

EDI (Electronic Data Interchange), iş ortakları arasında standart formatta elektronik belge alışverişini sağlayan sistemdir. Modern API’lerden çok önce vardı; ama bugün de kritik olmayı sürdürüyor.

EDI Standartları

EDIFACT (UN/EDIFACT)

Birleşmiş Milletler eliyle geliştirilen uluslararası standart. Avrupa’da ve uluslararası ticarette yaygın.

X12 (ANSI ASC X12)

Kuzey Amerika’da yaygın standart. ABD perakende ve sağlık sektöründe baskın.

TRADACOMS

İngiltere perakende sektöründe kullanılan eski bir standart.

Yaygın EDI Belge Türleri

• Sipariş (ORDERS / 850): Satın alma siparişi
• Sipariş Onay (ORDRSP / 855): Sipariş teyidi
• Sevkiyat Bildirimi (DESADV / 856): ASN (Advanced Shipping Notice)
• Fatura (INVOIC / 810): Ticari fatura
• Stok Raporu (INVRPT / 846): Envanter durumu

EDI İletişim Protokolleri

• AS2 (Applicability Statement 2): HTTP üzerinden güvenli EDI transferi
• SFTP: Güvenli dosya transferi
• VAN (Value Added Network): Üçüncü taraf EDI ağları
• AS4: Web servisleri tabanlı modern alternatif

EDI vs API: Hangisi Ne Zaman?

• EDI tercih edin: Büyük perakende zincirleri, lojistik firmaları ve zorunlu standart dayatan B2B partnerler
• API tercih edin: Modern SaaS entegrasyonları, esnek veri ihtiyacı, hızlı geliştirme
• Hibrit yaklaşım: EDI partnerler için EDI, modern sistemler için API

Sahadan Örnek: Çok Kanallı Perakende Entegrasyonu

Entegrasyon Mimarisinde En Sık Yapılan 7 Hata

1. Hata Senaryolarını Planlamamak

“Sistem nasılsa hep çalışır” varsayımı. Hedef sistem kesintisi, ağ hatası ya da timeout durumunda ne olacağı hiç düşünülmemiştir. Sonuçta veri ya kaybolur ya da tutarsız kalır.

2. Idempotency Sağlanmaması

Aynı mesaj birden fazla işlendiğinde tekrarlı kayıt oluşur; örneğin aynı sipariş ERP’ye iki kez yazılır. Her mesaja benzersiz bir ID atanmalı ve tekrar mutlaka kontrol edilmeli.

3. Yetersiz Loglama ve İzleme

Entegrasyon hataları ancak kullanıcı şikayet edince fark ediliyor. Proaktif izleme, alarm ve dashboard yok. Sorunu tespit etmek saatler alıyor.

4. Sıkılaştırılmış (Tight) Bağımlılık

Sistemler birbirine doğrudan bağımlı. Bir sistemdeki tek bir değişiklik tüm entegrasyonları etkiliyor. Araya middleware ya da bir soyutlama katmanı konmadan bağlantı kuruluyor.

5. Güvenliğin İhmal Edilmesi

API anahtarları kodun içinde saklı, HTTPS yerine HTTP kullanılıyor, kimlik doğrulama zayıf. Veri sızıntısı ve yetkisiz erişim riski gözden kaçırılıyor.

6. Dokümantasyon Eksikliği

Entegrasyon akışları, veri eşleme kuralları ve hata kodları hiç yazıya dökülmemiş. Geliştirici değişince bilgi buharlaşıyor, bakım kabusa dönüyor.

7. Test Ortamı Olmadan Canlı Geçiş

Entegrasyonlar doğrudan canlı (production) ortamda test ediliyor. Hatalar gerçek veriyi vuruyor; geri almak hem zor hem pahalı.

Hataların çoğu, dikkatli bir planlamayla en baştan önlenebilir

Hata Yönetimi ve Retry Stratejileri

Entegrasyon sistemlerinde hata kaçınılmazdır; hiç hata çıkmayacağını ummak yerine, çıktığında zararsız kalmasını sağlayan mekanizmaları kurmak gerekir.

Retry (Yeniden Deneme) Stratejileri

1. Sabit Aralık (Fixed Interval)

Her başarısız denemeden sonra aynı süre beklenir (temsili: 30 saniye). Basittir ama zaten zorlanan hedef sistemi daha da yorabilir.

2. Exponential Backoff

Bekleme süresi her denemede katlanarak artar (1s, 2s, 4s, 8s…). Hedef sisteme nefes alacak boşluk bırakır.

3. Exponential Backoff + Jitter

Bekleme süresine biraz rastgelelik eklenir. Böylece onlarca istemcinin aynı anda yeniden denemeye kalkışması engellenir.

Circuit Breaker Pattern

Hedef sistem üst üste hata döndürüyorsa, istekleri geçici olarak keser:

• Closed (Kapalı): Normal çalışma, istekler geçiriliyor
• Open (Açık): Hata eşiği aşıldı, istekler engelleniyor
• Half-Open (Yarı Açık): Test istekleri gönderiliyor, iyileşme kontrol ediliyor

Dead Letter Queue (DLQ)

Bütün retry denemeleri tükenmiş mesajlar ayrı bir kuyruğa (DLQ) alınır. Bu mesajlar:

• Manüel inceleme için bekletilir
• Kurtarma (recovery) işlemine tabi tutulur
• Analiz için saklanır

Idempotency (Tekrar Edilebilirlik)

Aynı işlem birden fazla kez çalışsa bile sonuç değişmemeli. Peki nasıl?

• Her mesaja benzersiz bir ID (UUID) atanır
• İşlem öncesinde bu ID kontrol edilir
• Daha önce işlenmişse, sonuç doğrudan geri döndürülür

İzleme (Monitoring) ve Alarm Sistemleri

Entegrasyon sistemleri 7/24 izlenmeli. Sorunu kullanıcıdan önce siz görmelisiniz.

İzlenmesi Gereken Metrikler

İşlem Metrikleri

• Toplam işlem sayısı (dakika/saat/gün bazında)
• Başarılı/başarısız işlem oranı
• Ortalama işlem süresi (latency)
• Kuyruk derinliği (queue depth)

Sistem Metrikleri

• CPU, bellek, disk kullanımı
• Network I/O
• Bağlantı havuzu (connection pool) durumu

İş Metrikleri

• İşlenen sipariş/fatura sayısı
• Veri tutarlılığı oranları
• SLA uyum oranları

Alarm Stratejisi

• Kritik (P1): İşlem başarı oranı %95 altına düştü – anında bildirim
• Yüksek (P2): Latency normalin 2 katı – 15 dakika içinde bildirim
• Orta (P3): DLQ’da birikmiş mesaj – saatlik özet
• Düşük (P4): Kapasite uyarıları – günlük rapor

Dashboard ve Görselleştirme

Entegrasyonun sağlığını tek bakışta gösteren dashboard’lar kurun:

• Trafik haritası (hangi sistemler konuşuyor)
• Hata dağılımı (sistem, tür, zaman bazında)
• Trend grafikleri (işlem hacmi, hata oranı)
• SLA takip tablosu

Entegrasyon Başarı Metrikleri

Aşağıdaki metrikler, entegrasyon mimarinizin sağlığını ölçmek için elinizin altında olsun (temsili değerler):

Entegrasyon Mimarisi Kontrol Listesi

Projenize özel entegrasyon mimarisi tasarımı için iletişim sayfasından ulaşabilirsiniz.

Sıkça Sorulan Sorular (SSS)