Kurumsal ERP projelerinde en sık görülen problem, çekirdek sistemin etrafına yıllar içinde doğrudan bağlantılar örülmesidir. Muhasebe, e-ticaret, depo, CRM, raporlama ve insan kaynakları aynı veri alanına farklı yöntemlerle dokunur. Sistem çalışıyor gibi görünür; fakat her yeni entegrasyon, karmaşıklığı görünmez biçimde büyütür.
Neden doğrudan entegrasyon modeli kırılgan?
Nokta-nokta entegrasyon modeli kısa vadede hızlıdır; uzun vadede ise pahalıdır. Çünkü:
- Hata yayılımı kontrolsüz olur.
- Kaynak sistem üzerinde gereksiz yük oluşur.
- Sıra, tekrar deneme ve idempotency mantığı her uygulamada yeniden yazılır.
- Gözlemlenebilirlik parçalanır.
Özellikle ERP sistemleri yüksek iş kritikliği taşıdığı için, entegrasyon mimarisi performanstan çok dayanıklılık perspektifiyle ele alınmalıdır.
Olay tabanlı mimari ne kazandırır?
Olay tabanlı modelde ERP çekirdeği, “bir şey oldu” bilgisini güvenilir biçimde dışarı aktarır. Tüketici sistemler bu olayı bağımsız şekilde işler. Böylece:
- Üretici ile tüketici zaman açısından gevşek bağlanır.
- Geçici hatalarda mesaj tekrar işlenebilir.
- Her entegrasyon için ayrı ölçekleme yapılabilir.
- İş akışları izlenebilir ve yeniden oynatılabilir.
Sağlam bir desen: Outbox + Message Broker
Kurumsal sistemlerde en güvenli başlangıç deseni çoğu zaman transactional outbox yaklaşımıdır. Bunun mantığı basittir:
- ERP işlemi kendi veritabanısında tamamlanır.
- Aynı işlem içinde bir outbox kaydı oluşturulur.
- Ayrı bir yayınlayıcı süreç bu kayıtları mesaj broker’a taşır.
- Tüketiciler olayları bağımsız şekilde işler.
Bu desen, “veri yazıldı ama olay yayınlanamadı” ya da tersi gibi tutarsızlık risklerini azaltır.
Hangi olaylar yayınlanmalı?
Her alan değişikliği bir olay olmak zorunda değildir. Kurumsal teknoloji mimarisinde iyi olay tasarımı şu nitelikleri taşır:
- İş anlamı vardır.
- Tüketiciler için yeniden kullanılabilir.
- Versiyonlanabilir.
- Kişisel veya hassas veri minimum tutulur.
Örnekler:
SiparisOnaylandiFaturaKesildiStokRezervasyonuTamamlandiCariHesapLimitiGuncellendi
İzlenebilirlik ve hata yönetimi
Olay tabanlı sistemlerde başarı yalnızca mesajın yayınlanması değildir. Her adım izlenmelidir:
- Olay üretildi mi?
- Broker’a başarıyla yazıldı mı?
- Tüketici kaç kez denedi?
- Dead-letter kuyruğuna düştü mü?
- İş etkisi hangi kayıtları etkiledi?
Bu nedenle correlation ID, olay kimliği ve iş emri numarası gibi alanlar standardize edilmelidir.
ERP dünyasında dikkat edilmesi gereken sınırlar
Gerçek hayatta bazı ERP sistemleri eski sürücüler, dosya tabanlı aktarım mekanizmaları veya kısıtlı API yetenekleri taşır. Böyle durumlarda olay tabanlı mimariyi idealleştirmek yerine pragmatik bir ara katman kurmak daha doğrudur:
- Kaynak sistemden değişiklikleri toplayan entegrasyon servisi
- Normalizasyon ve zenginleştirme katmanı
- Mesaj broker
- Tüketici servisler
Bu yaklaşım, çekirdek ERP’ye minimum müdahale ile modern entegrasyon davranışı kazandırır.
Sonuç
ERP entegrasyonlarında ölçek sorunu çoğu zaman işlem hacminden değil, bağımlılık biçiminden kaynaklanır. Olay tabanlı mimari; doğru olay modeli, outbox deseni ve güçlü gözlemlenebilirlik ile birlikte uygulandığında çekirdek sistem üzerindeki baskıyı azaltır ve kurumsal mimariyi daha dayanıklı hâle getirir. En iyi sonuç, teknoloji modasına değil iş akışlarının kırılgan noktalarına odaklanıldığında elde edilir.