Miért volt jó döntés egy saját fejlesztésű alkalmazást kapcsolni az SAP-hoz?
Egy saját fejlesztésű alkalmazásnál előbb-utóbb felmerül a kérdés: meddig maradjon a rendszer önálló, és mikor érdemes bekapcsolni egy vállalati háttérrendszert? Ez különösen érdekes akkor, ha az alkalmazás nem csupán technikai demó, hanem valamilyen üzleti folyamatot is modellez.
A projektem egy okosotthon-kezelő alkalmazásként indult. A cél egy olyan rendszer kialakítása volt, amelyben felhasználók, telepítések és később okoseszközök kezelhetők egy egységes felületen. Az alkalmazás lokálisan is működőképes: saját adattárolással, saját validációkkal és saját működési logikával rendelkezik. Ez fontos, mert egy külső alkalmazásnak nem szabad teljesen attól függenie, hogy egy másik rendszer éppen elérhető-e.
Ugyanakkor egy ponton túl már nem az volt a fő kérdés, hogy az alkalmazás képes-e adatokat menteni, hanem az, hogy ezek az adatok miként válhatnak értelmezhetővé a vállalati környezetben. Itt jött képbe az SAP.
Az SAP nem egyszerű adatbázis
Egy rossz integrációs döntés ott kezdődik, amikor az SAP-ra csak úgy tekintünk, mint egy nagy, központi adatbázisra. Ez kényelmes gondolat, de enterprise környezetben veszélyes leegyszerűsítés.
Az SAP értéke nem pusztán abban van, hogy adatokat tárol. Sokkal inkább abban, hogy üzleti objektumokat, szabályokat, jogosultságokat, ellenőrzött folyamatokat és egységes adatmodelleket biztosít. Ha egy külső alkalmazás csak “beküld valamit SAP-ba”, de nem gondolja végig a rendszerhatárokat, akkor az integráció hamar átláthatatlanná válhat.
Ezért a projektben nem az volt a cél, hogy az egész alkalmazást SAP-ba költöztessem. Az alkalmazás továbbra is megmarad saját működési egységként. Az SAP szerepe az lett, hogy a fontos üzleti adatokat kontrollált módon fogadja és reprezentálja.
Lokális működés és SAP mirror
A választott architekturális minta lényege: lokális operational store + SAP oldali üzleti mirror. Ez azt jelenti, hogy az alkalmazás saját adatbázisban kezeli azokat az adatokat, amelyek a napi működéséhez szükségesek. Ilyen például a felhasználó létrehozása, a telepítés kiválasztása vagy az alkalmazáson belüli állapotok kezelése.
Ezzel párhuzamosan bizonyos üzleti szempontból fontos adatok SAP oldalon is megjelennek. Például amikor létrejön egy felhasználó, illetve okoseszközt regisztrál, az alkalmazás képes ezt OData szolgáltatáson keresztül továbbítani az SAP-rendszer felé, illetve bármilyen üzleti szempontból releváns változás is frissül SAP-ban.
Ez nem teljes adattükrözés, és nem is vak adatmásolás. A mirror stratégia lényege, hogy csak az kerüljön át SAP-ba, aminek ott üzleti értelme van.
Ez több szempontból is jó döntés volt:
- az alkalmazás SAP nélkül is tesztelhető és használható marad;
- az SAP-integráció fokozatosan kapcsolható be;
- a hibák jobban elkülöníthetők;
- az érzékeny vagy alkalmazásspecifikus adatok nem kerülnek át feleslegesen;
- az SAP-ban mégis létrejön egy üzletileg értelmezhető adatnyom.
Ez utóbbi különösen fontos. Egy vállalati rendszerben nem az a cél, hogy minden technikai részlet mindenhol megjelenjen. Az a cél, hogy a megfelelő adat a megfelelő rendszerben, megfelelő felelősséggel legyen jelen.
Miért RAP/OData?
Az SAP oldali integrációhoz RAP/OData alapú megközelítést választottam. A külső alkalmazás nem közvetlenül SAP táblákat módosít, hanem egy publikált szolgáltatást ér el, ami architekturálisan sokkal egészségesebb. A szolgáltatás mögött SAP oldalon külön rétegek kezelik az adatmodellt, az üzleti viselkedést és a publikált API-t.
Ez a megközelítés azért előnyös, mert a külső alkalmazásnak nem kell ismernie az SAP belső technikai részleteit. Elég azt tudnia, hogy milyen endpointot hívhat, milyen adatokat kell küldenie, és milyen választ várhat vissza.
Másképp fogalmazva: az integráció nem táblaszintű kapcsolat, hanem egy interface két rendszer között.
Miért volt ez jó döntés az alkalmazás szempontjából?
Az SAP-integráció nem csak technikai bővítés volt, hanem architekturális szintlépés. Egy lokálisan működő okosotthon-alkalmazás önmagában is hasznos lehet. De ha ugyanaz az alkalmazás képes egy vállalati rendszerrel szabályozott módon kommunikálni, akkor már sokkal közelebb kerül egy valós enterprise környezethez.
A projekt így nem csak arról szól, hogy “van egy app, ami adatokat ment”. Hanem arról, hogy az alkalmazás képes különbséget tenni saját működési adatok és vállalati szempontból releváns üzleti adatok között.
Ez a különbség fejlesztőként nagyon fontos. Egy enterprise integrációnál nem az a legerősebb megoldás, amelyik minden adatot mindenhová elküld. Hanem az, amelyik pontosan meghatározza:
- melyik rendszer miért felel;
- milyen adat mehet át;
- milyen művelet engedélyezett;
- mi történik hiba esetén;
- hogyan marad biztonságos és tesztelhető a folyamat.
A projektben ezért volt jó döntés az SAP-ra kötés: nem lecserélte az alkalmazás saját működését, hanem adott mellé egy vállalati integrációs dimenziót.
Kitekintés
A jelenlegi megközelítés nem csak felhasználókra alkalmazható. Ugyanez a minta később kiterjeszthető telepítésekre, eszközökre vagy akár automatizálási eseményekre is.
Ez adja a megoldás valódi erejét: nem egyszeri integrációs trükkről van szó, hanem újrahasználható mintáról. Ha a rendszerhatárok tiszták, akkor az újabb üzleti objektumok bekötése már nem nulláról indul.
Tanulság
A modern SAP-integráció nem egyszerű adatküldés. Sokkal inkább tudatos rendszerhatár-tervezés. Egy külső alkalmazásnak nem kell minden működését SAP-ba költöztetnie ahhoz, hogy SAP-integrált legyen. Sok esetben erősebb megoldás, ha az alkalmazás lokálisan stabil marad, miközben a fontos üzleti adatok SAP oldalon is megjelennek.
Ebben a projektben a RAP/OData alapú integráció pontosan ezt tette lehetővé: az SAP nem háttér-adatbázisként, hanem üzleti szolgáltatásokat publikáló rendszerként jelent meg.
A sorozat következő részében azt mutatom be, hogyan épül fel ez SAP oldalon: hogyan lesz egy SAP táblából RAP objektumláncon keresztül külső rendszer által elréhető OData V4 endpoint.
