Miért nem elég, ha az endpoint SAP oldalon működik?
Az előző részben azt mutattam be, hogyan épül fel SAP oldalon egy RAP/OData V4 szolgáltatás. Végigmentünk azon az objektumláncon, amely a fizikai táblától a CDS view-n, behavior rétegen, projectionön, service definitionön és service bindingon keresztül elvezet egy külső rendszer által elérhető endpointig.
Ez azonban csak az integráció egyik fele.
Attól, hogy egy szolgáltatás SAP oldalon működik, még nem biztos, hogy egy külső alkalmazásból is stabilan, biztonságosan és üzletileg helyesen használható. A másik oldal legalább ugyanilyen fontos: hogyan viselkedik a kliens, milyen adatot küld, hogyan kezeli az autentikációt, hogyan dolgozik CSRF tokennel, hogyan tartja meg a sessiont, és mit csinál akkor, ha az SAP oldali írás nem sikerül.
A saját okosotthon-kezelő alkalmazásom SAP-integrációja során ez volt az egyik legfontosabb tanulság: az endpoint publikálása nem a projekt vége, hanem az a pont, ahol a külső alkalmazás felelőssége igazán elkezdődik.
A működő GET még nem teljes integráció
Fejlesztés közben könnyű hamis biztonságérzetbe kerülni. Ha az OData szolgáltatás metadata oldala elérhető, a GET kérés működik, és SAP Gateway Clientből látszanak az adatok, akkor elsőre úgy tűnhet, hogy az integráció készen van. Valójában ilyenkor csak azt bizonyítottuk, hogy az SAP oldali szolgáltatás elérhető.
Egy külső alkalmazás teljesen más helyzetben van. Neki nem egyszeri tesztkérést kell küldenie, hanem valódi alkalmazásfolyamatba kell illesztenie az SAP-kommunikációt. Például amikor létrejön egy felhasználó, egy telepítés vagy egy okoseszköz, az alkalmazásnak el kell döntenie, mikor küld adatot SAP felé, milyen formátumban küldi, és hogyan kezeli, ha az SAP válasza nem sikeres.
Ezért fontos különbséget tenni két állítás között.
Az egyik: az endpoint SAP oldalon működik.
A másik: a külső alkalmazás megbízhatóan integrálódik az SAP szolgáltatáshoz.
A kettő nem ugyanaz.
A külső kliens nem csak HTTP-kérést küld.
Egy RAP/OData szolgáltatás esetében a külső kliensnek több felelőssége van, mint elsőre gondolnánk:
- Hitelesítetten kell kommunikálnia az SAP-rendszerrel,
- Módosító műveleteknél kezelnie kell a CSRF tokent,
- Meg kell tartania a sessionhöz tartozó cookie-kat,
- Pontosan olyan payloadot kell küldenie, amelyet az SAP oldali szolgáltatás vár,
- Emellett figyelnie kell arra is, hogy érzékeny vagy alkalmazásspecifikus adatok ne kerüljenek át feleslegesen SAP-ba.
Ezért nem szerencsés, ha az alkalmazás különböző pontjain elszórva jelennek meg nyers HTTP-hívások. Tisztább megoldás, ha az SAP-kommunikáció külön integrációs rétegbe kerül. Így az alkalmazás üzleti logikája nem keveredik össze azzal, hogy pontosan milyen header, token, cookie vagy endpoint szükséges az SAP hívásához.
Ez a réteg nem csak technikai kényelmet ad. Rendszerhatárt is teremt.
CSRF token és session kezelés
Az egyik legfontosabb technikai tanulság a CSRF token és a session/cookie kezelés volt.
Egy lekérdező GET kérés általában egyszerűbb. Egy POST, PATCH, PUT vagy DELETE kérés viszont már adatot módosít, ezért az SAP oldali védelem miatt CSRF tokenre is szükség lehet.
A tipikus folyamat egyszerűen így írható le: a kliens először lekéri a tokent, az SAP válaszban visszaadja azt, majd a kliens a módosító kérésnél visszaküldi ugyanazt a tokent. A kritikus rész az, hogy a sessionhöz tartozó cookie-kat is meg kell tartani. Ha a token megvan, de a session elveszik, a módosító kérés ugyanúgy hibázhat.
Ezért ha SAP Gateway Clientből működik a POST, de C# kliensből nem, nem biztos, hogy az SAP oldalon van a probléma. Lehet, hogy a külső kliens nem ugyanazt a technikai kontextust viszi tovább.
A másik gyakori hiba az adatküldés formátuma.
Egy külső kliensnek nem azt kell elküldenie, ami neki kényelmes, hanem azt, amit a publikált OData szolgáltatás elvár. Ez különösen akkor fontos, amikor a C# alkalmazás és az SAP eltérően reprezentál bizonyos értékeket.
Például egy C# modellben természetes lehet a true vagy false érték. SAP oldalon viszont előfordulhat, hogy egy logikai állapot technikailag karakteres értékként jelenik meg, ahol az igaz érték „X”, a hamis pedig üres érték. Ha a kliens rossz formátumban küldi ezt át, akkor a kérés hibás lehet, vagy rossz adat jöhet létre.
Ugyanez igaz az azonosítókra, dátumokra, decimális értékekre, mértékegységekre és kötelező mezőkre is.
Ezért kell mapping réteg. Az alkalmazás belső modellje és az SAP felé küldött payload ne legyen ugyanaz a fogalom. A mapping réteg feladata, hogy az alkalmazás adatait lefordítsa arra a szerződésre, amelyet az SAP szolgáltatás vár.
Biztonsági határok: mit nem küldünk át?
Egy integráció minőségét nem csak az mutatja meg, hogy milyen adatot képes átvinni. Legalább ennyire fontos, hogy mit nem visz át. A projektben alapelv volt, hogy az SAP mirror nem válhat kontrollálatlan adatdumpá. Csak azok az adatok kerülhetnek át, amelyeknek SAP oldalon üzleti értelme van.
- Plain jelszó nem kerülhet SAP-ba.
- Alkalmazásspecifikus token nem kerülhet SAP-ba.
- Session információ nem kerülhet SAP-ba.
- Felesleges debug adat nem kerülhet SAP-ba.
Ugyanez igaz a logolásra is. Hibakeresés közben csábító lehet minden headert, payloadot és választ kiírni, de ez biztonsági kockázat. Egy jó integrációs log segít megtalálni a hibát, de nem tartalmaz titkokat.
Feature flag és best-effort mirror
Fejlesztési fázisban sokat segített, hogy az SAP mirror kapcsolható funkcióként működött. Ha a kapcsoló ki van kapcsolva, az alkalmazás csak lokálisan dolgozik. Ha be van kapcsolva, a fontos üzleti adatokat SAP felé is továbbítja. Ez biztonságosabb fejlesztést tesz lehetővé, mert nem minden lokális teszt hoz létre automatikusan SAP oldali adatot.
Ez illeszkedik az első részben bemutatott architektúrához is: az SAP nem veszi át az alkalmazás teljes működését, hanem üzleti integrációs pontként jelenik meg mellette.
Itt jön be a best-effort mirror gondolata is. Ha a lokális mentés sikeres, de az SAP oldali írás átmenetileg hibázik, akkor nem feltétlenül kell az egész alkalmazásfolyamatot megállítani. Ez természetesen üzleti döntés kérdése. Ha az SAP oldali írás kritikus feltétel, akkor a folyamat nem mehet tovább. Ha viszont a mirror kiegészítő üzleti reprezentáció, akkor kezelhető külön hibaként.
A lényeg: az SAP-hibát nem szabad elnyelni. Láthatóvá kell tenni, naplózni kell, és később újrapróbálkozási lehetőséget kell adni rá.
Read-after-write: ne higgyük el vakon, hogy sikerült
Egy sikeres HTTP válasz jó jel, de fejlesztési fázisban nem mindig elég.
Ha az alkalmazás létrehoz valamit SAP oldalon, érdemes utána visszaolvasással is ellenőrizni, hogy az adat valóban megjelent-e. Ez a read-after-write ellenőrzés.
Ez különösen hasznos, mert nem csak azt mutatja meg, hogy a kérés technikailag lefutott, hanem azt is, hogy az SAP oldali állapot megfelel-e annak, amit vártunk.
Így hamarabb kiderülhet például egy rossz mezőmapping, hibás boolean reprezentáció, hiányzó azonosító vagy nem megfelelő kapcsolat a felhasználó, telepítés és eszköz között.
Tanulság
A sorozat első részében az architekturális döntésről volt szó: miért érdemes az SAP-ra nem adatbázisként, hanem üzleti szolgáltatásokat publikáló rendszerként tekinteni.
A második részben az SAP oldali objektumláncot mutattam be: hogyan épül fel a RAP/OData V4 endpoint.
A harmadik rész legfontosabb tanulsága az, hogy az endpoint publikálása csak az integráció fele. A másik fele a külső kliens felelőssége.
Egy külső alkalmazásnak tudnia kell, hogyan kommunikáljon biztonságosan, milyen adatot küldhet, mit nem küldhet, hogyan kezeli a tokeneket és sessionöket, hogyan különíti el a lokális működést az SAP mirror folyamatától, és hogyan bizonyítja, hogy az adat valóban megjelent SAP oldalon.
Ez a három rész együtt ugyanarra a következtetésre vezet: a modern SAP-integráció nem egyszerű adatküldés, hanem tudatos rendszerhatár-tervezés.
Ebben a projektben a RAP/OData alapú megközelítés azért bizonyult jó döntésnek, mert lehetővé tette, hogy a saját fejlesztésű alkalmazás megőrizze az önálló működését, miközben kontrollált, üzletileg értelmezhető módon kapcsolódik egy SAP-rendszerhez.
A következő részben bemutatom, hogyan legyen SAP oldalról tesztelni az endpointot, ezzel meggyőzödve arról, hogy az SAP oldali szolgáltatás helyesen működik.
