Sistemler Birbiriyle Nasıl Konuşur: Kurumsal Entegrasyonun Anatomisi

İki sistemi konuşturmak, teknik olarak veri alışverişidir; pratikte ise iki farklı dünya görüşünü uzlaştırmaktır. Bir tarafta müşteri kaydı beş alandan oluşur, diğer tarafta yirmi beş; birinde tarih saat dilimiyle gelir, diğerinde çıplak; birinde iptal edilen kayıt silinir, diğerinde durumu değişir. Entegrasyonun asıl işi veri taşımak değil, bu farkları çeviren kuralları yazmaktır.

İkinci zorluk sahiplik meselesidir: hangi sistem hangi verinin sahibi? İki taraf da aynı müşteri kaydını güncelleyebiliyorsa, er ya da geç iki farklı doğru oluşur ve hangisinin kazanacağına karar veren bir kural yoksa veri sessizce bozulur. Entegrasyon tasarımının ilk adımı kod yazmak değil, her veri parçası için tek bir sahip belirlemektir.

Üçüncüsü, karşı tarafın sizin kontrolünüzde olmamasıdır. Dış sistem bakıma girer, sürüm değiştirir, alan ekler, yanıt biçimini değiştirir ya da sadece yavaşlar. Kendi kodunuzda test edip geçtiğiniz bir akış, karşı taraf değiştiği gün çalışmaz hâle gelir. Bu yüzden entegrasyon kodu, normal kodunuzdan daha savunmacı yazılmalıdır.

Entegrasyonun mimari cevabı adaptördür: dış sistemle konuşan her şey, uygulamanın çekirdeğinden ayrı bir modülde yaşar. Çekirdek yalnız kendi diliyle konuşur; adaptör çeviriyi yapar. Bu ayrım olmadığında dış sistemin alan adları, hata kodları ve tuhaflıkları uygulamanın her yerine sızar ve o sistemden vazgeçmek imkânsız hâle gelir.

Bizim kural olarak yazdığımız hâli şu: yeni bir dış sistem eklemek, yeni bir adaptör ve bir kayıt satırı demektir; çekirdeğe dokunulmaz. Bu disiplin iki şey sağlıyor. Birincisi, bir müşteri için yazılan entegrasyon diğer müşterilerin ürününü riske atmıyor. İkincisi, bir gün o sistemden vazgeçildiğinde silinecek yer belli — tek bir klasör.

Adaptörün içinde tutulması gereken üç şey var: alan eşlemesi, hata çevirisi ve kimlik bilgileri. Alan eşlemesi dışarının modelini içerinin modeline çevirir; hata çevirisi karşı tarafın hata kodlarını sizin anlayacağınız duruma dönüştürür; kimlik bilgileri ise ortam değişkeninde yaşar, kodda değil. Bu üçü dışarı taştığında adaptör olmanın anlamı kalmaz.

Birden fazla sistemi olan bir kurumda en görünür entegrasyon ihtiyacı kimliktir: aynı kişi her sistemde ayrı parolayla dolaşmak istemez. Merkezî bir kimlik servisi bu sorunu çözer — kullanıcı bir kez giriş yapar, diğer uygulamalar o girişi tanır. Bunun ikinci faydası daha önemlidir: birisi işten ayrıldığında erişimi tek yerden kesersiniz.

Kendi ürün ailemizde bu yaklaşımı uyguluyoruz: uygulamaların yerel girişi yok, kimlik merkezî servisten geliyor. Bunun bedeli, o servisin kritik hâle gelmesidir — çalışmadığında hiçbir uygulamaya girilemez. Bu yüzden kimlik servisinin ayakta kalması, tek tek uygulamalardan daha yüksek öncelikli bir işletim konusudur.

Kimlik entegrasyonunda en sık atlanan konu yetkidir. Kimlik 'bu kişi kim' sorusunu cevaplar; yetki 'bu kişi burada ne yapabilir' sorusunu. İkincisini merkeze taşımak her zaman doğru değildir — her uygulamanın kendi rol dünyası vardır. Pratik bir denge: kimlik merkezde, yetki uygulamada.

İki sistem arasında veri gönderirken en zor problem, kendi veritabanınıza yazma ile karşı tarafa gönderme işlemlerinin tek bir bütün olmamasıdır. Kaydı yazarsınız, göndermeye çalışırsınız, karşı taraf o an cevap vermez — kayıt sizde vardır, onlarda yoktur. Ya da tersi olur: gönderilir ama sizin kaydınız hata alır. İkisi de sessiz tutarsızlık üretir.

Bunun bilinen çözümü, gönderilecek mesajı da aynı işlemde kendi veritabanınıza yazmaktır: kayıt ve 'gönderilecek' notu birlikte oluşur, ayrı bir süreç o notu alıp karşı tarafa iletir ve başarılıysa işaretler. Böylece hiçbir mesaj kaybolmaz; en kötü ihtimalle gecikir. Biz para hareketlerinin olduğu ürünümüzde tam olarak bu deseni kullanıyoruz.

İkinci kural, tekrar gönderime dayanıklı olmaktır. Ağ hatası yüzünden aynı mesaj iki kez gidebilir; karşı taraf bunu iki ayrı işlem olarak görürse çift kayıt oluşur. Çözüm, her mesaja benzersiz bir kimlik koymak ve karşı tarafın aynı kimliği ikinci kez işlememesini sağlamaktır. Entegrasyonlarda 'en az bir kez' teslim normaldir; sizin işiniz onu 'etkisi bir kez'e çevirmektir.

Her entegrasyon canlı bağlantı olmak zorunda değildir. İki sistem arasında günde bir kez veri aktarmak yetiyorsa, standart bir dosya biçimiyle dışa aktarım ve içe aktarım en ucuz, en dayanıklı ve en anlaşılır çözümdür. Kurulumu saatler alır, bozulduğunda teşhisi kolaydır ve karşı tarafın altyapısına bağımlı değildir.

Bunu küçümsememek gerekiyor: canlı entegrasyon ihtiyacı çoğu zaman gerçek değil, varsayılan tercihtir. 'Anlık olsun' cümlesinin arkasında somut bir iş gereksinimi var mı diye sorulduğunda, cevabın 'aslında sabah görsek yeterli' olduğu çok olur. Böyle durumlarda basit çözümü seçmek, hem projeyi hızlandırır hem işletim yükünü azaltır.

Kendi ürünlerimizde de bu yüzden dışa/içe aktarımı temel bir yetenek olarak tutuyoruz. Hem veri sahipliği açısından önemli hem de çoğu entegrasyon ihtiyacını canlı bağlantı kurmadan karşılıyor. Karşı taraf modern bir arayüz sunmuyorsa — kurumsal dünyada sık karşılaşılan durum — zaten tek pratik yol budur.

Entegrasyon kodunun kalitesi, mutlu yolda değil hata anında belli olur. Karşı taraf yavaşladığında ne oluyor: istek sonsuza kadar bekliyor mu, yoksa makul bir sürede vazgeçip tekrar mı deniyor? Zaman aşımı koymayan bir entegrasyon, karşı taraf yavaşladığında kendi sisteminizi de kilitler — ve dışarıdan bakan 'bizim sistem çöktü' der.

İkinci mekanizma, tekrar denemenin sınırlı olmasıdır. Hata alan bir mesajı sonsuza kadar denemek, karşı taraf ayağa kalktığında binlerce birikmiş isteğin aynı anda gitmesi demektir. Artan aralıklarla deneme ve belirli sayıda başarısızlıktan sonra durup insana haber verme, hem karşı tarafı hem sizi korur.

Üçüncüsü görünürlüktür: başarısız mesajların bir yerde birikmesi ve o yerin izlenmesi. 'Gönderilemedi' durumundaki kayıtlar sessizce bir kolonda duruyorsa kimse bakmaz. Panelde görünen, sayısı artınca fark edilen bir kuyruk, entegrasyonun sağlığını gösteren en pratik göstergedir.

Entegrasyonların çoğu büyük mimari sorunlardan değil, küçük biçim farklarından bozulur. Tarih en klasik olanıdır: bir taraf saat dilimiyle gönderir, diğer taraf çıplak alır ve kayıtlar üç saat kayar. Kural basit: sistemler arasında tarih her zaman saat dilimi bilgisiyle taşınmalı ve depolama tek bir zaman diliminde yapılmalıdır. Görüntülemede yerelleştirmek ucuzdur; depolamada karışıklığı çözmek pahalıdır.

İkincisi sayı biçimidir. Ondalık ayırıcı, binlik ayırıcı ve yuvarlama kuralları iki sistemde farklı olabilir; para hesaplarında bu fark doğrudan tutarsızlığa dönüşür. Parasal değerleri ondalıklı kayan sayı yerine tam sayı kuruş olarak taşımak, bu sınıf hataların çoğunu baştan siler. Yuvarlamanın nerede yapılacağı da yazılı olmalı — iki sistem ayrı ayrı yuvarlarsa toplamlar tutmaz.

Üçüncüsü karakter kodlamasıdır ve Türkçe içerikte hemen görünür: 'ş', 'ğ', 'İ' harfleri bozuk geliyorsa sorun veride değil, aktarım biçiminin kodlamasındadır. Entegrasyon testine mutlaka Türkçe karakter içeren, uzun ve boşluklu bir örnek kayıt koyun; bu tek satır, üretimde çıkacak bir sürü şikâyeti önceden yakalar.

Entegrasyon geliştirmenin en sinir bozucu tarafı, karşı tarafın test ortamının çoğu zaman ya olmaması ya da çalışmamasıdır. Bu durumda tek yol, karşı tarafı taklit eden bir sahte servis yazmaktır: beklenen yanıtları döndüren, hataları da simüle edebilen küçük bir katman. Bu, geliştirmeyi karşı tarafın takviminden bağımsız hâle getirir.

Sahte servisin en değerli kullanımı mutlu yol değil, kötü yoldur. Gerçek ortamda 'karşı taraf beş saniye cevap vermezse ne olur' senaryosunu üretmek zordur; sahte serviste bir satırla üretilir. Zaman aşımı, yarım yanıt, beklenmeyen hata kodu ve aynı mesajın iki kez gelmesi — bu dört senaryoyu test etmeden bir entegrasyon üretime alınmamalıdır.

Bir de kayıt-oynat yöntemi var: gerçek ortamdan alınan yanıtları kaydedip testlerde tekrar oynatmak. Bu, karşı tarafın gerçek davranışını yakalar ve sahte servisin fazla iyimser olmasını engeller. Kaydedilen yanıtlarda kişisel veri varsa maskelemeyi unutmayın; test verisi de veri koruma kapsamındadır.

Entegrasyon projelerinin en çok tartışma çıkaran tarafı, arıza anında sorumluluğun kimde olduğudur. İki sistem arasında bir şey çalışmadığında, iki tedarikçi de karşı tarafı işaret etme eğilimindedir ve müşteri ortada kalır. Bunun önüne geçmenin tek yolu, projenin başında bir 'entegrasyon sahibi' belirlemektir: arıza anında ilk kimin bakacağı ve teşhisi kimin koyacağı yazılı olmalıdır.

Teşhisi mümkün kılan şey ise kayıttır. Giden ve gelen her mesajın, zaman damgası ve kimliğiyle birlikte kaydedilmesi, 'biz gönderdik' ile 'biz almadık' tartışmasını dakikalar içinde bitirir. Bu kayıtların ne kadar süre saklanacağı da baştan kararlaştırılmalı — kişisel veri içeriyorsa süresiz saklamak seçenek değildir.

Üçüncü madde bildirimdir: karşı taraf bir değişiklik yapacağında sizi ne kadar önceden haberdar edecek? Kurumsal entegrasyonlarda en sık yaşanan kesinti sebebi, karşı tarafın habersiz yaptığı bir sürüm değişikliğidir. Sözleşmeye konacak basit bir 'değişiklik bildirimi' maddesi, bir gecelik kesintiden ucuzdur.

Entegrasyonun diğer yönü, kendi sisteminizin dışarıya kapı açmasıdır. Burada ilk kural, açtığınız kapının açıldığı gün korunmasıdır: kimlik doğrulama, hız sınırı ve kötüye kullanım koruması sonradan eklenecek işler değildir. Bizim halka açık uçlarımızda bu koruma baştan var — çünkü koruma sonradan eklendiğinde temizlenecek veri de bırakır.

İkinci kural sözleşmenin kararlı olmasıdır. Dışarıya açtığınız bir uç, artık sizin değil kullanıcılarınızın da programıdır; alan silmek ya da anlamını değiştirmek onların sistemini bozar. Değişiklik gerektiğinde eskisini bir süre yaşatmak, yeni sürümü ayrı bir adreste sunmak ve geçiş için süre tanımak gerekir.

Üçüncüsü dürüstlük: neyin olmadığını da söylemek. Bizim ürünlerimizde bugün dışarıya olay bildirimi (webhook) yok; entegrasyon isteyen bir müşteriye bunu baştan söylüyoruz ve mevcut yollarla — uçlar ve dışa aktarım — neyin mümkün olduğunu anlatıyoruz. Yol haritasında olan bir şeyi var gibi anlatmak, entegrasyon projelerinde en pahalı yanlış anlamadır.

Entegrasyon, kurumsal projelerin görünmeyen ama en çok zaman alan kısmıdır ve başarısı birkaç ilkeye bağlıdır: her dış sistemi ayrı bir adaptörde tutmak, her veri parçasına tek bir sahip tanımlamak, mesajları kaybolmayacak biçimde kuyruğa yazmak, hataları görünür kılmak ve dışarı açtığınız her kapıyı ilk günden korumak.

Bir de en ucuz çözümü küçümsememek: ihtiyaç günlük aktarımsa, canlı bağlantı kurmak yerine dosya alışverişi çoğu zaman daha dayanıklıdır. Elinizde konuşturulması gereken sistemler varsa, önce hangi verinin kimin olduğunu konuşarak başlayalım — entegrasyon projelerinin yarısı bu soruyla çözülüyor.