REST API’lerde iç içe veri yapıları ve tablolar

Test sisteminde çalışıyordu. Üretimde ilk gün bozuldu ve kimse gövdedeki tek satırlık farkı göremedi.

Hikâye çoğu entegrasyon projesinde aynı yerden başlar. Geliştirici kaynaktan bir örnek yanıt alır, onu düz bir JSON gövdesine çevirir, sözleşmeyi bu gövdenin üzerine kurar ve ön yüz ekibine gönderir. Örnek doğrudur; sözleşme değildir.

Örnek gövdeden çıkarılan şemanın açığı

Sebep basit: SAP fonksiyon parametreleri düz değil. Bir yapı başka yapıları veya tabloları içerebilir. Örnek veriden çıkarılan şema, yalnızca o örnekte hangi alanların dolu geldiğini anlatır; parametrenin gerçek tipini anlatmaz.

Fatura da buna göre gelir. Fonksiyon boş olmayan bir tablo parametresi döndürdüğü gün, tüketici tarafı ya alanı hiç görmez ya da tek değer beklediği yerde liste alır. Hata mesajı genellikle SAP’den değil, karşı taraftaki ayrıştırıcıdan çıkar; bu yüzden aranacak yer de yanlış seçilir.

Tip kararını parametre tanımına bağlamak

API akışı SAP tablo, program, işlem kodu, fonksiyon ve iDataView nesnelerini işleyebilir. Fonksiyon parametrelerinde ayrıştırıcı, EXID değerine bakarak karakter, sayı, yapı ve tablo sonuçlarını uygun tipe dönüştürür. Yani karar örnek gövdeye değil, parametrenin katalogdaki tanımına dayanır; servis çıktısı da bu yapıya uygun biçimde JSON veya XML olarak hazırlanır.

Pratikte işleyen sıra şudur: giriş ve çıkış parametrelerini gerçek katalog bilgisiyle okumak, yapı ve tablo tiplerini ayrı işaretlemek, tüketiciye vereceğiniz örnek gövdeyi bu tiplerden üretmek. Örnek gövde belgeden değil, tanımdan çıkmalı. Bu sırayı bir kez uyguladığınızda, karşı tarafa verdiğiniz örnek bir tahmin değil, tanımın çıktısı olur.

Fonksiyon çıktısının kapsamını daraltmak

Bir de kapsam kararı var. Fonksiyonun döndürdüğü her alanı servise koymak zorunda değilsiniz. Alan kümesini daraltmak yanıtı küçültür ve sözleşmeyi okunur kılar; kayıt sınırı ile sabit parametreler de aynı işi görür.

Karar verirken sorulacak soru teknik değil, iş tarafında: tüketici bu alanla ne yapacak? Cevabı olmayan alan sözleşmeye girmesin, çünkü bir kez girdikten sonra çıkarılması sözleşme değişikliği demektir. Sözleşmeden alan çıkarmak, sözleşmeye alan eklemekten her zaman daha pahalıdır.

Derin yapı desteğinin sınırları

  • Özel bir fonksiyonun iş kuralı kendiliğinden anlaşılmaz. Hangi giriş kombinasyonunun hangi hatayı ürettiği ayrıca test edilir.
  • İç içe yapıların işlenebilmesi, veri paketi büyüklüğü veya yanıt süresi için bir taahhüt değildir; bu konuda yayımlanmış bir ölçümümüz yok.
  • SOAP tarafında yapılandırma alanları bulunur, ancak çağrı çekirdeği ortak HTTP yolunu kullanır. WSDL içe aktarma ve WS-Security kapsamı doğrulanmış değildir.

Kendi ortamınızda hızlı bir karşılaştırma yapabilirsiniz: aynı fonksiyonu tablo parametresi boş dönecek bir seçimle, bir de dolu dönecek bir seçimle çağırın. İki yanıt yapı olarak aynıysa sözleşmeniz sağlamdır. Değilse sözleşmeyi değil, örneği yazmışsınız.

Tipinden emin olamadığınız bir fonksiyon varsa, sözleşmeyi karşı tarafa vermeden önce parametre listesini birlikte okuyalım. Yapı ve tablo parametrelerini işaretlemek bugün yarım günlük iş; entegrasyonun son haftasında aynı iş değil.