Kao što znate, SAP nudi čitav niz softvera kako za održavanje transakcijskih podataka tako i za obradu ovih podataka u sistemima za analizu i izvještavanje. Konkretno, platforma SAP Business Warehouse (SAP BW) je komplet alata za skladištenje i analizu podataka sa širokim tehničkim mogućnostima. Uz sve svoje objektivne prednosti, SAP BW sistem ima jedan značajan nedostatak. Ovo je visoka cijena pohrane i obrade podataka, posebno uočljiva kada se koristi SAP BW baziran na oblaku na Hani.
Što ako počnemo koristiti neki ne-SAP i po mogućnosti OpenSource proizvod kao skladište? Mi u X5 Retail Group odabrali smo GreenPlum. Ovo, naravno, rješava pitanje troškova, ali u isto vrijeme odmah se javljaju problemi koji su riješeni gotovo standardno kada se koristi SAP BW.
Konkretno, kako dohvatiti podatke iz izvornih sistema, koji su uglavnom SAP rješenja?
HR Metrics je bio prvi projekat u kojem je bilo potrebno riješiti ovaj problem. Naš cilj je bio kreiranje repozitorija HR podataka i izgradnja analitičkog izvještavanja u oblasti rada sa zaposlenima. U ovom slučaju, glavni izvor podataka je transakcijski sistem SAP HCM u kojem se provode sve kadrovske, organizacijske i platne aktivnosti.
Ekstrakcija podataka
U SAP BW postoje standardni ekstraktori podataka za SAP sisteme. Ovi ekstraktori mogu automatski prikupljati potrebne podatke, pratiti njihov integritet i odrediti delte promjena. Evo, na primjer, standardnog izvora podataka za atribute zaposlenika 0EMPLOYEE_ATTR:
Rezultat izdvajanja podataka iz njega za jednog zaposlenog:
Ako je potrebno, takav ekstraktor se može modificirati kako bi odgovarao vašim vlastitim zahtjevima ili se može kreirati vlastiti ekstraktor.
Prva ideja koja se pojavila bila je mogućnost njihove ponovne upotrebe. Nažalost, ovo se pokazalo kao nemoguć zadatak. Većina logike je implementirana na strani SAP BW, i nije bilo moguće bezbolno odvojiti ekstraktor na izvoru od SAP BW.
Postalo je očigledno da ćemo morati da razvijemo sopstveni mehanizam za izdvajanje podataka iz SAP sistema.
Struktura pohrane podataka u SAP HCM
Da bismo razumjeli zahtjeve za takav mehanizam, prvo moramo odrediti koji nam podaci trebaju.
Većina podataka u SAP HCM pohranjena je u ravnim SQL tablicama. Na osnovu ovih podataka, SAP aplikacije korisniku vizualiziraju organizacijske strukture, zaposlenike i druge HR informacije. Na primjer, ovako izgleda organizacijska struktura u SAP HCM:
Fizički, takvo stablo je pohranjeno u dvije tabele - u hrp1000 objektima i u hrp1001 vezama između ovih objekata.
Objekti “Odjel 1” i “Ured 1”:
Odnos između objekata:
Može postojati ogroman broj obje vrste objekata i vrsta veza između njih. Postoje i standardne veze između objekata i one prilagođene za vaše specifične potrebe. Na primjer, standardni B012 odnos između organizacione jedinice i pozicije s punim radnim vremenom označava šefa odjela.
Prikaz menadžera u SAP-u:
Skladištenje u tabeli baze podataka:
Podaci o zaposlenima pohranjeni su u pa* tabelama. Na primjer, podaci o kadrovskim događajima za zaposlenog pohranjuju se u tablicu pa0000
Odlučili smo da će GreenPlum uzimati „sirove“ podatke, tj. samo ih kopirajte iz SAP tabela. I direktno u GreenPlumu oni će biti obrađeni i konvertovani u fizičke objekte (na primjer, odjel ili zaposleni) i metrike (na primjer, prosječan broj zaposlenih).
Definirano je oko 70 tabela iz kojih se podaci moraju prenijeti u GreenPlum. Nakon toga smo počeli da razrađujemo metodu za prenošenje ovih podataka.
SAP nudi prilično veliki broj mehanizama integracije. Ali najlakši način je da je direktan pristup bazi podataka zabranjen zbog ograničenja licenciranja. Dakle, svi tokovi integracije moraju biti implementirani na razini poslužitelja aplikacija.
Sljedeći problem je bio nedostatak podataka o izbrisanim zapisima u SAP bazi podataka. Kada izbrišete red u bazi podataka, on se fizički briše. One. formiranje delte promjene na osnovu vremena promjene nije bilo moguće.
Naravno, SAP HCM ima mehanizme za evidentiranje promjena podataka. Na primjer, za naknadni prijenos na sisteme primatelja, postoje pokazivači promjena koji bilježe sve promjene i na osnovu kojih se formira Idoc (objekat za prijenos na vanjske sisteme).
Primjer IDoc-a za promjenu infotipa 0302 za zaposlenog sa brojem osoblja 1251445:
Ili vođenje dnevnika promjena podataka u tablici DBTABLOG.
Primjer dnevnika za brisanje zapisa s ključem QK53216375 iz tabele hrp1000:
Ali ovi mehanizmi nisu dostupni za sve potrebne podatke, a njihova obrada na razini poslužitelja aplikacija može potrošiti dosta resursa. Stoga, masovno omogućavanje logovanja na svim potrebnim tabelama može dovesti do primjetne degradacije performansi sistema.
Sljedeći veliki problem bile su grupisane tabele. Procjena vremena i podaci o plaćama u RDBMS verziji SAP HCM pohranjeni su kao skup logičkih tablica za svakog zaposlenika za svaki obračun. Ove logičke tablice su pohranjene kao binarni podaci u tablici pcl2.
Platni klaster:
Podaci iz klasteriranih tablica ne mogu se smatrati SQL naredbom, ali zahtijevaju korištenje SAP HCM makroa ili posebnih funkcionalnih modula. U skladu s tim, brzina čitanja takvih tablica bit će prilično niska. S druge strane, takvi klasteri pohranjuju podatke koji su potrebni samo jednom mjesečno – konačan platni spisak i procjenu vremena. Dakle, brzina u ovom slučaju nije toliko kritična.
Procjenjujući opcije za formiranje delte promjena podataka, odlučili smo razmotriti i opciju potpunog istovara. Mogućnost prijenosa gigabajta nepromijenjenih podataka između sistema svaki dan možda neće izgledati dobro. Međutim, on takođe ima brojne prednosti - nema potrebe da se implementira delta na strani izvora i implementira ugradnja ove delte na strani prijemnika. Shodno tome, smanjuju se troškovi i vrijeme implementacije, a povećava se pouzdanost integracije. Istovremeno je utvrđeno da se gotovo sve promjene u SAP HR-u dešavaju u horizontu od tri mjeseca prije tekućeg datuma. Stoga je odlučeno da se odluči za dnevno puno preuzimanje podataka iz SAP HR N mjeseci prije tekućeg datuma i mjesečno puno preuzimanje. N parametar ovisi o specifičnoj tablici
i kreće se od 1 do 15.
Predložena je sljedeća shema za ekstrakciju podataka:
Vanjski sistem generira zahtjev i šalje ga SAP HCM-u, gdje se provjerava kompletnost podataka i dozvola za pristup tabelama ovog zahtjeva. Ako je provjera uspješna, SAP HCM pokreće program koji prikuplja potrebne podatke i prenosi ih u Fuse integracijsko rješenje. Fuse određuje potrebnu temu u Kafki i tamo prenosi podatke. Zatim se podaci iz Kafke prenose u Stage Area GP.
U ovom lancu nas zanima pitanje izdvajanja podataka iz SAP HCM. Pogledajmo to detaljnije.
SAP HCM-FUSE dijagram interakcije.
Vanjski sistem određuje vrijeme posljednjeg uspješnog zahtjeva prema SAP-u.
Proces se može pokrenuti pomoću tajmera ili drugog događaja, uključujući postavljanje vremenskog ograničenja za čekanje na odgovor s podacima iz SAP-a i pokretanje zahtjeva za ponavljanje. Zatim generiše delta zahtjev i šalje ga SAP-u.
Podaci zahtjeva se šalju tijelu u json formatu.
Metoda http: POST.
Primjer zahtjeva:
SAP servis prati zahtjev za potpunost, usklađenost sa trenutnom SAP strukturom i dostupnost dozvole pristupa traženoj tabeli.
U slučaju greške, servis vraća odgovor sa odgovarajućim kodom i opisom. Ako je kontrola uspješna, kreira pozadinski proces za generiranje uzorka, generira i sinhrono vraća jedinstveni ID sesije.
U slučaju greške, eksterni sistem to bilježi u dnevnik. U slučaju uspješnog odgovora, prenosi ID sesije i naziv tabele za koju je zahtjev napravljen.
Vanjski sistem registruje trenutnu sesiju kao otvorenu. Ako postoje druge sesije za ovu tabelu, one se zatvaraju sa upozorenjem koje se evidentira.
SAP pozadinski posao generira kursor na temelju specificiranih parametara i paketa podataka određene veličine. Veličina serije je maksimalni broj zapisa koje proces čita iz baze podataka. Podrazumevano se pretpostavlja da je jednako 2000. Ako u uzorku baze podataka ima više zapisa nego što je korišćena veličina paketa, nakon prenošenja prvog paketa, formira se sledeći blok sa odgovarajućim pomakom i povećanim brojem paketa. Brojevi se povećavaju za 1 i šalju striktno uzastopno.
Zatim, SAP prosljeđuje paket kao ulaz web servisu vanjskog sistema. I sistem vrši kontrole nad dolaznim paketom. Sesija sa primljenim ID-om mora biti registrovana u sistemu i mora biti u otvorenom statusu. Ako je broj paketa > 1, sistem bi trebao zabilježiti uspješan prijem prethodnog paketa (package_id-1).
Ako je kontrola uspješna, vanjski sistem analizira i sprema podatke tablice.
Dodatno, ako je konačna zastavica prisutna u paketu i serijalizacija je bila uspješna, integracijski modul se obavještava o uspješnom završetku obrade sesije i modul ažurira status sesije.
U slučaju greške u kontroli/parsingu, greška se evidentira i paketi za ovu sesiju će biti odbijeni od strane eksternog sistema.
Slično, u suprotnom slučaju, kada vanjski sistem vrati grešku, ona se evidentira i prijenos paketa se zaustavlja.
Za traženje podataka na strani SAP HSM implementiran je servis integracije. Usluga je implementirana na ICF okviru (SAP Internet Communication Framework - ). Omogućuje vam da tražite podatke iz SAP HCM sistema koristeći određene tablice. Prilikom kreiranja zahtjeva za podacima moguće je specificirati listu specifičnih polja i parametara filtriranja kako bi se dobili potrebni podaci. Istovremeno, implementacija usluge ne podrazumijeva nikakvu poslovnu logiku. Algoritmi za izračunavanje delta, parametara upita, praćenje integriteta, itd. takođe su implementirani na strani eksternog sistema.
Ovaj mehanizam vam omogućava da prikupite i prenesete sve potrebne podatke za nekoliko sati. Ova brzina je na granici prihvatljive, pa ovo rješenje smatramo privremenim, što je omogućilo da se ispuni potreba za alatom za ekstrakciju na projektu.
U ciljnoj slici, kako bi se riješio problem ekstrakcije podataka, istražuju se opcije za korištenje CDC sistema kao što su Oracle Golden Gate ili ETL alati kao što je SAP DS.
izvor: www.habr.com