Birkaç ayda bir, bir sigorta şirketinin ya da bankanın poliçe verilerinin, hasar beslemesinin veya komisyon hesaplamasının neden yanlış olduğunu çözmeye çalıştığı bir kriz odasına çağrılıyorum. Entegrasyon platformu her zaman pırıl pırıl — Logic Apps, MuleSoft, Boomi ya da Python yapıştırıcısıyla evde yapılmış bir Kafka hattının bir kombinasyonu. Ve kök neden neredeyse her zaman aynı: kimse sınırda bir sözleşme dayatmamış, kimse teslimatı garanti etmemiş ve kimse hangi mesajın hangi alt sistem kaydını ürettiğini kesin olarak söyleyemiyor.
Kariyerimin anlamlı bir bölümünü Türk bankaları ve sigortacıları için BizTalk çözümleri inşa ederek geçirdim. Bu konuda nostaljik değilim. Araçlar acı vericiydi, öğrenme eğrisi acımasızdı ve sabah 2'de DTA sorgularıyla bir orchestration'ı debug etmek özel bir çile türüydü. Ama BizTalk, modern iPaaS platformlarının isteğe bağlı hale getirdiği şeyleri size doğru şekilde yapmaya zorluyordu — ve kurumsal entegrasyonda isteğe bağlı, atlandı demektir.
BizTalk'ın Dayattığı Üç Disiplin
BizTalk, can sıkıcı olacak kadar fikir sahibiydi. Platform sizinle savaşmadan yarım yamalak bir entegrasyon kuramazdınız. Özellikle üç disiplin:
- Sınırda şema doğrulama. MessageBox'a giren her mesaj, yayımlanmış bir XSD'ye uymak zorundaydı. Bir partner size bozuk bir EDI 837 ya da kırık bir poliçe XML'i gönderdiyse, alt akıştaki bir stored procedure'da üç sıçrama sonra değil, receive port'ta başarısız olurdu.
- Garantili, dayanıklı mesaj teslimi. MessageBox transactional bir depoydu. Bir mesaj kalıcılaştırıldığında, retry, askıya alma ve devam ettirme yetenekleriyle birlikte tam olarak bir kez teslim edilirdi. Bu mantığı siz yazmıyordunuz. Miras alıyordunuz.
- Açık orchestration sözleşmeleri. Bir orchestration'ın tipli girdileri, tipli çıktıları ve görünür bir akışı vardı. Correlation set'ler beyan edilirdi. Compensation mantığı açıktı. Bir orchestration'ı okuyup ne yaptığını anlayabilirdiniz.
Bunların hiçbiri gösterişli değildi. Hepsi yük taşıyordu.
Modern iPaaS'in İsteğe Bağlı Hale Getirdikleri
Orta ölçekli bir sigortacıdaki tipik bir Logic Apps veya Boomi uygulamasına bakın. Bir REST endpoint'i JSON alıyor. JSON bir dizi dönüşüm adımından geçiriliyor. Belki bir JSON şema kontrolü vardır, belki yoktur. Genellikle yoktur, çünkü şema 2022'den beri güncellenmemiş bir Confluence sayfasında yaşamaktadır.
Üst sistem yeni bir alan eklediğinde veya policyHolderId'yi int'ten string'e çevirdiğinde, entegrasyon çalışmaya devam eder. Dönüşüm alanı sessizce zorlar ya da düşürür. Alt akışta, veri ambarı bir tanımlayıcı beklediği yerde NULL alır. Üç hafta sonra, bir reasürans raporu yanlış çıkar ve birisi beni arar.
Desen tekrarlanıyor:
- Şema dayatması yok. JSON bağışlayıcı olarak ele alınır, bu da hataların önlenmediği, ertelendiği anlamına gelir. Bozuk bir hasar payload'ı bozuk bir hasar kaydına dönüşür.
- Exactly-once kılığına sokulmuş at-least-once teslimat. Çoğu iPaaS connector'ı başarısızlıkta yeniden dener ancak idempotency sözleşmesi yoktur. Aynı prim ödemesinin acknowledgment timeout olduğu için üç kez kaydedildiğini gördüm.
- Örtük orchestration. 40 adımlı, dinamik içerik referansları ve inline ifadeler içeren bir akış orchestration değildir. Bir script'tir. Kimse review edemez, kimse hata modları üzerine akıl yürütemez ve orijinal geliştirici ayrıldığı an arkeolojiye dönüşür.
Somut Bir Örnek: Poliçe İhracı
Birlikte çalıştığım Türk bir hayat sigortacısı, BizTalk poliçe ihraç hattını modern bir olay tabanlı mimariyle değiştirdi. Kafka, mikroservisler, tam yığın. Altı ay sonra finans, ihraç edilen poliçelerin yaklaşık %0,4'ünün underwriting kararıyla uyuşmayan prim tutarlarına sahip olduğunu işaretledi.
Eski BizTalk akışı, grossPremium, netPremium ve commissionAmount alanlarını açık hassasiyetle decimal olarak gerektiren bir şemaya karşı underwriting mesajını doğruluyordu. Orchestration'da quoteId üzerinde bir correlation set vardı ve her durum geçişi kalıcılaştırılıyordu.
Yeni akış JSON olayları kabul ediyordu. Yukarıda bir yerde, bir servis belirli bir ürün teklif edildiğinde grossPremium'u locale-formatlı bir string olarak — "1.234,56" — yaymaya başladı. Tüketici bunu parseFloat ile parse etti, 1.234 aldı ve bunu poliçe kaydına yazdı. Hata yok, uyarı yok, şema reddi yok. Sadece bir ürün hattı için altı ay boyunca sessizce yanlış primler.
BizTalk'ta bu, ilk gerçekleştiğinde receive port'ta başarısız olurdu. Yeni sistemde, denetim komitesinde başarısız oldu.
BizTalk'tan Ne Çalmalı, BizTalk'ı Geri Getirmeden
Bir BizTalk yeniden doğuşu savunmuyorum. Platform emekliliğini hak etmişti. Ama dayattığı disiplin onunla birlikte emekli olmamalıydı. Modern iPaaS üzerinde entegrasyonlar inşa ediyorsanız, şu alışkanlıkları çalın:
- Her gelen payload'ı versiyonlu bir şemaya karşı doğrulayın. JSON Schema, Avro, Protobuf — birini seçin, bir registry'de saklayın, uymayan mesajları kenarda reddedin. Dönüşüm adımında değil. Kenarda.
- Idempotency'yi bir umut değil, bir sözleşme yapın. Her mesajın stabil bir tanımlayıcısı olmalı. Her tüketici replay'leri ele almalı. Bunu yazıya dökün. Test edin.
- İşlemeden önce kalıcılaştırın. Son 30 günde platformunuza giren her mesajı replay edemiyorsanız, garantili teslimatınız yok. Ekstra adımlarla optimistik teslimatınız var.
- Orchestration'ı açık ve incelenebilir yapın. Entegrasyon mantığınız visual designer ifadeleri, inline script'ler ve connector konfigürasyonları arasında dağılmışsa, kimse onu review etmiyor demektir. Karmaşık akışları pull request'lerden geçen koda taşıyın.
- Şema değişikliklerini varsayılan olarak breaking change kabul edin. Geriye dönük uyumluluk varsayılan değil, kanıtlanan bir özelliktir.
Gerçek Ders
iPaaS satıcıları, entegrasyonun sürükle-bırak, low-code ve citizen developer'lar için erişilebilir olabileceği bir hikaye sattı. Basit akışlar için tamam. Ama para, poliçeler veya regülatif veri işin içine girdiği an, dayatılan sözleşmelerin yokluğu, bir denetçi ya da müşteri bulana kadar sessizce büyüyen bir borç haline gelir.
BizTalk, yanlış şeylerin çok kolay olduğunu bildiği için doğru şeyleri zorunlu kıldı. Modern platformlar doğru şeyleri isteğe bağlı yapıp buna esneklik dedi. Düzeltmek için para aldığım veri kalitesi sorunları, o esnekliğin faturasıdır — faiziyle birlikte gelir.