Hogyan lesz egy SAP táblából külső alkalmazás által elérhető szolgáltatás?
Az előző részben azt mutattam be, miért volt jó döntés egy saját fejlesztésű okosotthon-kezelő alkalmazást SAP-hoz kapcsolni. A fő gondolat az volt, hogy az SAP-ra nem egyszerű adatbázisként érdemes tekinteni, hanem olyan vállalati rendszerként, amely üzleti szolgáltatásokat publikálhat külső alkalmazások számára.
Ebben a részben azt mutatom be, hogy ez miként épül fel SAP oldalon.
A cél egy olyan RAP/OData V4 szolgáltatás létrehozása, amelyen keresztül egy külső alkalmazás kontrollált módon tud adatot létrehozni vagy lekérdezni SAP-ban. A példában egy egyszerűsített felhasználói objektumot használok, mert ezen jól látszik a teljes objektumlánc: fizikai tábla, CDS view, behavior, projection, service definition, service binding és végül az OData endpoint.
Fontos: a bemutatott kódrészletek rövidített példák. Nem teljes production kódot mutatnak, hanem azt a logikát, amelyen keresztül érthetővé válik a RAP felépítése.
1. lépés: SAP oldali tábla létrehozása
A folyamat első eleme a fizikai adattárolás. Ebben a projektben a külső alkalmazásban létrejövő felhasználói adatok egy része SAP oldalon is megjelenik. Ehhez szükség van egy SAP oldali táblára, amely üzletileg értelmezhető formában tárolja ezeket az adatokat.
Egy egyszerűsített felhasználói tábla például tartalmazhat felhasználói azonosítót, felhasználónevet, e-mail-címet, aktív/inaktív státuszt, valamint létrehozási és módosítási technikai mezőket. Itt már az első fontos architekturális döntés megszületik: nem minden kerül SAP-ba. A külső alkalmazás saját belső működéséhez tartozó technikai részleteket nem érdemes automatikusan SAP-ba tükrözni. A táblának azt kell tartalmaznia, aminek SAP oldalon üzleti értelme van.
Például egy felhasználó SAP oldali reprezentációja hasznos lehet, de a teljes alkalmazáslogika, UI-állapotok vagy ideiglenes kliensoldali adatok nem tartoznak ide.
2. lépés: CDS view – a tábla üzleti nézetté alakítása
A következő réteg a CDS view. Itt a fizikai tábla már nem puszta tárolóként jelenik meg, hanem üzleti modellként. Ez azért fontos, mert a külső világ felé nem a nyers táblát akarjuk közvetlenül megnyitni. A CDS view egy kontrolláltabb, SAP oldali fejlesztési nézetet ad az adatok fölé.
Egyszerűsített példa:
A root view entity jelzi, hogy ez az entitás egy RAP business object gyökéreleme lehet. A mezőnevek itt már nem feltétlenül egyeznek meg a fizikai táblamezők nevével: a CDS rétegben üzletibb, olvashatóbb elnevezéseket adhatunk. Ez nem kozmetika. Ez az első absztrakciós réteg a fizikai tárolás és az üzleti modell között.
3. lépés: Behavior definition – mit lehet csinálni az objektummal?
A CDS view megmondja, hogyan néz ki az adatmodell. A behavior definition azt mondja meg, mit lehet csinálni vele. Ezen a ponton válik a modell valódi RAP üzleti objektummá. Itt definiálható például, hogy engedélyezett-e a létrehozás, a módosítás vagy a törlés. Itt történik a fizikai táblamezők és a CDS mezők összerendelése is.
Példa:
Ez a rész enterprise szempontból kritikus. Ha a külső alkalmazás létrehozhat felhasználót, de például nem törölhet, akkor ezt nem a külső kliens jóindulatára kell bízni. SAP oldalon is egyértelműen szabályozni kell, milyen műveletek engedélyezettek. A behavior definition tehát nemcsak kötelező technikai kör. Ez az üzleti objektum viselkedési szerződése.
4. lépés: Projection – a külső API modell kijelölése
A projection réteg elsőre feleslegesnek tűnhet. Ha már van CDS view és behavior, miért kell még egy újabb réteg? Azért, mert a belső SAP modell és a külső API-modell nem feltétlenül ugyanaz.
A belső modell tartalmazhat olyan mezőket, amelyek SAP oldalon szükségesek, de külső felhasználóknak nem akarjuk kitenni őket. A projection lehetőséget ad arra, hogy kijelöljük, mit lásson a szolgáltatás fogyasztója.
A projection rétegben már az API-ra szánt modellben gondolkodunk. Ez különösen akkor hasznos, ha a rendszer később bővül: például telepítésekkel, eszközökkel vagy automatizálási eseményekkel. A projection nem díszréteg, hanem biztonsági és architekturális határ. Itt döntjük el, hogy a belső SAP objektumból mi váljon külsőleg elérhetővé.
A projection behavior ugyanezt a gondolatot viszi tovább a műveletekre:
Ez azt jelenti, hogy a publikált modell szintjén is explicit módon engedélyezzük a létrehozást és módosítást. Ha valamit nem akarunk kitenni, itt sem használjuk.
5. lépés: Service definition – mit publikálunk?
A service definition mondja meg, mely entitásokat szeretnénk szolgáltatásként elérhetővé tenni. Itt már nagyon közel vagyunk ahhoz, amit a külső alkalmazás látni fog. Ha például a projection entitást „Users” néven tesszük ki, akkor ez a név jelenik meg a szolgáltatás látható entitásaként.
Példa:
Ez a lépés rövid, de stratégiailag fontos. Itt válik világossá, hogy nem a teljes SAP belső modellt publikáljuk, hanem egy kiválasztott, külső használatra szánt szolgáltatási modellt.
A későbbi bővítésnél ugyanez a service definition tartalmazhat például telepítéseket vagy eszközöket is, ha ezek logikailag ugyanahhoz a szolgáltatási határhoz tartoznak.
6. lépés: Service binding – hogyan lesz ebből OData V4 endpoint?
A service definition azt mondja meg, mit publikálunk. A service binding azt mondja meg, hogyan. A service binding során választjuk ki a technikai protokollt, például az OData V4-et. Ez kapcsolja össze a service definitiont a ténylegesen meghívható endpointtal.
Ellenőrzési pontok service binding után:
- a binding aktív-e;
- a megfelelő service definition van-e hozzárendelve;
- OData V4 binding típust választottunk-e;
- látszik-e a Users entity set;
- elérhető-e a metadata;
- a szolgáltatás publikált állapotban van-e.
Itt szokott előjönni az egyik legfontosabb tanulság: attól, hogy az objektumok aktiválódnak ADT-ben, az endpoint még nem biztos, hogy külső kliensből elérhető. A technikai publikálásnak is rendben kell lennie.
SAP GUI szerepe: amikor a publikálás adminisztrációs kérdés
Bizonyos környezetekben, különösen private cloud, on-premise rendszerekben előfordulhat, hogy a szolgáltatás publikálása vagy ellenőrzése nem ADT-ből történik. Ilyenkor SAP GUI oldali adminisztrációs tranzakcióban (IWFND/V4_ADMIN) is ellenőrizni kell a V4 service group állapotát.
Ez a projektben is fontos tanulság volt: a RAP objektumlánc fejlesztői oldalon elkészülhet, de a külső alkalmazás csak akkor tudja használni, ha a szolgáltatás technikailag is publikált és elérhető.
Ezért az endpointot nem tekintem késznek addig, amíg legalább a következőket nem ellenőriztem:
- aktivált SAP objektumok;
- publikált service binding;
- elérhető metadata;
- sikeres GET kérés;
- módosító művelet esetén sikeres CREATE vagy UPDATE;
- visszaolvasással igazolt adatmegjelenés SAP oldalon.
Ez a sorrend rengeteg hibakeresési időt spórol. Ha a szolgáltatás SAP oldalon sem működik stabilan, nincs értelme a külső C# kliensben keresni a hibát.
Tesztelés külső alkalmazás előtt
A külső alkalmazás bekötése előtt először SAP oldalon kell bizonyítani, hogy az endpoint működik. A minimum teszt egy GET kérés és a metadata elérése. Ezután jöhet egy CREATE teszt. Ha létrejön az adat, akkor visszaolvasással is ellenőrizni kell, hogy valóban megjelent SAP oldalon.
Ez azért fontos, mert a külső kliensnél már további hibaforrások jelennek meg: autentikáció, CSRF token, session/cookie kezelés, payload formátum, jogosultság vagy hálózati probléma.
A helyes sorrend tehát:
- először SAP oldali működés;
- utána külső kliens oldali kommunikáció;
- végül alkalmazásfolyamatba illesztés.
Ez a gondolkodás különösen fontos enterprise integrációknál. Nem mindegy, hol hibázik a rendszer. Egy jól szétválasztott ellenőrzési folyamat megmondja, hogy SAP oldali objektumproblémáról, publikálási gondról vagy külső kliensoldali kommunikációs hibáról van-e szó. Az SAP oldali tesztelésről a negyedik részben lesz szó.
Mit ad ez a rétegzés?
A RAP objektumlánc elsőre hosszúnak tűnhet:
Database Table → CDS View → Behavior → Projection → Service Definition → Service Binding → OData Endpoint
Gyakorlati oldalról viszont minden rétegnek külön felelőssége van:
- A tábla tárol.
- A CDS view üzleti nézetet ad.
- A behavior meghatározza a műveleteket.
- A projection kijelöli a külső API-modellt.
- A service definition megmondja, mit publikálunk.
- A service binding technikai endpointot készít.
- Az OData endpoint pedig a külső alkalmazás belépési pontja.
Ez nem felesleges bonyolítás, hanem kontrollált rendszerépítés.
Ha mindent közvetlenül táblaszinten kezelnénk, gyorsabbnak tűnne az indulás, de sokkal gyengébb lenne a rendszerhatár. A RAP rétegzés pont abban segít, hogy a fizikai tárolás, az üzleti modell, a publikált API és a technikai endpoint ne keveredjenek össze.
Tanulság
A RAP/OData V4 endpoint publikálása nem egyetlen kattintás, hanem több egymásra épülő döntés eredménye.
A legfontosabb tanulság számomra az volt, hogy az SAP oldali integrációt nem az endpointnál kell elkezdeni gondolatban, hanem az üzleti objektumnál. Először tisztázni kell, milyen adatnak van SAP oldalon értelme, milyen műveleteket akarunk engedni, mit akarunk publikálni, és milyen technikai formában érheti el ezt egy külső alkalmazás.
Ebben a felépítésben a RAP nem akadály, hanem védőkorlát. Segít abban, hogy a külső alkalmazás ne közvetlenül az SAP belsejébe nyúljon, hanem egy szabályozott, üzleti szempontból értelmezhető szolgáltatást használjon.
A sorozat következő részében a külső alkalmazás oldaláról nézzük meg ugyanezt: miért nem elég, hogy az endpoint SAP oldalon működik, és mire kell figyelnie egy C# kliensnek az autentikáció, CSRF token, session kezelés, payload formátum és biztonságos adatküldés során.
