Problemler
Bu sorunların kökünde hep aynı şey yatıyor. Batch entegrasyonu veriyi zamanında değil, toplu olarak taşır. Bu durum sahada üç somut probleme dönüşür:
| Sorun | Sahada ne anlama gelir |
|---|---|
| Veri Senkronizasyon Gecikmesi | Müşteri kaydı CRM'de güncellendi, ERP bir sonraki batch'e kadar bunu bilmiyor. O pencerede satış temsilcisi eski segmentle teklif hazırladı. Kampanya yanlış kitleye gitti. Sonuç: kaybedilen teklif, geriye dönük düzeltme maliyeti. |
| Gereksiz API Yükü | Her seferinde yüz binlerce kayıt taşınıyor. Gerçekte sadece birkaç satır değişmiştir. Sistem yükü ve maliyet orantısız şekilde artar. Sonuç: gereksiz API limit tüketimi, ölçeklendikçe artan altyapı faturası. |
| Entegrasyon İzlenebilirlik Sorunu | Hangi kayıt ne zaman değişti, hangi job taşıdı, nerede takıldı? Batch logları bunu yanıtlamıyor. Denetimde ya tahmin yürütülüyor ya da elle araştırılıyor. Sonuç: denetim riski, GDPR/KVKK uyumsuzluk tehlikesi. |
Veri doğru yerde, ama doğru zamanda değil. Bu fark yeterince pahalı.
Mimari
MuleSoft CDC entegrasyonunda tek flow yaklaşımı kısa vadede hızlı görünür. Ancak uzun vadede her değişiklik riski beraberinde getirir. Retry stratejisi, idempotency kontrolü ve fan-out yönlendirmesi aynı akışa sıkıştırıldığında bakım maliyeti katlanarak artar. Aşağıdaki katmanlı model bu sorumlulukları ayırır. Gerçek projelerde kararlı kalmayı bu ayrım sağlar.
① Event Kaynağı
MuleSoft'un Salesforce'u gerçek zamanlı dinlemesi Anypoint Studio'daki Salesforce Connector'ın Replay Channel Listener bileşeniyle başlar. Önce Salesforce tarafında bir Connected App tanımlanır. OAuth 2.0 client credentials akışıyla MuleSoft bu uygulamaya bağlanır.
Bağlantı kurulduktan sonra Replay Channel Listener iki farklı kanalı dinleyebilir: Platform Events — geliştiricinin tanımladığı özel iş olayları; ya da Change Data Capture — Salesforce Setup'tan nesne bazında etkinleştirilen, Account veya Contact gibi nesnelerdeki her CREATE / UPDATE / DELETE / UNDELETE değişikliğini otomatik event'e dönüştüren mekanizma. Anypoint Studio'da bu ikinci seçenek için listener /data/AccountChangeEvent gibi nesneye özel bir CDC kanalını dinler. Ekstra Salesforce geliştirmesi gerekmez.
Dayanıklılık açısından kritik bir detay: Salesforce her event'e bir replayId atar ve 24 saat saklar. MuleSoft bağlantısı koparsa Replay Channel Listener son başarılı replayId'den devam eder. Bu sayede event kaybı olmaz.
② Kuyruk Katmanı — Anypoint MQ
Event doğrudan işlenmez. Önce Anypoint MQ kuyruğuna alınır. Hedef sistem meşgulse, ağ koparsa veya bir şeyler ters giderse kayıp olmaz. Üç mekanizma birlikte çalışır:
- ✓main-event-queue sıralı işlemeyi ve at-least-once delivery'yi garantiler.
- ✓retry-queue başarısız event'leri exponential backoff ile yeniden dener. Maksimum 5 deneme yapılır.
- ✓dead-letter-queue tekrar eden hataları izole eder. Watermark/offset ile işlenen son pozisyon takip edilir. Sistem yeniden başlasa bile kaldığı yerden devam eder.
③ Process API — Veri Dönüşümü ve Yönlendirme
Bu katman olmasa entegrasyon sadece veri taşır. Process API onu anlam taşıyan bir akışa dönüştürür.
İlk adım idempotency kontrolüdür: aynı correlationId daha önce işlendi mi? ObjectStore veya Redis üzerinden kontrol edilir (ttl: 24h). Duplicate işlem engellenir. Ardından DataWeave 2.0 ile format dönüşümü yapılır. Gerekirse harici servislerden veri zenginleştirme eklenir ve iş kuralları uygulanır. Content Router fan-out sağlar. Tek bir müşteri güncellemesi Scatter-Gather pattern'i ile hem ERP'ye hem CRM'e hem veri ambarına paralel gönderilebilir.
Hata yönetimi de bu katmanda tanımlanır. Audit logger her event için değişiklik öncesi ve sonrası durumu kaydeder. Bu kayıt GDPR/KVKK denetim süreçleri için kritik öneme sahiptir.
④ Hedef Sistemler
ERP/SAP (SOAP/RFC), CRM (REST/JSON), Data Warehouse (JDBC/bulk insert), bildirim sistemleri (HTTP/webhook) veya downstream bir Mule flow (VM/JMS). Yeni bir hedef eklemek mevcut akışı değiştirmez. Content Router'a yeni bir route tanımlamak yeterlidir.
Observability — Yatay Katman
Tüm katmanları kesen tek sorumluluk: her şeyin görünür olması. CorrelationId, event tipi, hedef sistem sonucu, retry sayısı ve gecikme süresi her adımda yapılandırılmış şekilde loglanır. Bir şey ters gittiğinde "nerede, ne zaman, neden" sorusunun cevabı zaten kayıt altındadır. Anypoint Monitoring ile SLA eşikleri aşılınca otomatik alarm üretilir.
Sektörler
Salesforce CDC entegrasyonunun iş değeri en net biçimde operasyonel senaryolarda ortaya çıkar:
| Sektör | Problem | CDC ile kazanım |
|---|---|---|
| Perakende | Salesforce CPQ'da fiyat güncellendi. Batch 15 dakika sonra çalıştı. Bu sürede e-ticaret sitesi eski fiyatı gösterdi. 3 sipariş eski fiyatla kapandı. | Fiyat değişikliği anında ERP ve e-ticaret platformuna yansır. Tutarsız satış olmaz. Manuel düzeltme maliyeti sıfırlanır. |
| Finans | Salesforce'ta müşterinin kredi limiti değiştirildi. CRM entegrasyonu 10 dakikalık batch aralığında çalışıyor. Temsilci bu pencerede eski limite göre teklif hazırladı. | Limit değişikliği downstream sistemlere saniyeler içinde düşer. Temsilci her zaman güncel veriyle çalışır. |
| Üretim | Salesforce'taki sipariş miktarı revize edildi. ERP bir sonraki senkronizasyonda bunu aldı. Araya giren 8 dakikada planlama eski miktara göre malzeme rezerve etti. | Revizyon üretim ve depo sistemlerine anında iletilir. Gereksiz malzeme rezervasyonu ortadan kalkar. |
| Lojistik | Salesforce'ta teslimat adresi güncellendi. Kargo sistemi 5 dakikada bir senkronize oluyor. Bu pencerede kargo etiketi eski adresle basıldı. | Adres değişikliği kargo API'sine işlem tamamlanmadan ulaşır. Yanlış teslimat ve iade maliyeti sıfırlanır. |
| Sağlık | Salesforce Health Cloud'da hasta ilaç alerjisi eklendi. Eczane modülü periyodik batch ile çalışıyor. Reçete bu pencerede yazıldı. | Klinik güncelleme tüm modüllerde anlık tutarlı kalır. Audit trail otomatik oluşur. KVKK uyumu güvence altına alınır. |
MuleSoft CDC Entegrasyonunda Karşılaşılan Gerçek Sorunlar
CDC teoride temiz görünür. Çoğu sorun mimari kararlardan değil, önceden düşünülmeyen operasyonel varsayımlardan gelir.
| Ders | Neden önemli |
|---|---|
| Event yakalamak yeterli değildir | Asıl zorluk event'i yakaladıktan sonra başlar. Zenginleştirme, iş kuralları, hata yönetimi ve tekrar işleme gibi unsurlar önemlidir. Salesforce CDC akışı uçtan uca tasarlanmalıdır. |
| Kaynaktaki veri eksik olabilir | Bazı Salesforce CDC event'leri sadece "bir şey değişti" sinyali taşır. Yeni değeri içermez. Bu durumda ilgili kaydın güncel hali Process API katmanında Salesforce API'den yeniden okunmalıdır. |
| Idempotency şarttır | Ağ hatası, retry veya Anypoint MQ replay sırasında aynı event birden fazla kez işlenebilir. CorrelationId ile duplicate kontrolü yapılmazsa veri bozulması kaçınılmazdır. |
| Retry baştan planlanmalıdır | Canlıya çıktıktan sonra retry stratejisi eklemek mevcut akışı değiştirmeyi gerektirir. Dead letter queue, exponential backoff ve manuel replay mekanizmaları başından itibaren parçası olmalıdır. |
| Log çokluğu ≠ izlenebilirlik | CorrelationId, entity adı, event tipi, hedef sistem sonucu ve retry sayısı gibi bağlamsal alanlar yapılandırılmış şekilde loglanmalıdır. Anypoint Monitoring bu yapı olmadan değer üretemez. |
| Ne zaman CDC, ne zaman batch? | Düşük hacimli, anlık olma ihtiyacı olmayan durumlarda batch hâlâ doğru seçimdir. CDC her problemi çözmez. Ancak "verinin doğru anda doğru yerde olması" kritikse, geçiş kaçınılmazdır. |
Sonuç
MuleSoft CDC entegrasyonu bir araç kararı değil, operasyonel bir karardır. Salesforce'taki her değişikliğin downstream sistemlere güvenilir, sıralı ve kayıpsız ulaşması — idempotency, retry stratejisi ve structured logging olmadan mümkün değildir.
Anypoint MQ ile kayıpsız buffer, DataWeave ile esnek dönüşüm, Content Router ile fan-out — bunların hepsi doğru yapılandırıldığında gerçek zamanlı Salesforce CDC entegrasyonunun altyapısını oluşturur. Ancak başarı araçlardan önce kararlara bağlıdır. Hangi event'ler kritik, retry politikası ne olacak, hata durumunda sistem nasıl davranacak? Bu soruların cevabı mimari çizilmeden önce verilmelidir.
CDC'ye geçiş yalnızca teknik bir karar değil, takımın operasyonel olgunluğa ulaşması demektir. Batch mantığıyla büyümüş ekipler için bu aynı zamanda bir kültür değişimidir. Reaktif izleme yerine proaktif observability, toplu senkronizasyon yerine anlık güvenilirlik.
Bu mimariyi kendi projenize uyarlamak istiyorsanız başlangıç noktası olarak şunu öneririz: önce kuyruk yapısını tasarlayın, idempotency stratejisini belirleyin, sonra fan-out hedeflerini ekleyin. Sırayı atlarsanız canlıda bedelini ödersiniz.
"Doğru tasarlanmış bir MuleSoft CDC mimarisi kurumlara yalnızca teknik verimlilik değil; daha güvenilir ve daha çevik bir operasyon modeli sunar."
