ABAP RESTful programozási modell

Rövid áttekintés a programozási modell múltjáról és az új funkciókról.

ABAP RESTful platform programozási modell

Az ABAP RESTful programozási modell (RAP) az ABAP Platform-ba épített keretrendszerek és új nyelvi elemek és az azt támogató eszközök és bevált módszerek gyűjtőneve. Az ABAP alapú web-service backend alkalmazások fejlesztésének irányát jelöli ki. Az absztraktabb, letisztultabb formában definiálható adatmodell entitásaiból pár kattintással előnézetet kaphatunk egy SAPUI5 alkalmazás formájában, ahol jóváhagyható a működés a tényleges UI alkalmazás fejlesztésének megkezdése előtt. A programozási modell múltjáról és az új funkciókról röviden olvashatunk az alábbiakban.

A RAP az ABAP Platform csapat azon erőfeszítése nyomán született meg, hogy modernizálja az alkalmazásfejlesztést. Maga a törekvés és a felhasznált technológiák nem új keletűek, inkább a meglévők továbbgondolása. Az evolúciós lépcsőben őt megelőző programozási modellben (ABAP Programming model for SAP Fiori ≥ ABAP 7.5) külön eszköztár és keretrendszer áll rendelkezésre egy modern alkalmazás létrehozásához: a Gatweway Service Builder-ben (SEGW) lehetőség van létrehozni a modern alkalmazás backend-et biztosító szabványos OData v2 service-t, az Internet Communication Framework (ICF) alatt hozzáadható a modern SAPUI5 frontend alkalmazás. A backend service egyes funkcióinak megvalósításához ABAP fejlesztőre van szükség, aki a Gateway Service-szel kellő mértékben viszonylag rövid idő alatt képes lehet megismerkedni.

Az ABAP RESTful programozási modell szeretne újítani a fejlesztés menetén azáltal, hogy standardizálja azt és egyetlen eszközre az Eclipse ABAP Development Toolkit-re (ADT) fókuszálja. Abból indulhattak ki az ABAP platform csapatnál, hogy ABAP 7.5 óta az alkalmazásfejlesztők úgyis az ADT-t használják, legyen ebben az eszközben létrehozható a service és ne legyen szükség külső eszköz, mint az SEGW használatára. Minden fejlesztési objektumhoz külön varázslót ajánl az ADT, egyes objektumokhoz segítségként választhatjuk, hogy kérünk egy stub-ot. A szokásos kódkiegészítés funkció, elem információk és statikus kódellenőrzés segíti a fejlesztést.

Az ABAP CDS nyelv ABAP 7.5 óta elérhető és már a HANA Platform alatt láthattuk, hogy a CDS egy olyan leíró, ami elegendő egy OData service definiáláshoz. Az ABAP RESTful programozási modellel ezt az ötletet emelték át az ABAP Platform-ba: nincs szükség külső eszközre, mint az „SEGW”, ahol definiálni szükséges az OData entitást mert az következik a CDS modellből, sőt maga a szerviz definíció protokollfüggetlen, nem is szükséges feltétlenül OData entitásban gondolkodni (bár egyelőre csak ez a támogatott). Két új fejlesztési objektumra van szükség: a protokollfüggetlen service definíciós leíróra és a protokollt meghatározó service binding-ra. A definícióban adható meg az adatmodellből kiajánlott entitások felsorolása, így ugyanazt az adatmodellt több service definiálásához is újra felhasználhatjuk.

A Business Object (BO) fogalmát is leporolták az ABAP RESTful programozási modellben. Pongyolán fogalmazva a BO a CDS segítségével létrehozott adatmodellből a felhasználó felé prezentált entitást és annak futás idejű implementációját jelenti. A behavior (viselkedés) új fejlesztési objektum, egy leíró, amiben megadható az adatmodell entitásain definiált elvégezhető funkciók és műveletek halmaza, a zárolás, jogosultságkezelés illetve a draft (piszkozat) funkció engedélyezése. A BO életciklusát az interakciós fázisra és a mentési folyamatra (save sequence), illetve ezen belül további lépésekre bontották. A BO futás idejű implementációjára két módozatot kínál a RAP: a menedzselt (managed) és a „menedzseletlen” (unmanaged) forgatókönyvet (scenario). Előbbi esetében a futtatókörnyezet felel az életciklus során minden lépésről, a fejlesztőnek egy sor kódot sem kell írnia minden megy „egyenesen a dobozból”, utóbbi esetben az alkalmazásfejlesztő gondoskodik miden lépésről, egy implementációs osztályt létrehozva megírja az egyes lépésekhez tartozó metódusok kódját, meglévő alkalmazáskód felhasználására is itt van lehetőség.

A RAP keretrendszere lehetővé teszi, hogy a kész service-t kipróbáljuk UI kód írása nélkül az úgynevezett Fiori Elements előnézet alkalmazásban, ami egy böngészőben futó SAPUI5 alkalmazás. Talán jobban érthetjük a dolgot, ha tudjuk, hogy a Fiori Elements alkalmazást régebben Smart Templates-nek hívták, ami attól volt smart, hogy az adatmodellben szereplő UI annotációk vezérelték további kódolás nélkül. A UI annotációk az adat prezentációjáról nyilatkoznak és a UI komponensekbe bele van kódolva, hogy hogyan kell viselkedni az egyes direktívák nyomán. ABAP CDS-ben ezek az annotációk hozzáadhatóak explicit módon így megjelennek az OData service metaadatában, ami alapján előállhat a Fiori Elements előnézet egy kattintásra minden további UI kód nélkül. Fejlesztői teszt, üzleti jóváhagyás könnyen és azonnal végezhető az előnézet alapján nem szükséges megvárni azt a kört amíg a tényleges UI alkalmazás fejlesztésre és telepítésre kerül.

2019-ben adták ki az első változatot és azóta is folyik a fejlesztése az új programozási modellnek és ígéretes irányba tart. Látszik, hogy a CDS-t helyezik előtérbe nem csak itt, hanem más technológiákban is, például a Cloud Foundry-s fejlesztések jövője a Cloud Application Programming model (CAP) szintén CDS központú. Érdemes ezzel a technológiával foglalkozni a jövőben is, standard riport programok és ALV listák könnyen kiválthatók egy OData service-szel és egy Fiori Elements alkalmazással.
Ha ki szeretnénk próbálni lehetőség van S/4 HANA Cloud 1808-as verzióban, on-prem 1909 verzióban limitált scope-pal, például a managed scenario nem elérhető. Steampunk alatt – ami a SAP Cloud ABAP környezetet vagy ABAP PaaS vagy SAP Cloud Platform ABAP environment – a legfrissebb fejlesztéseket próbálhatjuk ki, trial verzióban is elérhető, de itt egy közös fejlesztői környezetet biztosítanak több fejlesztőnek regionális szinten.