Kot veste, SAP ponuja celotno paleto programske opreme za vzdrževanje podatkov o transakcijah in za obdelavo teh podatkov v sistemih za analizo in poročanje. Zlasti platforma SAP Business Warehouse (SAP BW) je komplet orodij za shranjevanje in analiziranje podatkov z obsežnimi tehničnimi zmogljivostmi. Kljub vsem svojim objektivnim prednostim ima sistem SAP BW eno pomembno pomanjkljivost. To je visok strošek shranjevanja in obdelave podatkov, še posebej opazen pri uporabi SAP BW v oblaku na Hani.
Kaj pa, če začnete uporabljati izdelek, ki ni SAP, in po možnosti odprtokodni izdelek kot prostor za shranjevanje? V X5 Retail Group smo izbrali GreenPlum. To seveda reši vprašanje stroškov, hkrati pa se takoj pojavijo težave, ki so bile skoraj privzeto rešene pri uporabi SAP BW.
Še posebej, kako pridobiti podatke iz izvornih sistemov, ki so večinoma rešitve SAP?
HR Metrics je bil prvi projekt, v katerem je bilo potrebno rešiti ta problem. Naš cilj je bil ustvariti repozitorij kadrovskih podatkov in zgraditi analitično poročanje na področju dela z zaposlenimi. V tem primeru je glavni vir podatkov transakcijski sistem SAP HCM, v katerem se izvajajo vse kadrovske, organizacijske in plačne aktivnosti.
Pridobivanje podatkov
V SAP BW obstajajo standardni ekstraktorji podatkov za sisteme SAP. Ti ekstraktorji lahko samodejno zbirajo potrebne podatke, spremljajo njihovo celovitost in določajo delte sprememb. Tukaj je na primer standardni vir podatkov za atribute zaposlenih 0EMPLOYEE_ATTR:
Rezultat črpanja podatkov iz njega za enega zaposlenega:
Po potrebi lahko tak ekstraktor prilagodite svojim zahtevam ali pa izdelate lasten ekstraktor.
Prva ideja, ki se je porodila, je bila možnost njihove ponovne uporabe. Na žalost se je to izkazalo za nemogočo nalogo. Večina logike je implementirana na strani SAP BW in ni bilo mogoče neboleče ločiti ekstraktorja na izvoru od SAP BW.
Postalo je očitno, da bomo morali razviti lasten mehanizem za pridobivanje podatkov iz sistemov SAP.
Struktura shranjevanja podatkov v SAP HCM
Da bi razumeli zahteve za tak mehanizem, moramo najprej ugotoviti, katere podatke potrebujemo.
Večina podatkov v SAP HCM je shranjenih v ravnih tabelah SQL. Na podlagi teh podatkov aplikacije SAP uporabniku vizualizirajo organizacijske strukture, zaposlene in druge kadrovske podatke. Tako je na primer videti organizacijska struktura v SAP HCM:
Fizično je takšno drevo shranjeno v dveh tabelah - v objektih hrp1000 in v hrp1001 povezavah med temi objekti.
Objekta “Oddelek 1” in “Pisarna 1”:
Odnos med predmeti:
Tako vrst predmetov kot vrst povezav med njimi je lahko ogromno. Obstajajo tako standardne povezave med objekti kot tudi prilagojene za vaše posebne potrebe. Na primer, standardno razmerje B012 med organizacijsko enoto in redno zaposlitvijo označuje vodjo oddelka.
Prikaz upravitelja v SAP:
Shranjevanje v tabeli zbirke podatkov:
Podatki o zaposlenih so shranjeni v tabelah pa*. Na primer, podatki o kadrovskih dogodkih za zaposlenega so shranjeni v tabeli pa0000
Odločili smo se, da bo GreenPlum zajemal “surove” podatke, tj. samo kopirajte jih iz tabel SAP. In neposredno v GreenPlumu bodo obdelani in pretvorjeni v fizične objekte (na primer Oddelek ali Zaposleni) in meritve (na primer povprečno število zaposlenih).
Definiranih je bilo približno 70 tabel, podatke iz katerih je potrebno prenesti v GreenPlum. Nato smo začeli razvijati metodo za prenos teh podatkov.
SAP ponuja precej veliko število integracijskih mehanizmov. Toda najlažji način je, da je neposreden dostop do baze podatkov prepovedan zaradi licenčnih omejitev. Tako morajo biti vsi integracijski tokovi implementirani na ravni aplikacijskega strežnika.
Naslednji problem je bilo pomanjkanje podatkov o izbrisanih zapisih v bazi SAP. Ko izbrišete vrstico v bazi podatkov, je fizično izbrisana. Tisti. oblikovanje delte spremembe na podlagi časa spremembe ni bilo mogoče.
Seveda ima SAP HCM mehanizme za beleženje sprememb podatkov. Na primer, za naknadni prenos v prejemne sisteme obstajajo kazalci sprememb, ki beležijo morebitne spremembe in na podlagi katerih se oblikuje Idoc (objekt za prenos v zunanje sisteme).
Primer IDoc za spremembo infotipa 0302 za zaposlenega s kadrovsko številko 1251445:
Ali vodenje dnevnikov sprememb podatkov v tabeli DBTABLOG.
Primer dnevnika za brisanje zapisa s ključem QK53216375 iz tabele hrp1000:
Toda ti mehanizmi niso na voljo za vse potrebne podatke, njihova obdelava na ravni aplikacijskega strežnika pa lahko porabi precej virov. Zato lahko množično omogočanje beleženja v vse potrebne tabele povzroči opazno poslabšanje zmogljivosti sistema.
Naslednji večji problem so bile gručaste tabele. Ocena časa in podatki o plačah v različici RDBMS SAP HCM so shranjeni kot nabor logičnih tabel za vsakega zaposlenega za vsak izračun. Te logične tabele so shranjene kot binarni podatki v tabeli pcl2.
Plačilni grozd:
Podatki iz gručastih tabel se ne morejo obravnavati kot ukaz SQL, ampak zahtevajo uporabo makrov SAP HCM ali posebnih funkcijskih modulov. V skladu s tem bo hitrost branja takšnih tabel precej nizka. Po drugi strani pa se v takšnih grozdih hranijo podatki, ki so potrebni le enkrat na mesec – končna plačilna lista in ocena časa. Torej hitrost v tem primeru ni tako kritična.
Pri ocenjevanju možnosti za oblikovanje delte sprememb podatkov smo se odločili, da razmislimo tudi o možnosti popolnega razkladanja. Možnost prenosa gigabajtov nespremenjenih podatkov med sistemi vsak dan morda ne izgleda dobro. Vendar pa ima tudi vrsto prednosti - ni potrebe po implementaciji delte na izvorni strani in implementaciji vdelave te delte na strani sprejemnika. Skladno s tem se zmanjšajo stroški in čas izvedbe, poveča pa se zanesljivost integracije. Hkrati je bilo ugotovljeno, da se skoraj vse spremembe v SAP HR zgodijo v obdobju treh mesecev pred trenutnim datumom. Tako smo se odločili za dnevni popolni prenos podatkov iz SAP HR N mesecev pred trenutnim datumom in mesečni popolni prenos. Parameter N je odvisen od posamezne tabele
in se giblje od 1 do 15.
Za pridobivanje podatkov je bila predlagana naslednja shema:
Zunanji sistem generira zahtevo in jo pošlje SAP HCM, kjer se ta zahteva preveri glede popolnosti podatkov in dovoljenj za dostop do tabel. Če je preverjanje uspešno, SAP HCM zažene program, ki zbere potrebne podatke in jih prenese v integracijsko rešitev Fuse. Fuse določi zahtevano temo v Kafki in tja prenese podatke. Nato se podatki iz Kafke prenesejo v Stage Area GP.
V tej verigi nas zanima problematika pridobivanja podatkov iz SAP HCM. Oglejmo si ga podrobneje.
Diagram interakcije SAP HCM-FUSE.
Zunanji sistem določi čas zadnje uspešne zahteve SAP-ju.
Postopek se lahko sproži s časovnikom ali drugim dogodkom, vključno z nastavitvijo časovne omejitve za čakanje na odgovor s podatki iz SAP in sprožitev ponovne zahteve. Nato ustvari delta zahtevo in jo pošlje SAP-u.
Podatki zahteve se telesu pošljejo v formatu json.
Metoda http: POST.
Primer zahteve:
Storitev SAP spremlja popolnost zahteve, skladnost s trenutno strukturo SAP in razpoložljivost dovoljenj za dostop do zahtevane tabele.
V primeru napak storitev vrne odgovor z ustrezno kodo in opisom. Če je nadzor uspešen, ustvari postopek v ozadju za ustvarjanje vzorca, ustvari in sinhrono vrne edinstveni ID seje.
V primeru napake jo zunanji sistem zabeleži v dnevnik. V primeru uspešnega odgovora posreduje id seje in ime tabele, za katero je bila podana zahteva.
Zunanji sistem registrira trenutno sejo kot odprto. Če za to tabelo obstajajo druge seje, se zaprejo z zabeleženim opozorilom.
Opravilo SAP v ozadju ustvari kazalec na podlagi podanih parametrov in podatkovnega paketa podane velikosti. Velikost serije je največje število zapisov, ki jih proces prebere iz baze podatkov. Privzeto se predpostavlja, da je enak 2000. Če je v vzorcu baze podatkov več zapisov, kot je uporabljena velikost paketa, se po prenosu prvega paketa oblikuje naslednji blok z ustreznim odmikom in povečano številko paketa. Številke se povečajo za 1 in pošljejo strogo zaporedno.
Nato SAP posreduje paket kot vhod v spletno storitev zunanjega sistema. In sistem izvaja nadzor nad dohodnim paketom. Seja s prejetim ID-jem mora biti registrirana v sistemu in mora biti v odprtem statusu. Če je številka paketa > 1, naj sistem zabeleži uspešen prejem prejšnjega paketa (package_id-1).
Če je nadzor uspešen, zunanji sistem razčleni in shrani podatke tabele.
Poleg tega, če je končna zastavica prisotna v paketu in je bila serializacija uspešna, je integracijski modul obveščen o uspešnem zaključku obdelave seje in modul posodobi status seje.
V primeru napake pri nadzoru/razčlenjevanju se napaka zabeleži in zunanji sistem bo zavrnil pakete za to sejo.
Podobno, v nasprotnem primeru, ko zunanji sistem vrne napako, se le-ta zabeleži in paketni prenos se ustavi.
Za zahtevanje podatkov na strani SAP HСM je bila implementirana integracijska storitev. Storitev je implementirana na ogrodju ICF (SAP Internet Communication Framework - ). Omogoča vam poizvedovanje po podatkih iz sistema SAP HCM z uporabo določenih tabel. Pri ustvarjanju zahtevka za podatke je mogoče določiti seznam določenih polj in parametrov filtriranja, da pridobimo potrebne podatke. Hkrati izvedba storitve ne pomeni nobene poslovne logike. Na strani zunanjega sistema so implementirani tudi algoritmi za izračun delte, poizvedbenih parametrov, nadzora integritete itd.
Ta mehanizem vam omogoča zbiranje in posredovanje vseh potrebnih podatkov v nekaj urah. Ta hitrost je na meji sprejemljivega, zato to rešitev obravnavamo kot začasno, kar je omogočilo zapolnitev potrebe po ekstrakcijskem orodju na projektu.
V ciljni sliki se za rešitev problema pridobivanja podatkov preučujejo možnosti za uporabo sistemov CDC, kot je Oracle Golden Gate, ali orodij ETL, kot je SAP DS.
Vir: www.habr.com