Kao što znate, SAP nudi cijeli niz softvera za održavanje podataka o transakcijama i za obradu tih podataka u sustavima za analizu i izvješćivanje. Konkretno, platforma SAP Business Warehouse (SAP BW) je skup alata za pohranu i analizu podataka sa širokim tehničkim mogućnostima. Uz sve svoje objektivne prednosti, SAP BW sustav ima jedan značajan nedostatak. To je visok trošak pohrane i obrade podataka, posebno primjetan kada se koristi SAP BW temeljen na oblaku na Hani.
Što ako počnete koristiti neki proizvod koji nije SAP, a po mogućnosti OpenSource proizvod kao pohranu? Mi u X5 Retail Group odabrali smo GreenPlum. Time se, naravno, rješava pitanje troškova, ali u isto vrijeme odmah se pojavljuju problemi koji su gotovo standardno riješeni pri korištenju SAP BW.
Konkretno, kako dohvatiti podatke iz izvornih sustava, koji su uglavnom SAP rješenja?
HR Metrics je bio prvi projekt u kojem je bilo potrebno riješiti ovaj problem. Cilj nam je bio stvoriti repozitorij HR podataka i izgraditi analitičko izvještavanje u području rada sa zaposlenicima. U ovom slučaju glavni izvor podataka je transakcijski sustav SAP HCM u kojem se provode sve kadrovske, organizacijske i platne aktivnosti.
Ekstrakcija podataka
U SAP BW postoje standardni ekstraktori podataka za SAP sustave. Ovi ekstraktori mogu automatski prikupiti potrebne podatke, nadzirati njihovu cjelovitost i odrediti delte promjene. Ovdje je, na primjer, standardni izvor podataka za atribute zaposlenika 0EMPLOYEE_ATTR:
Rezultat izvlačenja podataka iz njega za jednog zaposlenika:
Ako je potrebno, takav ekstraktor se može prilagoditi vašim zahtjevima ili se može izraditi vlastiti ekstraktor.
Prva ideja koja se pojavila bila je mogućnost njihove ponovne uporabe. Nažalost, to se pokazalo nemogućim zadatkom. Većina logike implementirana je na strani SAP BW i nije bilo moguće bezbolno odvojiti ekstraktor na izvoru od SAP BW.
Postalo je očito da ćemo morati razviti vlastiti mehanizam za izvlačenje podataka iz SAP sustava.
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-u pohranjuje se u ravnim SQL tablicama. Na temelju tih podataka, SAP aplikacije korisniku vizualiziraju organizacijske strukture, zaposlenike i druge HR informacije. Na primjer, ovako izgleda organizacijska struktura u SAP HCM-u:
Fizički je takvo stablo pohranjeno u dvije tablice – u hrp1000 objekte i u hrp1001 veze između tih 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 kako standardne veze između objekata tako i prilagođene za vaše specifične potrebe. Na primjer, standardni B012 odnos između organizacijske jedinice i radnog mjesta s punim radnim vremenom označava voditelja odjela.
Prikaz upravitelja u SAP-u:
Pohrana u tablici baze podataka:
Podaci o zaposlenicima pohranjuju se u pa* tablice. Na primjer, podaci o kadrovskim događajima za zaposlenika pohranjeni su u tablici pa0000
Odlučili smo da će GreenPlum uzimati "sirove" podatke, tj. samo ih kopirajte iz SAP tablica. A izravno u GreenPlumu bit će obrađeni i pretvoreni u fizičke objekte (na primjer, odjel ili zaposlenik) i metrike (na primjer, prosječni broj zaposlenih).
Definirano je oko 70 tablica iz kojih se podaci moraju prenijeti u GreenPlum. Nakon čega smo počeli razrađivati metodu za prijenos tih podataka.
SAP nudi prilično velik broj integracijskih mehanizama. Ali najlakši način je da je izravan pristup bazi podataka zabranjen zbog ograničenja licenciranja. Dakle, svi tokovi integracije moraju biti implementirani na razini aplikacijskog poslužitelja.
Sljedeći problem bio je nedostatak podataka o izbrisanim zapisima u SAP bazi. Kada izbrišete red u bazi podataka, on se fizički briše. Oni. formiranje delte promjene na temelju vremena promjene nije bilo moguće.
Naravno, SAP HCM ima mehanizme za bilježenje promjena podataka. Primjerice, za naknadni prijenos u sustave primatelja postoje pokazivači promjena koji bilježe eventualne promjene i na temelju kojih se formira Idoc (objekt za prijenos u vanjske sustave).
Primjer IDoc-a za promjenu infotipa 0302 za zaposlenika s matičnim brojem 1251445:
Ili vođenje dnevnika promjena podataka u tablici DBTABLOG.
Primjer loga za brisanje zapisa s ključem QK53216375 iz tablice hrp1000:
Ali ti mehanizmi nisu dostupni za sve potrebne podatke, a njihova obrada na razini aplikacijskog poslužitelja može potrošiti dosta resursa. Stoga, masovno omogućavanje bilježenja na svim potrebnim tablicama može dovesti do primjetne degradacije performansi sustava.
Sljedeći veliki problem bile su grupirane tablice. Podaci o procjeni vremena i plaćama u RDBMS verziji SAP HCM-a pohranjuju se kao skup logičkih tablica za svakog zaposlenika za svaki izračun. Ove logičke tablice su pohranjene kao binarni podaci u tablici pcl2.
Skupina plaća:
Podaci iz klasteriranih tablica ne mogu se smatrati SQL naredbom, već zahtijevaju upotrebu SAP HCM makronaredbi ili posebnih funkcijskih modula. Sukladno tome, brzina čitanja takvih tablica bit će prilično niska. S druge strane, takvi klasteri pohranjuju podatke koji su potrebni samo jednom mjesečno – konačnu plaću i procjenu radnog 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 sustava svaki dan možda neće izgledati dobro. Međutim, također ima brojne prednosti - nema potrebe za implementacijom delte na strani izvora i implementacijom ugradnje ove delte na strani prijemnika. Sukladno tome, smanjuju se troškovi i vrijeme implementacije, a povećava pouzdanost integracije. Istodobno je utvrđeno da se gotovo sve promjene u SAP HR događaju unutar horizonta od tri mjeseca prije tekućeg datuma. Stoga je odlučeno da se odlučimo za dnevno potpuno preuzimanje podataka iz SAP HR N mjeseci prije tekućeg datuma i mjesečno potpuno preuzimanje. Parametar N ovisi o konkretnoj tablici
i kreće se od 1 do 15.
Za ekstrakciju podataka predložena je sljedeća shema:
Vanjski sustav generira zahtjev i šalje ga SAP HCM-u, gdje se taj zahtjev provjerava u pogledu potpunosti podataka i dopuštenja za pristup tablicama. Ako je provjera uspješna, SAP HCM pokreće program koji prikuplja potrebne podatke i prenosi ih u integracijsko rješenje Fuse. Fuse određuje traženu temu u Kafki i tamo prenosi podatke. Zatim se podaci iz Kafke prenose u Stage Area GP.
U ovom lancu nas zanima pitanje izvlačenja podataka iz SAP HCM-a. Pogledajmo to detaljnije.
Dijagram interakcije SAP HCM-FUSE.
Eksterni sustav utvrđuje vrijeme zadnjeg uspješnog zahtjeva SAP-u.
Proces se može pokrenuti mjeračem vremena ili drugim događajem, uključujući postavljanje vremenskog ograničenja za čekanje odgovora s podacima iz SAP-a i pokretanje ponovljenog zahtjeva. Zatim generira delta zahtjev i šalje ga SAP-u.
Podaci zahtjeva šalju se tijelu u json formatu.
Metoda http: POST.
Primjer zahtjeva:
SAP usluga prati zahtjev za cjelovitost, usklađenost s trenutnom SAP strukturom i dostupnost dopuštenja pristupa traženoj tablici.
U slučaju pogreške servis vraća odgovor s odgovarajućim kodom i opisom. Ako je kontrola uspješna, stvara pozadinski proces za generiranje uzorka, generira i sinkrono vraća jedinstveni ID sesije.
U slučaju greške vanjski sustav to bilježi u dnevnik. U slučaju uspješnog odgovora, prenosi ID sesije i naziv tablice za koju je postavljen zahtjev.
Vanjski sustav registrira trenutnu sesiju kao otvorenu. Ako postoje druge sesije za ovu tablicu, one se zatvaraju uz zabilježeno upozorenje.
SAP pozadinski posao generira kursor na temelju navedenih parametara i paketa podataka navedene veličine. Veličina paketa je najveći broj zapisa koje proces čita iz baze podataka. Prema zadanim postavkama, pretpostavlja se da je jednak 2000. Ako postoji više zapisa u uzorku baze podataka od korištene veličine paketa, nakon prijenosa prvog paketa, formira se sljedeći blok s odgovarajućim pomakom i povećanim brojem paketa. Brojevi se povećavaju za 1 i šalju strogo sekvencijalno.
Zatim SAP prosljeđuje paket kao ulaz u web uslugu vanjskog sustava. A sustav provodi kontrole nad dolaznim paketom. Sesija s primljenim ID-om mora biti registrirana u sustavu i mora biti u otvorenom statusu. Ako je broj paketa > 1, sustav treba zabilježiti uspješan primitak prethodnog paketa (package_id-1).
Ako je kontrola uspješna, vanjski sustav analizira i sprema podatke tablice.
Osim toga, ako je konačna zastavica prisutna u paketu i serijalizacija je bila uspješna, integracijski modul dobiva obavijest o uspješnom završetku obrade sesije i modul ažurira status sesije.
U slučaju pogreške kontrole/parsiranja, pogreška se bilježi i paketi za ovu sesiju će biti odbijeni od strane vanjskog sustava.
Isto tako, u suprotnom slučaju, kada vanjski sustav vrati pogrešku, ona se bilježi i prijenos paketa se zaustavlja.
Za traženje podataka na strani SAP HSM implementirana je usluga integracije. Usluga je implementirana na ICF okviru (SAP Internet Communication Framework - ). Omogućuje vam postavljanje upita za podatke iz SAP HCM sustava pomoću određenih tablica. Prilikom izrade podatkovnog zahtjeva moguće je odrediti popis određenih polja i parametara filtriranja kako bi se dobili potrebni podaci. Pritom implementacija usluge ne podrazumijeva nikakvu poslovnu logiku. Algoritmi za izračun delte, parametara upita, nadzor integriteta itd. također su implementirani na strani vanjskog sustava.
Ovaj mehanizam omogućuje prikupljanje i prijenos svih potrebnih podataka u nekoliko sati. Ova brzina je na granici prihvatljivog, stoga ovo rješenje smatramo privremenim, čime smo pokrili potrebu za alatom za izvlačenje na projektu.
U ciljnoj slici, za rješavanje problema ekstrakcije podataka, istražuju se opcije za korištenje CDC sustava kao što je Oracle Golden Gate ili ETL alata kao što je SAP DS.
Izvor: www.habr.com