Talep genellikle tek cümleyle gelir: “Bize şu veriyi API olarak verin.” Cümle kısa, iş uzun. Çünkü teknik taraf bir adres üretmekten ibaretken, karar tarafı haftalarca konuşulmayı bekler.
Kurumların bu noktada seçtiği iki yol var. Birincisi, talebi bir geliştirme işi olarak ele almak: her tüketici için ayrı bir çıkış yazmak, alanları o haftanın ihtiyacına göre seçmek, sonra bir daha dönmemek. İkincisi, aynı işi bir servis tanımı olarak kurmak ve kararları yazılı hâle getirmek.
İlk yolun bedeli hemen görünmez. Altı ay sonra aynı veriyi isteyen ikinci ekip geldiğinde, ilk çıkışın hangi alanları hangi gerekçeyle döndürdüğünü kimse hatırlamaz. İş yeniden yapılır.
Adres üretmek ile servis sözleşmesi yazmak
iDataEngine’de giden servis tanımına kaynak olarak bir SAP tablosu, programı, işlem kodu, fonksiyonu veya iDataView bağlanır. Arka uç; servis adı ile müşteri ve sistem bilgisinden URL güvenli bir service GUID üretir ve çağrılacak adresi verir. Buraya kadarı dakikalar sürer.
Karar kısmı bundan sonra başlar: tüketicinin göreceği alan kümesi, özet veri, dil, kayıt sayısı ve çıktının JSON mu XML mi olacağı. /app/api uç noktası GET ve POST isteklerini kabul eder; nesne türüne göre URL veya gövdedeki seçim parametreleri SAP çalıştırma isteğine dönüştürülür.
REST servisinin arkasındaki parametre ayrımı
Parametrelerde sonradan pahalıya gelen bir ayrım var: bazı parametreler servis tanımında sabitlenir, bazıları çağrı anında geçilebilir. Sabitlenmiş bir parametre tekrar gönderilmeye çalışılırsa istek reddedilir.
Bu ayrımı baştan yapmak, altı ay sonra sorulacak bir soruyu ortadan kaldırır: “Neden bu iş ortağı bütün şirket kodlarını çekebiliyor?” Şirket kodu, iş yılı veya tesis gibi alanları sabitlemek genellikle doğru karardır; tarih aralığını çağrı anına bırakmak da öyle.
Servis GUID’i ne değildir
Bir yanılgıyı açıkça yazmak gerekir: service GUID bir parola değildir. GUID, servis adı ile müşteri ve sistem bilgisinin Base64 kodlanmış hâlidir; adresi çözümler, kimlik doğrulamaz. /app/api çağrıları Basic Authentication ister ve yalnız SERVICE tipindeki aktif kullanıcıyı, müşteri ve sistem atamasıyla birlikte kabul eder.
Bunun üzerine servis bazında kullanıcı listesi, izin verilen ve engellenen IP listeleri, dakika ve saat bazlı istek limitleri eklenebilir. Bir sınırı bilerek kurun: IP bilgisi alınamazsa denetleyici geriye uyumluluk için IP kontrolünü atlayabilir, dolayısıyla IP kuralı tek başına bir kapı değildir.
Yayına alınan servisin istek kayıtları
Servis yapılandırmasına göre istek, yanıt ve yürütme üst verisi API günlük tablolarına yazılır. Bu kayıtlar iki soruyu cevaplar: tüketici gerçekten hangi sıklıkla çağırıyor ve hata kaynakta mı, yetkide mi, limitte mi oluşuyor.
Kendi ortamınızda yapabileceğiniz basit bir kontrol var: ilk iki haftanın istek kayıtlarını açın ve gerçek çağrı desenine bakın. Dakika limitini tahminle koyduysanız, o kayıtlar limiti gerçek kullanıma göre yeniden ayarlamanın en kolay yolu.
Son olarak iki kararı ayrı tutmakta fayda var: servisin çalışıyor olması, o verinin paylaşılmaya uygun olduğunu göstermez. Teknik erişim kararını entegrasyon ekibi verir; veri paylaşım kararını genellikle başka biri.
Dışarıdan sürekli istenen bir SAP nesnesi seçin ve kısa bir teknik oturumda o servisin alan kümesini, sabit parametrelerini ve istek limitini birlikte yazalım. Masadan bir adresten fazlasıyla, bir sözleşmeyle kalkın.