Nagu teate, pakub SAP täielikku tarkvaravalikut nii tehinguandmete säilitamiseks kui ka nende andmete töötlemiseks analüüsi- ja aruandlussüsteemides. Eelkõige on SAP Business Warehouse (SAP BW) platvorm ulatuslike tehniliste võimalustega tööriistakomplekt andmete salvestamiseks ja analüüsimiseks. Kõigi oma objektiivsete eeliste juures on SAP BW süsteemil üks oluline puudus. See on andmete salvestamise ja töötlemise kõrge hind, mis on eriti märgatav pilvepõhise SAP BW kasutamisel Hanas.
Mis siis, kui hakkate salvestusruumina kasutama mõnda mitte-SAP-i ja eelistatavalt avatud lähtekoodiga toodet? Meie, X5 Retail Group, valisime GreenPlumi. See muidugi lahendab kulude küsimuse, kuid samal ajal tekivad kohe probleemid, mis SAP BW kasutamisel peaaegu vaikimisi lahenesid.
Täpsemalt, kuidas hankida andmeid lähtesüsteemidest, mis on enamasti SAP-lahendused?
HR Metrics oli esimene projekt, mille käigus oli vaja see probleem lahendada. Meie eesmärk oli luua personaliandmete hoidla ja analüütiline aruandlus töötajatega töötamise valdkonnas. Sel juhul on peamiseks andmeallikaks SAP HCM tehingusüsteem, milles viiakse läbi kõik personali-, organisatsiooni- ja palgategevused.
Andmete eraldamine
SAP BW-s on SAP-süsteemide jaoks standardsed andmeekstraktorid. Need ekstraktorid saavad automaatselt koguda vajalikke andmeid, jälgida nende terviklikkust ja määrata muutuste deltaid. Siin on näiteks standardne andmeallikas töötaja atribuutide 0EMPLOYEE_ATTR jaoks:
Ühe töötaja kohta andmete väljavõtmise tulemus:
Vajadusel saab sellist ekstraktorit kohandada vastavalt teie vajadustele või luua oma ekstraktori.
Esimene idee, mis tekkis, oli võimalus neid taaskasutada. Kahjuks osutus see võimatuks ülesandeks. Suurem osa loogikast on realiseeritud SAP BW poolel ning allikas olevat ekstraktorit SAP BW-st valutult eraldada ei õnnestunud.
Sai selgeks, et peame välja töötama oma mehhanismi andmete hankimiseks SAP-süsteemidest.
Andmete salvestamise struktuur SAP HCM-is
Sellise mehhanismi nõuete mõistmiseks peame kõigepealt kindlaks määrama, milliseid andmeid me vajame.
Enamik SAP HCM-i andmeid salvestatakse lamedates SQL-tabelites. Nende andmete põhjal visualiseerivad SAP rakendused kasutajale organisatsioonilisi struktuure, töötajaid ja muud personaliteavet. Näiteks SAP HCM-i organisatsiooniline struktuur näeb välja selline:
Füüsiliselt on selline puu talletatud kahes tabelis - hrp1000 objektides ja hrp1001 nende objektide vahelised ühendused.
Objektid “Osakond 1” ja “Büroo 1”:
Objektide vaheline seos:
Mõlemat tüüpi objekte ja nendevahelisi seoseid võib olla tohutult palju. Objektide vahel on nii standardseid ühendusi kui ka kohandatud ühendusi vastavalt teie vajadustele. Näiteks standardne B012 suhe organisatsiooniüksuse ja täiskohaga ametikoha vahel näitab osakonnajuhatajat.
Halduri kuva SAP-is:
Salvestus andmebaasi tabelis:
Töötajate andmed salvestatakse pa* tabelites. Näiteks andmed töötaja personalisündmuste kohta salvestatakse tabelisse pa0000
Otsustasime, et GreenPlum võtab “toored” andmed, st. lihtsalt kopeerige need SAP-i tabelitest. Ja otse GreenPlumis töödeldakse neid ja teisendatakse füüsilisteks objektideks (näiteks osakond või töötaja) ja mõõdikuteks (näiteks keskmine töötajate arv).
Määratleti umbes 70 tabelit, mille andmed tuleb GreenPlumi üle kanda. Pärast seda hakkasime välja töötama meetodit nende andmete edastamiseks.
SAP pakub üsna suurt hulka integratsioonimehhanisme. Kuid kõige lihtsam on see, et otsejuurdepääs andmebaasile on litsentsipiirangute tõttu keelatud. Seega tuleb kõik integratsioonivood realiseerida rakendusserveri tasemel.
Järgmiseks probleemiks oli andmete puudumine kustutatud kirjete kohta SAP andmebaasis. Kui kustutate andmebaasist rea, kustutatakse see füüsiliselt. Need. muutuste delta moodustamine muutumise aja järgi ei olnud võimalik.
Loomulikult on SAP HCM-il mehhanismid andmete muudatuste salvestamiseks. Näiteks hilisemaks vastuvõtvatesse süsteemidesse ülekandmiseks on muudatusnäidikud, mis salvestavad kõik muudatused ja mille alusel moodustatakse Idoc (välistesse süsteemidesse ülekandmise objekt).
Näidis IDoc infotüübi 0302 muutmiseks töötaja personalinumbriga 1251445 jaoks:
Või andmete muudatuste logide pidamine tabelis DBTABLOG.
Näide logist võtmega QK53216375 kirje kustutamiseks tabelist hrp1000:
Kuid need mehhanismid pole kõigi vajalike andmete jaoks saadaval ja nende töötlemine rakendusserveri tasemel võib kulutada üsna palju ressursse. Seetõttu võib kõigi vajalike tabelite sisselogimise massiline lubamine kaasa tuua süsteemi jõudluse märgatava halvenemise.
Järgmine suurem probleem oli rühmitabelid. Ajahinnangu ja palgaarvestuse andmed SAP HCM-i RDBMS-i versioonis salvestatakse iga arvutuse jaoks iga töötaja jaoks loogiliste tabelite komplektina. Need loogilised tabelid salvestatakse binaarandmetena tabelis pcl2.
Palgaarvestusklaster:
Kobartabelite andmeid ei saa pidada SQL-käsuks, vaid selleks on vaja kasutada SAP HCM makrosid või spetsiaalseid funktsionaalseid mooduleid. Sellest tulenevalt on selliste tabelite lugemiskiirus üsna madal. Teisalt salvestavad sellised klastrid andmeid, mida läheb vaja vaid kord kuus – lõplik palgaarvestus ja ajahinnang. Nii et kiirus pole antud juhul nii kriitiline.
Andmemuudatuste delta moodustamise võimalusi hinnates otsustasime kaaluda ka täieliku mahalaadimise võimalust. Võimalus gigabaite muutmata andmeid iga päev süsteemide vahel üle kanda ei pruugi hea välja näha. Kuid sellel on ka mitmeid eeliseid - pole vaja rakendada nii allika poolel deltat kui ka selle delta manustamist vastuvõtja poolel. Sellest tulenevalt vähenevad kulud ja rakendamise aeg ning suureneb integratsiooni usaldusväärsus. Samal ajal tehti kindlaks, et peaaegu kõik muudatused SAP HR-is toimuvad kolme kuu jooksul enne praegust kuupäeva. Seetõttu otsustati SAP HR-i andmete igapäevane täielik allalaadimine N kuud enne praegust kuupäeva ja igakuine täielik allalaadimine. N-parameeter sõltub konkreetsest tabelist
ja jääb vahemikku 1 kuni 15.
Andmete ekstraheerimiseks pakuti välja järgmine skeem:
Väline süsteem genereerib päringu ja saadab selle SAP HCM-ile, kus kontrollitakse selle päringu andmete täielikkust ja juurdepääsuõigusi tabelitele. Kui kontroll õnnestub, käivitab SAP HCM programmi, mis kogub vajalikud andmed ja edastab need Fuse integratsioonilahendusse. Fuse määrab Kafkas vajaliku teema ja edastab andmed sinna. Järgmisena edastatakse Kafka andmed Stage Area GP-le.
Selles ahelas oleme huvitatud SAP HCM-ist andmete hankimise probleemist. Vaatame seda üksikasjalikumalt.
SAP HCM-FUSE interaktsiooni diagramm.
Väline süsteem määrab SAP-ile viimase eduka päringu aja.
Protsessi saab käivitada taimer või muu sündmus, sealhulgas ajalõpu seadistamine SAP-i andmetega vastuse ootamiseks ja korduspäringu algatamiseks. Seejärel genereerib see deltapäringu ja saadab selle SAP-ile.
Päringu andmed saadetakse kehasse json-vormingus.
Meetod http: POST.
Taotluse näidis:
SAP-teenus jälgib taotluse täielikkust, vastavust praegusele SAP-struktuurile ja taotletud tabelile juurdepääsuloa saadavust.
Vigade korral tagastab teenus vastava koodi ja kirjeldusega vastuse. Kui juhtimine õnnestub, loob see näidise genereerimiseks taustprotsessi, genereerib ja tagastab sünkroonselt kordumatu seansi ID.
Vea korral salvestab väline süsteem selle logisse. Eduka vastuse korral edastab see seansi ID ja tabeli nime, mille kohta päring tehti.
Väline süsteem registreerib praeguse seansi avatuks. Kui selle tabeli jaoks on muid seansse, suletakse need koos hoiatusega.
SAP taustatöö genereerib kursori määratud parameetrite ja määratud suurusega andmepaketi põhjal. Partii suurus on maksimaalne kirjete arv, mida protsess andmebaasist loeb. Vaikimisi eeldatakse, et see on võrdne 2000. Kui andmebaasi näidis on rohkem kirjeid kui kasutatud paketi suurus, moodustatakse pärast esimese paketi edastamist järgmine plokk vastava nihke ja suurendatud paketinumbriga. Numbreid suurendatakse 1 võrra ja saadetakse rangelt järjest.
Järgmisena edastab SAP paketi sisendiks välissüsteemi veebiteenusele. Ja süsteem kontrollib sissetulevat paketti. Saadud ID-ga seanss peab olema süsteemis registreeritud ja see peab olema avatud olekus. Kui paki number > 1, peaks süsteem fikseerima eelmise paki eduka kättesaamise (paki_id-1).
Kui juhtimine õnnestub, parsib ja salvestab väline süsteem tabeliandmed.
Lisaks, kui viimane lipp on paketis olemas ja serialiseerimine õnnestus, teavitatakse integratsioonimoodulit seansi töötlemise edukast lõpuleviimisest ja moodul värskendab seansi olekut.
Juhtimise/parsimise vea korral tõrge logitakse ja väline süsteem lükkab selle seansi paketid tagasi.
Samamoodi, vastupidisel juhul, kui väline süsteem tagastab vea, logitakse see ja pakettide edastamine peatub.
SAP HСM-i poole andmete küsimiseks rakendati integratsiooniteenust. Teenus on rakendatud ICF raamistikul (SAP Internet Communication Framework - ). See võimaldab teil konkreetsete tabelite abil SAP HCM-süsteemist andmeid pärida. Andmepäringu koostamisel on võimalik vajalike andmete saamiseks määrata konkreetsete väljade loend ja filtreerimisparameetrid. Samas ei eelda teenuse juurutamine mingit äriloogikat. Välissüsteemi poolel on realiseeritud ka delta, päringuparameetrite, terviklikkuse jälgimise jms arvutamise algoritmid.
See mehhanism võimaldab teil koguda ja edastada kõik vajalikud andmed mõne tunni jooksul. See kiirus on vastuvõetava piiril, seega peame seda lahendust ajutiseks, mis võimaldas täita projekti ekstraheerimistööriista vajaduse.
Sihtpildil uuritakse andmete ekstraheerimise probleemi lahendamiseks võimalusi kasutada CDC süsteeme nagu Oracle Golden Gate või ETL tööriistu, nagu SAP DS.
Allikas: www.habr.com