Andmete väljavõtt mine SAP HCM non-SAP andmehoidlatest

Nagu teada, pakub ettevõte SAP laia valikut tarkvaralahendusi nii tehingute andmete haldamiseks kui ka nende töötlemiseks analüüsi ja aruandluse süsteemides. Eriti huvitav on SAP Business Warehouse (SAP BW) platvorm, mis on andmete salvestamise ja analüüsimise tööriist, millel on laiad tehnilised võimalused. Kõikide nende objektiivsete eeliste juures on SAP BW-l üks oluline puudus. See on kõrge andmete salvestamise ja töötlemise maksumus, mis on eriti märgatav, kui kasutada pilve põhinevat SAP BW on Hana.

Aga mis siis, kui hakata kasutama mõnd non-SAP ja soovitavalt avatud lähtekoodiga toodet? Me X5 Retail Groupis valisime GreenPlumi. See lahendab muidugi kuluküsimuse, kuid samas tekivad koheselt küsimused, mis SAP BW kasutamisel lahendati praktiliselt vaikimisi.

Eriti see, kuidas andmeid allikate süsteemidest hankida, mis enamikul juhtudel on SAP lahendused?

„HR-mõõdikud“ sai esimeseks projektiks, kus tuli see probleem lahendada. Meie eesmärk oli luua HR-andmete andmehoidla ning koostada analüütiline aruandlus töötajatega seotud tegevuste valdkonnas. Peamiseks andmeallikaks oli tehingute süsteem SAP HCM, kus haldatakse kõik personaliga, organisatsiooniga ja palgaga seotud toimingud.

Andmete väljavõtt

SAP BW-s SAP süsteemide jaoks on olemas standardseid andmete väljavõtutekitore. Need väljavõtjad suudavad automaatselt koguda vajalikke andmeid, jälgida nende terviklikkust ja määrata muutuste delta. Näiteks on olemas standardne andmeallikas töötaja atribuutide jaoks 0EMPLOYEE_ATTR:

Andmete väljavõtu tulemus ühe töötaja kohta:

Vajadusel saab sellist väljavõtjat kohandada vastavalt isiklikele nõudmistele või luua omaenda väljavõtja.

Esimene mõte tekkis nende taaskasutamise võimaluse kohta. Kahjuks osutus see teoreetiliselt teostamatuks ülesandeks. Suur osa loogikast on rakendatud SAP BW poolel ning ektraktori eraldamine allikast SAP BW-st ilma probleemideta ei osutunud võimalikuks.

Selgeks sai, et on vajalik välja töötada oma andmete ekstraktsiooni mehhanism SAP süsteemidest.

Andmete salvestamise struktuur SAP HCM-is

Kuna nõuete mõistmiseks on oluline määratleda, milliseid andmeid me täpselt vajame.

Enamik andmeid SAP HCM-is hoitakse tasapinnalistes SQL-tabelites. Nende andmete põhjal visualiseerivad SAP rakendused kasutajale organisatsioonistruktuure, töötajaid ja muud HR teavet. Näiteks näeb SAP HCM välja järgmine organisatsioonistruktuur:

Füüsiliselt hoitakse seda puu struktuuri kahes tabelis — hrp1000 objektid ja hrp1001 seosed nende objektide vahel.

Objektid "Osakond 1" ja "Juhtimine 1":

Seos objektide vahel:

Nii objektide kui ka nendevaheliste seoste tüüpe võib olla tohutult palju. Eksisteerivad nii standardsed seosed objektide vahel kui ka kohandatud erivajaduste tarbeks. Näiteks osakonna ja ametikoha vahel olev standardne seos B012 näitab osakonna juhatajat.

Juhataja kuvamine SAP-is:

Salvestamine andmebaasi tabelisse:

Töötajate andmeid hoitakse tabelites pa*. Näiteks töötaja kohta käivad personaliküsimused salvestatakse tabelisse pa0000.

Otsustasime, et GreenPlum toob "toored" andmed, st kopeerib need lihtsalt SAP tabelitest. Ja juba GreenPlumis töödeldakse ja muudetakse need füüsilisteks objektideks (nt osakond või töötaja) ja mõõdikiteks (nt keskmine arv töökohti).

Määratleti, et on olemas umbes 70 tabelit, mille andmeid on vaja edastada GreenPlum-i. Seejärel jätkasime nende andmete edastamise viisi töötlemist.

SAP pakub üsna palju integratsiooni mehhanisme. Kuid kõige lihtsam viis – otse andmebaasi pääsemine on litsentsipiirangute tõttu keelatud. Seega peavad kõik integratsioonivoogud olema rakendustasandil. serverilt rakendustes.
Järgmiseks probleemiks oli kadunud kirjeandmete puudumine SAP andmebaasis. Rida andmebaasist eemaldamisel kustutatakse see füüsiliselt. See tähendab, et muudatuste delta ajas genereerimine ei olnud võimalik.

Muidugi on SAP HCM-is mehhanisme andmete muudatuste fikseerimiseks. Näiteks edasiviimiseks saajate süsteemidesse on olemas muudatussuunajad (change pointer), mis fikseerivad kõik muudatused ja mille põhjal luuakse Idoc (objekt välistele süsteemidele edastamiseks).

Näidis IDoc muudatuste infotype 0302 töötajale selle töötaja numbriga 1251445:

Või andmete muudatuste logide pidamine tabelis DBTABLOG.

Näidis logi salvestuse kustutamise kohta võtmega QK53216375 tabelist hrp1000:

Kuid need mehhanismid ei ole kergesti kätte saadavad kõigi vajalike andmete jaoks ja nende töötlemine rakenduste serveri tasemel võib tarbida päris palju ressursse. Seetõttu võib massiline logimise sisselülitamine kõigile vajalikutele tabelitele põhjustada süsteemi jõudluse märkimisväärset halvenemist.

Järgmine tõsine probleem olid klastertabelid. Aja ja palgaarvestuse hindamise andmed RDBMS versiooni SAP HCM sees on salvestatud iga töötaja jaoks igas arvutuses loogiliste tabelite komplektina. Need loogilised tabelid salvestatakse kahekordsete andmetena tabelis pcl2.

Palga arvutamise klaster:

Klastertabelitest andmeid ei saa lugeda SQL-i käsuga, vaid on vaja kasutada SAP HCM makrokäsku või spetsiaalseid funktsionaalseid mooduleid. Seega on selliste tabelite lugemise kiirus üsna madal. Teiselt poolt sisaldavad need klastrid andmeid, mida on vaja ainult kord kuus – palga lõpphindamine ja aja hindamine. Seega ei ole kiirus selles osas nii kriitiline.

Hinnates andmete muudatuste delta genereerimise variante, otsustati kaaluda ka täieliku väljundi varianti. Iga päev gigabaitide muutumatute andmete edastamine süsteemide vahel ei tundu just kõigekena. Kuid sel on ka mitmeid eeliseid – ei pea rakendama delta allika poolel ega rakendama selle delta sisestamist vastuvõtja poolel. Seega väheneb kulud ja teostamise tähtaeg ning suureneb integreerimise usaldusväärsus. Selgus, et praktiliselt kõik muudatused SAP HR-is toimuvad kolme kuu jooksul enne praegust kuupäeva. Seetõttu otsustati jääda igapäevasele täielikule andme väljundile SAP HR-st N kuu jooksul enne praegust kuupäeva ja kord kuus täielikule väljundile. Parameeter N sõltub konkreetsest tabelist
ja kõikub vahemikus 1 kuni 15.

Andmete ekstraktsiooniks on soovitatud järgmine skeem:

Väline süsteem loob päringu ja saadab selle SAP HCM-ile, kus kontrollitakse nende andmete täiuslikkust ja õigusi tabelitele ligipääsuks. Kui kontroll on edukas, käivitub SAP HCM-is programm, mis kogub vajalikud andmed ja edastab need Fuse'i integreerimislahendusele. Fuse määrab vajalikku teemat Kafka's ja edastab andmed sinna. Järgmine etapp on see, et andmed Kafka'st edastatakse Stage Area GP-sse.

Selles ahelas huvitab meid küsimus andmete väljavõtmisest SAP HCM-ist. Peatume sellel üksikasjalikumalt.

SAP HCM-FUSE koostöö skeem.

Väline süsteem määrab SAP-is viimase eduka päringu aja.
Protsess võib käivituda ajastaja või muu sündmuse kaudu, sealhulgas võib olla määratud ooteaeg andmete vastuseks SAP-ilt ja algatada uuesti päring. Seejärel koostab see delta päringu ja saadab selle SAP-ile.

Päringu andmed edastatakse body-s json formaadis.
HTTP meetod: POST.
Päringu näide:

SAP teenus kontrollib päringu täiuslikkust, vastavust SAP-i praegusele struktuurile, juurdepääsuõiguse olemasolu nõutud tabelile.

Vigade korral tagastab teenus vastuse vastava koodi ja kirjeldustega. Kui kontroll on edukas, loob see taustaprotsessi valimi koostamiseks, genereerib ja sünkroonselt tagastab unikaalse sessiooni id.

Väline süsteem registreerib vigade korral selle logisse. Eduka vastuse korral edastab see sessiooni id ja tabeli nime, mille alusel päring tehti.

Väline süsteem registreerib praeguse sessiooni avatud. Kui selle tabeli kohta on muid sessioone, suletakse need hoiatuse registreerimisega logisse.

SAP taustateenus loob kursori määratud parameetrite alusel ja andmepaketi määratud suurusega. Paketi suurus on maksimaalne arv kirjeid, mida protsess lugedes DB-st toob. Vaikimisi on see määratud 2000-ks. Kui DB valimis on rohkem kirjeid, kui kasutatakse paketi suurust, siis pärast esimese paketi edastamist koostatakse järgmine plokk vastava offset ja suurendatud paketinumbriga. Numbrid suurenevad 1 võrra ja saadetakse rangelt järjestikku.

Edasi SAP edastab paketi välistesüsteemi veebiteenusele. Sellel süsteem kontrollib sissetuleva paketi. Süsteemis peab olema registreeritud seanss, mille ID on saadud, ja see peab olema avatud olekus. Kui paketi number > 1, peab süsteemis olema registreeritud eelmise paketi (package_id-1) edukas vastuvõtt.

Küsimuse edukal kontrollimisel parsib väline süsteem andmed tabelist ja salvestab need.

Lisaks, kui paketis on lipp final ja serialiseerimine on läinud edukalt, teavitatakse integratsioonimoodulit seansi töötlemise edukast lõpetamisest ning moodul värskendab seansi staatust.

Viga kontrollimisel/parsides logitakse ja selle seansi paketid väline süsteem tagasi lükkab.

Sarnaselt, kui väline süsteem tagastab vea, logitakse see ja pakettide edastamine peatatakse.

SAP HCM-i andmete pärimise jaoks on rakendatud integratsiooniteenus. Teenus on loodud ICF (SAP Internet Communication Framework) raamistiku baasil - help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html). See võimaldab teha päringuid SAP HCM süsteemi teatud tabelitesse. Andmepäringu koostamisel on võimalik määrata konkreetsed väljad ja filtreerimisparameetrid vajalike andmete saamiseks. Teenuse rakendamine ei eelda mingit äri logikat. Deltana, päringupäringu parameetrite kontrollimise algoritmid jne rakendatakse samuti välistesüsteemis.

See mehhanism võimaldab koguda ja edastada kõik vajalikud andmed mõne tunni jooksul. See kiirus on piiri peal vastuvõetav, seetõttu käsitleme seda lahendust ajutisena, mis suudab rahuldada projekti andmeekstraktsiooni vajadust.
Tuleviku strateegia andmete ekstraktsiooni lahendamiseks uuritakse CDC süsteemide, nagu Oracle Golden Gate, või ETL tööriistade, nagu SAP DS, kasutamise variante.

Allikas: habr.com