Mimari toplantısında en sık düşülen yanılgı bir ad yüzünden. Ekranda “gelen servis” yazıyor, herkes dış sistemin bize çağrı yaptığı akışı anlıyor ve tartışma yarım saat boyunca yanlış uçtan yürüyor.
Gelen servis adının yanıltıcı tarafı
Oysa akış ters yönde: çağrıyı iDataEngine başlatır, haricî servisten dönen yanıt işlenir. Adı bu şekilde okumak mimari tartışmalarının yarısını kısaltır. Karşı yön, yani dışarıdan gelen çağrılar, giden servis tarafında yaşar.
Bu netleştikten sonra asıl karar geliyor: dış servis çağrısı bir geliştirmenin içinde mi dursun, yoksa kayıtlı bir tanım olarak mı?
Haricî çağrı tanımında duran ayarlar
Tanım yolunda şunlar aynı kayıtta toplanır:
- URL, HTTP metodu, içerik tipi ve başlıklar.
- Kimlik doğrulama: Basic, Bearer belirteci veya API anahtarı biçiminde başlık üretimi.
- Değişkenlerle kurulan gövde şablonu ve sorgu parametreleri.
- Zaman aşımı, yönlendirme takibi ve sertifika doğrulaması gibi istemci ayarları.
- Yanıtın nasıl okunacağı: JSON, XML, HTML veya düz metin.
Yanıt tarafında XML, Jackson XmlMapper ile JSON’a çevrilir; HTML gövdesi ve tabloları Jsoup ile ayrıştırılır. Yani düzgün bir API sunmayan eski bir servisten veri almak mümkün, ama bu yolu kırılgan olduğunu bilerek kurmak gerekir. Kaynak sayfanın işaretlemesi değiştiğinde entegrasyon sessizce bozulur.
Kodun içinde duran çağrının bedeli başka yerde çıkıyor: kimlik bilgisi kaç dosyada geçiyor, zaman aşımı kaç saniye, üç yıl önce bunu yazan kişi ayrıldıysa cevabı kim biliyor? Tanımı tek yerde tutmak, sözleşme değiştiğinde düzeltmeyi tek yerde yapmanızı sağlar; sözleşmenin değişmesini engellemez.
Olay aksiyonları sırayla işlenir
Kayıtlı bir haricî servis, olay yönetiminde REST aksiyonu olarak da çağrılabilir. Bu durumda gövde şablonundaki değişkenler olay verisinden beslenir: satır alanları, üst veri ve olay bağlamı şablona yerleşir. Bir SAP tablosunda durum alanı değiştiğinde haricî bir sipariş servisine bildirim göndermek tam olarak bu yolla kurulur.
Burada bilinmesi gereken bir davranış var: dağıtıcı aktif tetikleyicileri sırayla okur ve aksiyonlar sıralı işlenir. Bir aksiyon yavaş bir servise bağlıysa arkasındaki işler de bekler. Hata durumunda zincirin devam etmesi mi, durması mı gerektiği ayarı bu yüzden önemli.
Zaman aşımı ve hata yanıtını birlikte denemek
Çoğu ekip yalnız başarılı yanıtı test eder. Haricî servislerde asıl bilgi hatada: 401 mi dönüyor, 200 ile hata gövdesi mi geliyor, yoksa zaman aşımına mı düşüyor? Beklenen davranışı önce yazıp iki senaryoyu birlikte denemek, üretimdeki ilk kesintide neye bakacağınızı belirler.
Şunu da açık yazalım: haricî servisin erişilebilirliği ve sözleşme kararlılığı iDataEngine dışındaki bağımlılıklar. Tanım bu bağımlılığı görünür kılar, ortadan kaldırmaz.
Elinizdeki dış entegrasyonlardan en kırılgan olanını seçin; genellikle kimsenin dokunmak istemediği olur. Onun URL’sini, kimlik bilgisini, zaman aşımını ve hata davranışını tek bir tanıma taşıyalım, sonra bilerek bozup ne olduğunu izleyelim.