Kao što je poznato, kompanija SAP nudi kompletnu paletu softverskih rešenja, kako za vođenje transakcionih podataka, tako i za obradu tih podataka u sistemima analize i izveštavanja. Konkretno, platforma SAP Business Warehouse (SAP BW) predstavlja alat za skladištenje i analizu podataka, koji posjeduje široke tehničke mogućnosti. I pored svih svojih objektivnih prednosti, sistem SAP BW ima jedan značajan nedostatak. To je visoka cena skladištenja i obrade podataka, posebno primetna prilikom korišćenja cloud SAP BW on Hana.
A šta ako kao skladište počnemo da koristimo neki non-SAP i poželjno OpenSource proizvod? Mi u X5 Retail Group smo se odlučili za GreenPlum. To naravno rešava pitanje cene, ali odmah se javljaju pitanja koja su se pri korišćenju SAP BW rešavala praktično podrazumevano.
Naime, kako preuzeti podatke iz izvora sistema, koji su većinom rešenja SAP?
„HR-metrika“ je postao prvi projekat u kojem je bilo potrebno rešiti ovaj problem. Naš cilj je bio kreiranje skladišta HR-podataka i izrada analitičkog izveštaja u oblasti rada sa zaposlenima. Osnovni izvor podataka je transakcioni sistem SAP HCM, u kojem se vode svi kadrovski, organizacioni i platni događaji.
Ekstrakcija podataka
U SAP BW postoje standardni ekstraktori podataka za SAP sisteme. Ovi ekstraktori mogu automatski prikupljati potrebne podatke, pratiti njihovu celovitost i odrediti delte promena. Na primer, standardni izvor podataka za atribute zaposlenika 0EMPLOYEE_ATTR:
Rezultat ekstrakcije podataka iz njega za jednog zaposlenika:
Po potrebi, takav ekstraktor se može modifikovati prema sopstvenim zahtevima ili može biti kreiran sopstveni ekstraktor.
Prva ideja je bila mogućnost njihove ponovne upotrebe. Nažalost, to se pokazalo kao neizvodiv zadatak. Velika većina logike je realizovana na strani SAP BW, i nije bilo moguće bezbolno odvojiti ekstraktor na izvoru od SAP BW.
Postalo je očigledno da će biti potrebna izrada sopstvenog mehanizma za ekstrakciju podataka iz SAP sistema.
Struktura shranjevanja podatkov v SAP HCM
Za razumevanje zahtev za takšen mehanizem je najprej treba določiti, kateri podatki so nam potrebni.
Večina podatkov v SAP HCM je shranjenih v ravnih SQL tabelah. Na podlagi teh podatkov aplikacije SAP vizualizirajo organske strukture, zaposlene in druge HR informacije. Na primer, tako v SAP HCM izgleda organska struktura:
Fizično je to drevo shranjeno v dveh tabelah - hrp1000 objekti in hrp1001 povezave med temi objekti.
Objekti 'Oddelek 1' in 'Upravljanje 1':
Povezava med objekti:
Obstaja lahko ogromno različnih tipov objektov in tipov povezav med njimi. Obstajajo tako standardne povezave med objekti kot tudi prilagojene za specifične potrebe. Na primer, standardna povezava B012 med organskimi enotami in delovnimi mesti označuje vodjo oddelka.
Prikaz vodje v SAP:
Shranjevanje v podatkovni bazi:
Podatki o zaposlenih so shranjeni v tabelah pa*. Na primer, podatki o kadrovskih dogodkih zaposlenega so shranjeni v tabeli pa0000.
Odločili smo se, da bo GreenPlum prevzel 'surove' podatke, tj. preprosto jih kopiral iz SAP tabel. V GreenPlumu bodo ti podatki obdelani in pretvorjeni v fizične objekte (na primer Oddelek ali Zaposleni) in metrike (na primer povprečno število zaposlenih).
Določili smo približno 70 tabel, katerih podatke je treba prenesti v GreenPlum. Nato smo se lotili obravnave načina prenosa teh podatkov.
SAP ponuja precej obsežno število mehanizmov integracije. Vendar je najpreprostejši način - neposreden dostop do podatkovne zbirke prepovedan zaradi licenčnih omejitev. Tako morajo biti vsi integracijski tokovi izvedeni na ravni strežnika aplikacij.
Naslednja težava je bila pomanjkanje podatkov o izbrisanih zapisih v podatkovni zbirki SAP. Ko se vrstica izbriše iz podatkovne zbirke, se fizično izbriše. To pomeni, da ni bilo mogoče oblikovati delte sprememb po času spremembe.
Seveda, v SAP HCM obstajajo mehanizmi za beleženje sprememb podatkov. Na primer, za kasnejši prenos v prejemniške sisteme obstajajo kazalci sprememb (change pointer), ki beležijo vse spremembe in na podlagi katerih se oblikujejo Idoc (objekt za prenos v zunanje sisteme).
Primer IDoc spremembe infotipa 0302 za zaposlenega s številko 1251445:
Ali vodenje logov sprememb podatkov v tabeli DBTABLOG.
Primer loga brisanja zapisa s ključno vrednostjo QK53216375 iz tabele hrp1000:
A vendar so ti mehanizmi na voljo le za nekatere potrebne podatke, njihova obdelava na ravni strežnika aplikacij pa lahko porabi precej veliko virov. Zato lahko množično vključevanje beleženja za vse potrebne tabele povzroči pomembno degradacijo zmogljivosti sistema.
Naslednja resna težava so bile klasterske tabele. Podatki o ocenah časa in obračunavanju plače v RDBMS različici SAP HCM so shranjeni v obliki niza logičnih tabel za vsakega zaposlenega pri vsakem obračunu. Te logične tabele v obliki binarnih podatkov so shranjene v tabeli pcl2.
Klasterski obračun plače:
Podatkov iz klasterskih tabel ni mogoče prebrati z SQL ukazom; potrebna je uporaba makro ukazov SAP HCM ali posebnih funkcionalnih modulov. Zato bo hitrost branja takih tabel precej nizka. Po drugi strani pa v takšnih klasterih hranimo podatke, ki so potrebni le enkrat na mesec – končni obračun plače in ocena časa. Zato hitrost v tem primeru ni tako kritična.
Pri ocenjevanju možnosti oblikovanja delta sprememb podatkov smo se odločili tudi za obravnavo možnosti popolnega izvoza. Možnost, da vsak dan prenašamo gigabajte nespremenjenih podatkov med sistemi, ni privlačna. Vendar pa ima tudi vrsto prednosti – ni potrebe po implementaciji delta na strani vira, prav tako pa ni potrebe po implementaciji vgradnje te delte na strani prejemnika. Zato se zmanjša strošek in čas izvedbe ter poveča zanesljivost integracije. Ugotovljeno je bilo, da se skoraj vse spremembe v SAP HR zgodijo v obdobju treh mesecev pred trenutnim datumi. Tako je bilo sprejeto odločitev, da se ustavimo na vsakodnevnem popolnem izvozu podatkov iz SAP HR za N mesecev pred trenutnim datumom ter na mesečnem popolnem izvozu. Parameter N je odvisen od konkretne tabele,
in se giblje med 1 in 15.
Za ekstrakcijo podatkov je bila predlagana naslednja shema:
Zunanjisistem oblikuje zahtevo in jo pošlje v SAP HCM, kjer se ta zahteva preveri glede popolnosti podatkov in pooblastil za dostop do tabel. V primeru uspešnega preverjanja v SAP HCM deluje program, ki zbira potrebne podatke in jih posreduje integracijski rešitvi Fuse. Fuse določi potrebni naslov v Kafka in podatke pošlje tja. Nato se podatki iz Kafka pošljejo v Stage Area GP.
V tej verigi nas zanima vprašanje pridobivanja podatkov iz SAP HCM. Osredotočimo se na to podrobneje.
Shema interakcije SAP HCM-FUSE.
Zunanja sistem določi čas zadnje uspešne zahteve v SAP.
Postopek se lahko sproži s časovnikom ali drugim dogodkom, vključno z določitvijo časovnega omejitvenega roka za čakajoč odgovor s podatki iz SAP ter iniciacijo ponovne zahteve. Nato oblikuje zahtevo delte in jo pošlje v SAP.
Podatki zahteve se prenašajo v telo v formatu json.
Metoda http: POST.
Primer zahteve:
Služba SAP izvaja nadzor nad zahtevo glede popolnosti, skladnosti s trenutno strukturo SAP ter prisotnosti dovoljenja za dostop do zahtevane tabele.
V primeru napak služba vrne odgovor s pripadajočo kodo in opisom. V primeru uspešnega nadzora ustvari ozadje za oblikovanje izbire, generira in sinhrono vrne edinstven id seje.
Zunanja sistem v primeru napake to zabeleži v dnevniku. V primeru uspešnega odgovora posreduje id seje in ime tabele, za katero je bila izvedena zahteva.
Zunanja sistem zabeleži trenutno sejo kot odprto. Če obstajajo druge seje za to tabelo, se te zaprejo z zabeleženjem opozorila v dnevniku.
Ozadnje opravilo SAP oblikuje kazalec po določenih parametrih in paket podatkov določene velikosti. Velikost paketa je največje število zapisov, ki jih proces prebere iz Baze podatkov. Privzeto je nastavljeno na 2000. Če v izbiri Baze podatkov obstaja več zapisov, kot je uporabljena velikost paketa, po prenosu prvega paketa nastane naslednji blok s pripadajočim offsetom in inkrementiranim številom paketa. Številke se inkrementirajo za 1 in pošljejo strogo zaporedno.
Nato SAP pošilja paket v vnos spletni storitvi zunanjega sistema. Ta sistem izvaja kontrole prihajajočega paketa. V sistemu mora biti registrirana seja s prejetim id-jem in mora biti v odprtem statusu. Če je številka paketa > 1, mora biti v sistemu registrirano uspešno prejemanje prejšnjega paketa (package_id-1).
V primeru uspešne kontrole zunanja sistem analizira in shrani podatke iz tabele.
Poleg tega, če paket vsebuje zastavico final in je bila serializacija uspešna, se izvede obvestilo integracijskega modula o uspešnjem zaključku obdelave seje in modul posodobi status seje.
V primeru napake pri kontrolah/analizi se napaka beleži in paketi za to sejo bodo zavrženi s strani zunanjega sistema.
Prav tako, v obratnem primeru, ko zunanja sistem vrne napako, se ta zabeleži in prenos paketov preneha.
Za pridobivanje podatkov na strani SAP HCM je bil implementiran integracijski servis. Servis je implementiran na okvirju ICF (SAP Internet Communication Framework — ). Omogoča poizvedovanje podatkov iz sistema SAP HCM po določenih tabelah. Pri oblikovanju poizvedbe podatkov je mogoče določiti seznam konkretnih polj in parametre filtriranja za pridobitev potrebnih podatkov. Pri tem implementacija servisa ne predvideva nobene poslovne logike. Algoritmi izračuna delta, parametrov poizvedbe, kontrole celovitosti itd. se izvajajo na strani zunanjega sistema.
Ta mehanizem omogoča zbiranje in prenos vseh potrebnih podatkov v nekaj urah. Takšna hitrost je na meji sprejemljive, zato to rešitev obravnavamo kot začasno, ki je omogočila zapolnitev potreb po orodju za ekstrakcijo na projektu.
V ciljni sliki za rešitev naloge ekstrakcije podatkov se preučujejo možnosti uporabe sistemov CDC, kot sta Oracle Golden Gate ali ETL orodij, kot je SAP DS.
Izvor: habr.com
