Mint ismeretes, az SAP a szoftverek teljes skáláját kínálja mind a tranzakciós adatok karbantartásához, mind az adatok feldolgozásához az elemző és jelentési rendszerekben. Az SAP Business Warehouse (SAP BW) platform az adatok tárolására és elemzésére szolgáló eszközkészlet, amely kiterjedt műszaki lehetőségekkel rendelkezik. Minden objektív előnye mellett az SAP BW rendszernek van egy jelentős hátránya. Ez az adatok tárolásának és feldolgozásának magas költsége, különösen akkor figyelhető meg, ha felhőalapú SAP BW-t használ a Hanán.
Mi van akkor, ha valamilyen nem SAP-t, lehetőleg nyílt forráskódú terméket kezdesz használni tárhelyként? Mi az X5 Retail Groupnál a GreenPlumot választottuk. Ez természetesen megoldja a költségek kérdését, ugyanakkor azonnal felmerülnek olyan problémák, amelyek az SAP BW használatakor szinte alapértelmezés szerint megoldódtak.
Konkrétan hogyan lehet adatokat lekérni a forrásrendszerekből, amelyek többnyire SAP-megoldások?
A HR Metrics volt az első olyan projekt, amelyben ezt a problémát kellett megoldani. Célunk az volt, hogy a HR-adatok tárházát hozzuk létre, és analitikus jelentéseket készítsünk az alkalmazottakkal való együttműködés területén. Ebben az esetben a fő adatforrás az SAP HCM tranzakciós rendszer, amelyben minden személyi, szervezési és bérezési tevékenység folyik.
Adatkinyerés
Az SAP BW-ben szabványos adatkivonatolók vannak az SAP rendszerek számára. Ezek az extraktorok automatikusan összegyűjthetik a szükséges adatokat, ellenőrizhetik azok integritását, és meghatározhatják a változási deltákat. Itt van például a 0EMPLOYEE_ATTR alkalmazotti attribútumok szabványos adatforrása:
Az adatok kinyerésének eredménye egy alkalmazott esetében:
Ha szükséges, egy ilyen kivonó módosítható a saját igényei szerint, vagy saját elszívó is létrehozható.
Az első ötlet az újrafelhasználás lehetősége volt. Sajnos ez lehetetlen feladatnak bizonyult. A logika nagy része SAP BW oldalon van megvalósítva, és nem lehetett fájdalommentesen leválasztani a forrásnál az extraktort az SAP BW-től.
Nyilvánvalóvá vált, hogy ki kell fejlesztenünk saját mechanizmusunkat az adatok SAP rendszerekből való kinyerésére.
Adattárolási struktúra az SAP HCM-ben
Ahhoz, hogy megértsük egy ilyen mechanizmus követelményeit, először meg kell határoznunk, hogy milyen adatokra van szükségünk.
Az SAP HCM legtöbb adata lapos SQL-táblákban van tárolva. Ezen adatok alapján az SAP alkalmazások szervezeti struktúrákat, alkalmazottakat és egyéb HR-információkat jelenítenek meg a felhasználó számára. Például így néz ki a szervezeti struktúra az SAP HCM-ben:
Fizikailag egy ilyen fa két táblában van tárolva - a hrp1000 objektumokban és a hrp1001-ben az objektumok közötti kapcsolatokban.
„1. osztály” és „1. iroda” objektumok:
Az objektumok közötti kapcsolat:
Mindkét típusú objektum és a köztük lévő kapcsolattípusok nagy száma lehet. Léteznek szabványos kapcsolatok az objektumok között, és az Ön egyedi igényei szerint testreszabott kapcsolatok is. Például a szervezeti egység és a teljes munkaidős állás közötti szabványos B012 kapcsolat egy osztályvezetőt jelöl.
Menedzser megjelenítése az SAP-ban:
Tárolás adatbázistáblában:
Az alkalmazottak adatait pa* táblák tárolják. Például egy alkalmazott személyi eseményeinek adatait a pa0000 tábla tárolja
Úgy döntöttünk, hogy a GreenPlum „nyers” adatokat vesz fel, pl. csak másolja ki őket az SAP táblákból. Közvetlenül a GreenPlumban pedig feldolgozzák és fizikai objektumokká (például osztály vagy alkalmazott) és mérőszámokká (például átlagos létszám) alakítják át.
Körülbelül 70 tábla került meghatározásra, amelyek adatait át kell vinni a GreenPlumba. Ezt követően elkezdtük kidolgozni az adatok továbbításának módszerét.
Az SAP meglehetősen nagy számú integrációs mechanizmust kínál. De a legegyszerűbb módja az, hogy az adatbázishoz való közvetlen hozzáférést tiltják az engedélyezési korlátozások miatt. Így minden integrációs folyamatot az alkalmazáskiszolgáló szintjén kell megvalósítani.
A következő probléma a törölt rekordokra vonatkozó adatok hiánya volt az SAP adatbázisban. Ha töröl egy sort az adatbázisból, az fizikailag is törlődik. Azok. változási delta kialakítása a változás időpontja alapján nem volt lehetséges.
Természetesen az SAP HCM rendelkezik az adatváltozások rögzítésére szolgáló mechanizmusokkal. Például a fogadó rendszerekre történő utólagos átvitelhez vannak változtatási mutatók, amelyek rögzítik az esetleges változásokat, és amelyek alapján egy Idoc (külső rendszerekre történő átviteli objektum) jön létre.
Példa IDoc-ra a 0302-es infótípus megváltoztatására egy 1251445-ös személyi számmal rendelkező alkalmazott esetében:
Vagy az adatváltozások naplóinak vezetése a DBTABLOG táblában.
Példa egy naplóra a QK53216375 kulcsú rekord törlésére a hrp1000 táblából:
De ezek a mechanizmusok nem állnak rendelkezésre minden szükséges adathoz, és alkalmazásszerver szintű feldolgozásuk meglehetősen sok erőforrást emészt fel. Ezért az összes szükséges tábla naplózásának nagymértékű engedélyezése a rendszer teljesítményének észrevehető romlásához vezethet.
A következő nagy probléma a fürtözött táblák volt. Az SAP HCM RDBMS-verziójában az időbecslés és a bérszámfejtési adatok logikai táblák készleteként kerülnek tárolásra minden alkalmazott számára minden számításhoz. Ezek a logikai táblák bináris adatként vannak tárolva a pcl2 táblában.
Bérszámfejtő klaszter:
A fürtözött táblákból származó adatok nem tekinthetők SQL-parancsnak, hanem SAP HCM makrók vagy speciális funkcionális modulok használatát igénylik. Ennek megfelelően az ilyen táblázatok olvasási sebessége meglehetősen alacsony lesz. Másrészt az ilyen klaszterek olyan adatokat tárolnak, amelyekre havonta csak egyszer van szükség - végső bérszámfejtés és időbecslés. Tehát a sebesség ebben az esetben nem olyan kritikus.
Az adatváltozások delta kialakításának lehetőségeit értékelve úgy döntöttünk, hogy mérlegeljük a teljes kirakodás lehetőségét is. Nem biztos, hogy jól néz ki az a lehetőség, hogy naponta gigabájtnyi változatlan adatot továbbítanak a rendszerek között. Ennek azonban számos előnye is van - nincs szükség a deltának a forrás oldalon való megvalósítására és a delta beágyazására a vevő oldalon. Ennek megfelelően csökken a költség és a megvalósítási idő, és nő az integráció megbízhatósága. Ugyanakkor megállapították, hogy az SAP HR szinte minden változása az aktuális dátum előtti három hónapon belül történik. Így az a döntés született, hogy az SAP HR-től az aktuális dátum előtt N hónappal történő napi teljes adatletöltést és havi teljes letöltést választanak. Az N paraméter az adott táblázattól függ
és 1-től 15-ig terjed.
Az adatkinyerésre a következő sémát javasolták:
A külső rendszer létrehoz egy kérést, és elküldi azt az SAP HCM-nek, ahol a kérés ellenőrzi az adatok teljességét és a táblákhoz való hozzáférési engedélyeket. Ha az ellenőrzés sikeres, az SAP HCM futtat egy programot, amely összegyűjti a szükséges adatokat, és továbbítja azokat a Fuse integrációs megoldásnak. A Fuse meghatározza a szükséges témát a Kafkában, és oda továbbítja az adatokat. Ezután a Kafkától származó adatok átkerülnek a Stage Area GP-be.
Ebben a láncban az SAP HCM-ből származó adatok kinyerésének kérdése érdekel bennünket. Nézzük meg részletesebben.
SAP HCM-FUSE interakciós diagram.
A külső rendszer határozza meg az utolsó sikeres SAP kérés idejét.
A folyamat elindítható egy időzítővel vagy más eseménnyel, beleértve az időtúllépés beállítását az SAP-tól származó adatokkal való válaszvárakozáshoz, és ismételt kérés kezdeményezéséhez. Ezután delta kérést generál, és elküldi az SAP-nak.
A kérési adatok json formátumban kerülnek elküldésre a törzsnek.
Módszer http: POST.
Példa kérés:
Az SAP szolgáltatás figyeli a kérést a teljességre, az aktuális SAP-struktúrának való megfelelésre, valamint a kért táblához való hozzáférési engedélyek elérhetőségére.
Hiba esetén a szolgáltatás a megfelelő kóddal és leírással válaszol. Ha a vezérlés sikeres, létrehoz egy háttérfolyamatot a minta generálásához, generál és szinkronosan visszaad egy egyedi munkamenet-azonosítót.
Hiba esetén a külső rendszer rögzíti a naplóban. Sikeres válasz esetén továbbítja a munkamenet azonosítóját és annak a táblának a nevét, amelyre a kérés történt.
A külső rendszer az aktuális munkamenetet nyitottként regisztrálja. Ha más munkamenetek is vannak ehhez a táblához, akkor azokat egy figyelmeztetéssel zárják le.
Az SAP háttérfeladat a megadott paraméterek és a megadott méretű adatcsomag alapján állít elő egy kurzort. A kötegméret a rekordok maximális száma, amelyet egy folyamat beolvas az adatbázisból. Alapértelmezés szerint ez egyenlő 2000-rel. Ha az adatbázismintában több rekord van, mint a használt csomagméret, az első csomag továbbítása után a következő blokk jön létre a megfelelő eltolási és növekményes csomagszámmal. A számok 1-gyel nőnek, és szigorúan egymás után küldik el.
Ezután az SAP bemenetként továbbítja a csomagot a külső rendszer webszolgáltatásának. A rendszer pedig ellenőrzéseket hajt végre a bejövő csomagon. A kapott azonosítóval rendelkező munkamenetet regisztrálni kell a rendszerben, és nyitott állapotban kell lennie. Ha a csomag száma > 1, akkor a rendszernek rögzítenie kell az előző csomag sikeres átvételét (csomagazonosító-1).
Ha a vezérlés sikeres, a külső rendszer elemzi és elmenti a táblázat adatait.
Ezenkívül, ha a végső jelző szerepel a csomagban, és a sorozatosítás sikeres volt, az integrációs modul értesítést kap a munkamenet-feldolgozás sikeres befejezéséről, és a modul frissíti a munkamenet állapotát.
Vezérlési/elemzési hiba esetén a hiba naplózásra kerül, és az ehhez a munkamenethez tartozó csomagokat a külső rendszer elutasítja.
Hasonlóképpen, ellenkező esetben, amikor a külső rendszer hibát ad vissza, naplózásra kerül, és a csomagátvitel leáll.
Az SAP HСM oldalon történő adatkéréshez egy integrációs szolgáltatást valósítottak meg. A szolgáltatás az ICF keretrendszeren (SAP Internet Communication Framework - ). Lehetővé teszi az adatok lekérdezését az SAP HCM rendszerből meghatározott táblák segítségével. Az adatigénylés létrehozásakor lehetőség van konkrét mezők és szűrési paraméterek listájának megadására a szükséges adatok beszerzése érdekében. Ugyanakkor a szolgáltatás megvalósítása nem tartalmaz üzleti logikát. A delta, lekérdezési paraméterek, integritásfigyelés stb. kiszámítására szolgáló algoritmusok is implementálva vannak a külső rendszer oldalán.
Ez a mechanizmus lehetővé teszi az összes szükséges adat összegyűjtését és továbbítását néhány óra alatt. Ez a sebesség az elfogadható határán van, ezért ezt a megoldást átmenetinek tekintjük, ami lehetővé tette, hogy a projekten egy extrakciós eszköz iránti igényt kielégítsék.
A célképben az adatkinyerés problémájának megoldására olyan CDC-rendszerek, mint az Oracle Golden Gate vagy az ETL-eszközök, mint az SAP DS, használatának lehetőségeit vizsgálják.
Forrás: will.com