Kaip žinote, SAP siūlo visą programinės įrangos asortimentą tiek operacijų duomenims palaikyti, tiek šiems duomenims apdoroti analizės ir ataskaitų teikimo sistemose. Visų pirma, SAP Business Warehouse (SAP BW) platforma yra duomenų saugojimo ir analizės įrankių rinkinys, turintis daug techninių galimybių. Nepaisant visų objektyvių privalumų, SAP BW sistema turi vieną reikšmingą trūkumą. Tai didelės duomenų saugojimo ir apdorojimo išlaidos, ypač pastebimos naudojant debesyje pagrįstą SAP BW „Hana“.
Ką daryti, jei kaip saugyklą pradėsite naudoti ne SAP ir, pageidautina, atvirojo kodo produktą? Mes, X5 Retail Group, pasirinkome GreenPlum. Tai, žinoma, išsprendžia išlaidų klausimą, tačiau tuo pačiu metu iš karto kyla problemų, kurios buvo išspręstos beveik pagal nutylėjimą naudojant SAP BW.
Visų pirma, kaip gauti duomenis iš šaltinio sistemų, kurios dažniausiai yra SAP sprendimai?
HR Metrics buvo pirmasis projektas, kuriame reikėjo išspręsti šią problemą. Mūsų tikslas buvo sukurti HR duomenų saugyklą ir sukurti analitines ataskaitas darbo su darbuotojais srityje. Šiuo atveju pagrindinis duomenų šaltinis yra SAP HCM transakcinė sistema, kurioje vykdoma visa personalo, organizacinė ir atlyginimo veikla.
Duomenų ištraukimas
SAP BW yra standartiniai SAP sistemų duomenų ištraukikliai. Šie ištraukikliai gali automatiškai rinkti reikiamus duomenis, stebėti jų vientisumą ir nustatyti pokyčių deltas. Pavyzdžiui, čia yra standartinis darbuotojų atributų 0EMPLOYEE_ATTR duomenų šaltinis:
Duomenų ištraukimo iš jo rezultatas vienam darbuotojui:
Jei reikia, tokį ištraukiklį galima modifikuoti pagal jūsų poreikius arba sukurti savo ištraukiklį.
Pirmoji kilusi idėja buvo galimybė juos panaudoti pakartotinai. Deja, tai pasirodė neįmanoma užduotis. Didžioji dalis logikos įdiegta SAP BW pusėje ir nebuvo įmanoma neskausmingai atskirti ištraukiklį šaltinyje nuo SAP BW.
Tapo akivaizdu, kad turėsime sukurti savo duomenų išgavimo iš SAP sistemų mechanizmą.
Duomenų saugojimo struktūra SAP HCM
Norėdami suprasti tokio mechanizmo reikalavimus, pirmiausia turime nustatyti, kokių duomenų mums reikia.
Dauguma SAP HCM duomenų saugomi plokščiose SQL lentelėse. Remiantis šiais duomenimis, SAP programos vartotojui vizualizuoja organizacines struktūras, darbuotojus ir kitą personalo informaciją. Pavyzdžiui, štai kaip atrodo SAP HCM organizacinė struktūra:
Fiziškai toks medis saugomas dviejose lentelėse – hrp1000 objektuose ir hrp1001 jungtys tarp šių objektų.
Objektai „1 skyrius“ ir „1 biuras“:
Ryšys tarp objektų:
Abiejų tipų objektų ir ryšių tarp jų tipų gali būti labai daug. Yra ir standartinių jungčių tarp objektų, ir pritaikytų jūsų konkretiems poreikiams. Pavyzdžiui, standartinis B012 ryšys tarp organizacinio padalinio ir etato nurodo skyriaus vadovą.
Valdytojo ekranas SAP:
Saugykla duomenų bazės lentelėje:
Darbuotojų duomenys saugomi pa* lentelėse. Pavyzdžiui, duomenys apie personalo įvykius darbuotojui yra saugomi lentelėje pa0000
Nusprendėme, kad GreenPlum ims „neapdorotus“ duomenis, t.y. tiesiog nukopijuokite juos iš SAP lentelių. Ir tiesiogiai GreenPlum jie bus apdorojami ir konvertuojami į fizinius objektus (pavyzdžiui, skyrių ar darbuotoją) ir metriką (pavyzdžiui, vidutinį darbuotojų skaičių).
Buvo apibrėžta apie 70 lentelių, iš kurių duomenis reikia perkelti į GreenPlum. Po to pradėjome kurti šių duomenų perdavimo būdą.
SAP siūlo gana daug integravimo mechanizmų. Tačiau paprasčiausias būdas yra tiesioginė prieiga prie duomenų bazės dėl licencijavimo apribojimų. Taigi visi integravimo srautai turi būti įgyvendinti programų serverio lygiu.
Kita problema buvo duomenų apie ištrintus įrašus trūkumas SAP duomenų bazėje. Kai ištrinate duomenų bazės eilutę, ji fiziškai ištrinama. Tie. kaitos deltos susidarymas pagal kaitos laiką nebuvo įmanomas.
Žinoma, SAP HCM turi duomenų pasikeitimų registravimo mechanizmus. Pavyzdžiui, vėlesniam perkėlimui į gavėjų sistemas yra pakeitimų rodyklės, kurios fiksuoja bet kokius pakeitimus ir kurių pagrindu formuojamas Idoc (objektas, skirtas perkelti į išorines sistemas).
0302 informacijos tipo keitimo IDoc pavyzdys darbuotojui, kurio personalo numeris 1251445:
Arba saugoti duomenų pasikeitimų žurnalus DBTABLOG lentelėje.
Žurnalo, skirto įrašui ištrinti su raktu QK53216375 iš hrp1000 lentelės, pavyzdys:
Tačiau šie mechanizmai nėra prieinami visiems reikiamiems duomenims, o jų apdorojimas programų serverio lygiu gali sunaudoti daug išteklių. Todėl masiškai įjungus registraciją visose būtinose lentelėse gali pastebimai pablogėti sistemos veikimas.
Kita didelė problema buvo sugrupuotos lentelės. Laiko apskaičiavimo ir darbo užmokesčio duomenys SAP HCM RDBMS versijoje saugomi kaip loginių lentelių rinkinys kiekvienam darbuotojui kiekvienam skaičiavimui. Šios loginės lentelės yra saugomos kaip dvejetainiai duomenys lentelėje pcl2.
Darbo užmokesčio skaičiavimo klasteris:
Duomenys iš sugrupuotų lentelių negali būti laikomi SQL komanda, bet reikia naudoti SAP HCM makrokomandas arba specialius funkcijų modulius. Atitinkamai, tokių lentelių skaitymo greitis bus gana mažas. Kita vertus, tokiuose klasteriuose saugomi tik kartą per mėnesį reikalingi duomenys – galutinis darbo užmokesčio ir laiko įvertinimas. Taigi greitis šiuo atveju nėra toks kritinis.
Įvertinę duomenų pokyčių delta formavimo galimybes, nusprendėme apsvarstyti ir pilno iškrovimo variantą. Galimybė kiekvieną dieną perkelti gigabaitus nepakitusių duomenų iš vienos sistemos į kitą gali atrodyti neblogai. Tačiau ji turi ir nemažai privalumų – nereikia tiek diegti delta šaltinio pusėje, tiek diegti šios delta imtuvo pusėje. Atitinkamai sumažėja sąnaudos ir įgyvendinimo laikas, padidėja integracijos patikimumas. Kartu buvo nustatyta, kad beveik visi SAP HR pokyčiai įvyksta per tris mėnesius iki dabartinės datos. Taigi buvo nuspręsta pasirinkti kasdienį pilną duomenų atsisiuntimą iš SAP HR likus N mėnesiams iki dabartinės datos ir kas mėnesį. N parametras priklauso nuo konkrečios lentelės
ir svyruoja nuo 1 iki 15.
Duomenims išgauti buvo pasiūlyta tokia schema:
Išorinė sistema sugeneruoja užklausą ir siunčia ją į SAP HCM, kur ši užklausa patikrinama, ar yra duomenų išsamumas ir prieigos prie lentelių leidimai. Jei patikrinimas sėkmingas, SAP HCM paleidžia programą, kuri surenka reikiamus duomenis ir perduoda juos į Fuse integravimo sprendimą. Fuse nustato reikiamą temą Kafkoje ir perkelia duomenis ten. Toliau duomenys iš Kafkos perduodami Stage Area GP.
Šioje grandinėje mus domina duomenų išgavimo iš SAP HCM problema. Pažvelkime į tai išsamiau.
SAP HCM-FUSE sąveikos diagrama.
Išorinė sistema nustato paskutinės sėkmingos užklausos į SAP laiką.
Procesas gali būti pradėtas naudojant laikmatį ar kitą įvykį, įskaitant skirtojo laiko nustatymą laukti atsakymo su duomenimis iš SAP ir inicijuoti pakartotinę užklausą. Tada jis sugeneruoja delta užklausą ir siunčia ją SAP.
Užklausos duomenys siunčiami korpusui json formatu.
Metodas http: POST.
Prašymo pavyzdys:
SAP paslauga stebi užklausos išsamumą, atitiktį dabartinei SAP struktūrai ir prieigos prie prašomos lentelės leidimo prieinamumą.
Klaidų atveju paslauga grąžina atsakymą su atitinkamu kodu ir aprašymu. Jei valdymas sėkmingas, jis sukuria foninį procesą pavyzdžiui generuoti, sugeneruoja ir sinchroniškai grąžina unikalų seanso ID.
Klaidos atveju išorinė sistema ją įrašo į žurnalą. Sėkmingo atsakymo atveju jis perduoda seanso ID ir lentelės, dėl kurios buvo pateikta užklausa, pavadinimą.
Išorinė sistema užregistruoja dabartinę sesiją kaip atidarytą. Jei yra kitų šios lentelės seansų, jie uždaromi ir įrašomas įspėjimas.
SAP fono užduotis generuoja žymeklį pagal nurodytus parametrus ir nurodyto dydžio duomenų paketą. Partijos dydis yra didžiausias įrašų, kuriuos procesas nuskaito iš duomenų bazės, skaičius. Pagal numatytuosius nustatymus manoma, kad ji yra lygi 2000. Jei duomenų bazės pavyzdyje yra daugiau įrašų nei naudojamas paketo dydis, po pirmojo paketo perdavimo formuojamas kitas blokas su atitinkamu poslinkiu ir padidintu paketo numeriu. Skaičiai didinami 1 ir siunčiami griežtai iš eilės.
Tada SAP perduoda paketą kaip įvestį išorinės sistemos žiniatinklio tarnybai. Ir sistema atlieka gaunamo paketo kontrolę. Seansas su gautu ID turi būti užregistruotas sistemoje ir turi būti atidarytas. Jei pakuotės numeris > 1, sistema turėtų užfiksuoti sėkmingą ankstesnės siuntos gavimą (package_id-1).
Jei valdymas sėkmingas, išorinė sistema analizuoja ir išsaugo lentelės duomenis.
Be to, jei pakete yra paskutinė vėliavėlė ir serializavimas buvo sėkmingas, integravimo moduliui pranešama apie sėkmingą seanso apdorojimo užbaigimą, o modulis atnaujina seanso būseną.
Įvykus valdymo / analizavimo klaidai, klaida registruojama ir išorinė sistema atmeta šios sesijos paketus.
Taip pat ir priešingu atveju, kai išorinė sistema grąžina klaidą, ji registruojama ir paketų siuntimas sustabdomas.
Norėdami paprašyti duomenų SAP HСM pusėje, buvo įdiegta integravimo paslauga. Paslauga įdiegta naudojant ICF sistemą (SAP Internet Communication Framework - ). Tai leidžia užklausti duomenis iš SAP HCM sistemos naudojant konkrečias lenteles. Kuriant duomenų užklausą galima nurodyti konkrečių laukų sąrašą ir filtravimo parametrus, kad būtų gauti reikiami duomenys. Tuo pačiu metu paslaugos įgyvendinimas nereiškia jokios verslo logikos. Išorinės sistemos pusėje taip pat įdiegti delta skaičiavimo, užklausos parametrų, vientisumo stebėjimo ir kt. algoritmai.
Šis mechanizmas leidžia surinkti ir perduoti visus reikiamus duomenis per kelias valandas. Šis greitis yra ant priimtinos ribos, todėl šį sprendimą laikome laikinu, kuris leido patenkinti projekto išgavimo įrankio poreikį.
Tiksliniame paveikslėlyje, siekiant išspręsti duomenų išgavimo problemą, nagrinėjamos galimybės naudoti CDC sistemas, tokias kaip Oracle Golden Gate arba ETL įrankius, tokius kaip SAP DS.
Šaltinis: www.habr.com