OData Servisi Oluştururken Yapılan 10 Hata

Kısaca bahsetmek gerekirse oData servisi; SAP ile dış dünya arasında veri alışverişini sağlayan bir protokoldür.

SAP artık bütün web tabanlı iletişimi bu yeni protokol üzerinden yapmaktadır. Fiori uygulamalarının kullandığı servisler de oData servisleridir.

SAP danışmanları tarafından daha önceleri geliştirilen servislerde, örneğin soap web servislerde geliştiricinin servise müdahelesini çok düşük seviyede olurken, oData servisinde durum biraz daha farklı ve geliştiricinin dikkat etmesi gereken bir çok konu mevcut.

Gördüğüm kadarıyla son yıllarda SAP danışmanları oData servisi oluştururken kulaktan dolma yöntemlerle ya da sezgisel yöntemlerle, bu bence böyle olmalı şeklinde geliştirmeler yapıyor. Bunu yaparken de çok ciddi hatalar yapabiliyorlar.

Bugüne kadar karşılaştığım en ciddi 10 hatayı aşağıda paylaşarak, farkındalık oluşmasına katkı sağlamak istiyorum.

1. SEGW işlem kodundan bihaber olmak

SAP, geliştiricilerin oData servisi oluşturabilmesi için çok güzel bir arayüz tasarlamış ve bunu SEGW işlem koduyla önümüze servis etmiş durumda. Bu durumdan habersiz olup SICF üzerinden servis oluşturup, bu servis ile json formatında veri dönerek, odata servisi oluşturduğunu zanneden bir takım güzel danışmanlarımız mevcut.

2. OData servisini ön uçta geliştirmek

Genel olarak Fiori (frontend) sistemiyle ile ERP (backend) sistemi farklı makineler üzerine kurulur. Bu durumda oData servisleri istisnalar hariç backend sistemde oluşturulmalı, Fiori sisteminde oluşturulmamalıdır. Nedir bu istisnalar derseniz, örneğin ERP sistemi o kadar eskidir ki SEGW işlem kodunun bulunduğu paket sisteme yüklenemiyordur, yüklense bile çok eski seviyede kalıyordur ama sizin son sürüm bir SEGW’ye yani son model bir oData servisine ihtiyacınız vardır.

3. SEGW işlem kodunu süs olarak kullanmak

SEGW işlem kodunu sadece servisin “entity”lerini oluşturmak için kullanan ve geri kalan herşeyi manuel ABAP koduyla yazan danışmanlarımız da malesef mevcut. 1. madddede belirttiğim gibi SAP, bize çok güzel bir oData servisi oluşturma arayüzü sunmuş durumda. Bu arayüzde create, update, delete, getEntity, getEntitySet metodlarını direk olarak RFC’leri çağıracak şekilde eşleme yapabiliyoruz ve sonrasında kod otomatik olarak bu arayüz tarafından üretiliyor.

4. “Function import”tan bihaber olmak

“Create” metodu yerine “update” metodu kullanımı, “update” metodu yerine “create” metodu kullanımı da sıkça rastladığım hatalardan biri. Olmayan bir veriyi oluşturmak için “create” metodu, var olan bir verinin alanlarını güncellemek için de “update” metodu kullanılmalıdır. Bir de onay uygulamalarında sıkça gördüğüm “update” metodu kullanımı hatası var. Verinin hiçbir alanı değişmemesine rağmen veriye onay diye bir alan eklenmekte bu alan doldurularak onay/red işlemi yapılmaktadır. Halbuki SAP bize bunun için “function import” dediğimiz yapıyı sunmaktadır. Bunun için 2 farklı “function import” oluşturulmalı, isimleri de “SiparisOnayla”, “SiparisReddet” gibi olmalıdır.

5. Hata mesaj yönetimini doğru yapamamak

Bazı danışmanlarımız yine “update”, “create” ve “delete” metodlarının sonuçlarını “entity”e ekledikleri “message” alanı ile yapmaktadırlar. Fakat siz hangi BAPI’de sonucun bu şekilde döndüğünü gördünüz ki?

Bu işin de doğru yöntemi çağırılan fonksiyona “bapiret2” tipinde bir “table” veya “export” parametresi eklemek ve eşleme ekranında bu parametreyi log olarak işlemek olmalıdır.

6. “Batch” ile “create deeep entity” ayrımı yapamamak

“Batch” işlemi toplu bir şekilde veri kaydederken kullanılmalıdır. Fakat bu veriler arasında bir bağlantı varsa ve biri olmadan diğeri olamıyorsa bu veri “create deep entity” yöntemi kaydedilmelidir. Örnek vermek gerekirse toplu onay vermek isteniyorsa “batch” işlemi kullanılmalı, başlık-kalem ilişkisi olan bir veri kaydedilmek isteniyorsa “create deep entity” yöntemi kullanılmalıdır.

7. “Search help” “entity”sini kod ile doldurmak

Her arama yardımı için ayrı bir fonksiyon yazılması durumu da malesef yapılan hatalardan birisi. Aslında SEGW işlem kodu bir kaç adımda “search help”i import edebilmekte, “entity”isini oluşturabilmekte ve bu “entity”in eşleşmesini yapmaktadır.

8. “Ext” uzantılı olmayan sınıfa müdahele etmek

SEGW işlem kodu 4 ana sınıf üretmektedir. Bunlardan “ext” uzantılı olan 2 sınıfı bizim müdahelemize açık bırakmaktadır. Fakat bununla yetinmeyen bazı arkadaşlarımız her seferinde yeniden üretilen sınıfların içine kod yazmakta ve bu kodu saatli bomba gibi oraya bırakmaktadırlar. Ne zaman başka bir danışman gelir servisi tekrar üretirse o kod oradan yok olur.

9. Standart sınıflarda “repair” yapmak

Hayatında ilk defa oData servisi “debug”layan genç dimağlar hatayı standart sınıflarda bulmakta ve bu sınıflara “repair” yapmaktadırlar. Özgüven güzel birşey olmakla birlikte fazlası hepimize zarar vermektedir. Hatayı önce kendimizde aramamız en doğru olanıdır.

10. Güvenlik açığı oluşturmak

Bu maddeyi belki de en başa yazmam gerekiyordu ama sona bıraktım. Benim en çok dikkat ettiğim konulardan birisi de güvenlik açığını en az seviyeye indirme konusudur.

Sıkça karşılaştığım hatalardan birisi de servisten dönen veriyi servisi çağıran kişinin görmeye yetkisi var mı kontrolünün yapılmaması ve veriyi güncellemek isteyen kişinin bunu yapmaya yetkisinin olup olmadığını kontrolünün yapılmamasıdır.

Örneğin bir “entity”nin “id” diye bir anahtar alanı var ve bu numerik “id” alanı 1’er 1’er artıyor. Servise “id” gönderilerek verinin detayları çekiliyor. Kurnaz bir kullanıcı da bastı f12’ye çağırılan servisin adresini gördü. Sonra “id” değerini 1’er 1’er artırarak url’yi çağırdı ve görmemesi gereken bütün bilgileri gördü. Bu durum oluşsun istenmiyorsa “backend” sistemde yetki kontrolü mutlaka yapılmalıdır.

Sizlerin de eklemek veya düzeltmek istediğiniz maddeler varsa duymaktan mutluluk duyarım.