Si e njohur, kompania SAP ofron një gamë të plotë të softuerit, si për menaxhimin e të dhënave transaksionale ashtu edhe për përpunimin e këtyre të dhënave në sistemet e analizës dhe raportimit. Në veçanti, platforma SAP Business Warehouse (SAP BW) përbënte një mjet për ruajtjen dhe analizimin e të dhënave, me mundësi të gjera teknike. Megjithë të gjitha përfitimet e saj objektive, sistemi SAP BW ka një mangësi të rëndësishme. Kjo është kostoja e lartë e ruajtjes dhe përpunimit të të dhënave, veçanërisht e dukshme kur përdoret SAP BW on Hana në cloud.
Por çfarë nëse si një depo fillojmë të përdorim ndonjë produkt non-SAP dhe preferohet open-source? Ne në grupin X5 Retail kemi vendosur për GreenPlum. Kjo sigurisht që zgjidh çështjen e kostos, por menjëherë ngjall pyetje që me përdorimin e SAP BW zgjidheshin praktikisht automatikisht.
Veçanërisht, si të marrim të dhëna nga sistemet burimore, të cilat shumicën e rasteve janë zgjidhje SAP?
«HR-metrikat» ishte projekti i parë, në të cilin duhej të zgjidhim këtë problem. Qëllimi ynë ishte krijimi i një depoje të dhënash HR dhe ndërtimi i raportimeve analitike në drejtimin e punës me punonjësit. Në këtë rast, burimi kryesor i të dhënave është sistemi transaksional SAP HCM, në të cilin menaxhohen të gjitha aktivitetet e stafit, organizatës dhe pagave.
Ekstraktimi i të dhënave
Në SAP BW për sistemet SAP ekzistojnë ekstraktues standard të të dhënave. Këta ekstraktues mund të mbledhin automatikisht të dhënat e nevojshme, të ndjekin integritetin e tyre, të përcaktojnë deltat e ndryshimeve. Ja, për shembull, burimi standard i të dhënave për atributet e punonjësve 0EMPLOYEE_ATTR:
Rezultati i ekstraktimit të të dhënave prej tij për një punonjës:
Nëse është e nevojshme, një ekstraktues i tillë mund të modifikohet sipas kërkesave të veta ose mund të krijohet një ekstraktues të ri.
Ideja e përdorimit të tyre u shfaq e para. Fatkeqësisht, kjo u tregua një detyrë e pamundur. Pjesa më e madhe e logjikës është realizuar nga ana e SAP BW, dhe nuk arritëm të ndajnë me lehtësi ekstraktorin në burim nga SAP BW.
U bë e qartë se do të ishte e nevojshme zhvillimi i një mekanizmi të vet për nxjerrjen e të dhënave nga sistemet SAP.
Struktura e ruajtjes së të dhënave në SAP HCM
Për të kuptuar kërkesat për një mekanizëm të tillë, fillimisht duhet të përcaktojmë cilat të dhëna do të na nevojiten.
Shumica e të dhënave në SAP HCM ruhen në tabela SQL të sheshta. Në bazë të këtyre të dhënave, aplikacionet SAP vizualizojnë për përdoruesin strukturat organizative, punonjësit dhe informacionin e tjera HR. Për shembull, kështu duket struktura organizative në SAP HCM:
Fizikisht, kjo pemë ruhet në dy tabela — në hrp1000 objektet dhe në hrp1001 lidhjet mes këtyre objekteve.
Objektet "Departamenti 1" dhe "Menaxhimi 1":
Lidhja midis objekteve:
Ka një numër të madh të tipeve të objekteve dhe tipeve të lidhjeve midis tyre. Ekzistojnë si lidhje standarde midis objekteve, ashtu edhe të personalizuara për nevojat specifike. Për shembull, lidhja standarde B012 midis një njësi organizative dhe një pozite të caktuar tregon mbi shefin e nëndegës.
Shfaqja e shefit në SAP:
Ruajtja në tabelën e DB:
Të dhënat për punonjësit ruhen në tabelat pa*. Për shembull, të dhënat mbi aktivitetet e punës për një punonjës ruhen në tabelën pa0000.
Ne vendosëm që GreenPlum do të marrë të dhënat "të papërpunuara", dmth, do t'i kopjojë ato thjesht nga tabelat SAP. Dhe pas kësaj, në GreenPlum do të përpunohen dhe përmirësohen në objekte fizike (p.sh., Departament ose Punonjës) dhe metrikat (p.sh., numri mesatar i punonjësve).
I janë përcaktuar rreth 70 tabela, të dhënat nga të cilat duhet të kalojnë në GreenPlum. Pas kësaj, ne filluam të punojmë mbi mënyrën e kalimit të këtyre të dhënave.
SAP ofron një numër të konsiderueshëm mekanizmash integrimi. Por mënyra më e lehtë – qasja direkte në bazën e të dhënave është e ndaluar për shkak të kufizimeve të licencës. kështu që, të gjitha rrjedhat e integrimit duhet të realizohen në nivelin сервера e aplikacioneve.
Problemi tjetër ishte mungesa e të dhënave për regjistrimet e fshira në DB SAP. Kur një rresht zhduket në DB, ai zhduket fizikisht. Domethënë, formimi i diferencës së ndryshimeve në kohën e ndryshimit nuk ishte i mundur.
Sigurisht, në SAP HCM ekzistojnë mekanizma për regjistrimin e ndryshimeve të të dhënave. Për shembull, për kalimin e mëvonshëm në sistemet marrës ekzistojnë tregues ndryshimesh (change pointer), të cilat regjistrojnë çdo ndryshim dhe mbi bazën e të cilave formohen Idoc (objekti për transferimin në sisteme të jashtme).
Shembulli i ndryshimit të infotype 0302 për një punonjës me numrin e regjistrimit 1251445:
Ose mbajtja e logëve të ndryshimeve të të dhënave në tabelën DBTABLOG.
Shembulli i logut të fshirjes së një regjistrimi me çelësin QK53216375 nga tabela hrp1000:
Por këto mekanizma nuk janë të disponueshëm për të gjitha të dhënat e nevojshme dhe përpunimi i tyre në nivelin e serverit të aplikacioneve mund të konsumojë mjaft burime. Prandaj, aktivizimi masiv i logimit për të gjitha tabelat e nevojshme mund të çojë në një degradim të dukshëm të performancës së sistemit.
Problemi tjetër i rëndësishëm ishte tabelat klaster. Të dhënat e llogaritjes së kohës dhe llogaritjes së pagës në RDBMS versionin SAP HCM ruhen si një grup tabelash logjike për çdo punonjës për çdo llogaritje. Këto tabela logjike ruhen në formën e të dhënave binare në tabelën pcl2.
Klasteri i llogaritjes së pagës:
Të dhënat nga tabelat klaster nuk mund të lexohen me komandën SQL, dhe nevojitet përdorimi i makrokomanandave SAP HCM ose moduleve funksionale speciale. Si rezultat, shpejtësia e leximit të këtyre tabelave do të jetë mjaft e ulët. Nga ana tjetër, në këto klaster ruhen të dhëna që nevojiten vetëm një herë në muaj – llogaritja përfundimtare e pagës dhe vlerësimi i kohës. Pra, shpejtësia në këtë rast nuk është aq kritike.
Duke vlerësuar opsionet për formimin e dytë të ndryshimeve të të dhënave, vendosëm gjithashtu të shqyrtojmë opsionin me eksport të plotë. Opsioni për të kaluar gigabajt të të dhënave të pandryshuara çdo ditë midis sistemeve nuk mund të duket tërheqës. Megjithatë, ai ka dhe disa përfitime – nuk ka nevojë as për realizimin e dytës nga ana e burimit, as për realizimin e integrimit të kësaj dytës nga ana e marrësit. Si rezultat, u zvogëloa kostoja dhe koha e realizimit, dhe u rrit besueshmëria e integrimit. Në të njëjtën kohë, u përcaktua se pothuajse të gjitha ndryshimet në SAP HR ndodhin brenda një harku tre mujor deri në datën aktuale. Prandaj, u mor vendimi për të qëndruar te eksporti i plotë të të dhënave nga SAP HR për N muaj deri në datën aktuale dhe për eksportin e plotë çdo muaj. Parametri N varet nga tabela specifike
dhe varion nga 1 në 15.
Për ekstraktimin e të dhënave, u propozuar skema e mëposhtme:
Sistemi i jashtëm formon një kërkesë dhe e dërgon në SAP HCM, ku kjo kërkesë kontrollohet për plotësinë e të dhënave dhe kompetencat për qasje në tavola. Në rast të një verifikimi të suksesshëm, në SAP HCM punon një program që mbledh të dhënat e nevojshme dhe i transmeton ato në zgjidhjen e integrimit Fuse. Fuse përcakton temën e nevojshme në Kafka dhe e dërgon atje të dhënat. Më pas, të dhënat nga Kafka dërgohen në Stage Area GP.
Ne në këtë zinxhir jemi të interesuar për procesin e nxjerrjes së të dhënave nga SAP HCM. Do të ndalemi më në detaje mbi këtë.
Schema e bashkëpunimit SAP HCM-FUSE.
Sistemi i jashtëm përcakton kohën e kërkesës së fundit të suksesshme në SAP.
Processi mund të iniciohet nga një kohëmatës ose një ngjarje tjetër, përfshirë mundësinë e vendosjes së një kohëprerjeje për pritjen e një përgjigjeje me të dhëna nga SAP dhe iniciimin e një kërkese të përsëritur. Pas kësaj, formon një kërkesë për delta dhe e dërgon atë në SAP.
Të dhënat e kërkesës dërgohen në trup në formatin json.
Metoda http: POST.
Shembulli i kërkesës:
Shërbimi SAP kryen kontrollin e kërkesës për plotësi, përputhje me strukturën aktuale të SAP, dhe pranimin e aksesit në tavolat e kërkuara.
Në rast gabimesh, shërbimi kthen një përgjigje me kodin përkatës dhe përshkrimin. Në rast kontrolli të suksesshëm, krijon një proces në sfond për formimin e përzgjedhjes, gjeneron dhe kthen në mënyrë sinhron një ID unik të sesionit.
Sistemi i jashtëm në rast gabimi e regjistron atë në ditar. Në rast të një përgjigjeje të suksesshme, transmeton ID-në e sesionit dhe emrin e tavolës për të cilën u bë kërkesa.
Sistemi i jashtëm regjistron sesionin aktual si të hapur. Nëse ka sesione të tjera për këtë tavollë, ato mbyllen duke regjistruar një paralajmërim në ditar.
Detyra në sfond SAP formon një kursori sipas parametrave të caktuara dhe një paketë të dhënash me madhësi të caktuar. Madhësia e paketës - numri maksimal i rekordeve që procesi lexon nga Baza e të Dhënave. Në mënyrë të parazgjedhur merret si 2000. Nëse në përzgjedhjen e Baza e të Dhënave ka më shumë rekorde se madhësia e përdorur e paketës, pas dërgimit të paketës së parë formohet blloku tjetër me offsetin përkatës dhe numrin e paketës të inkrementuar. Numrat inkrementohen me 1 dhe dërgohen rreptësisht në radhë.
Më pas, SAP dërgon paketën në hyrje të shërbimit web të sistemit të jashtëm. Ai sistem realizon kontrollet e paketës në hyrje. Në sistem duhet të jetë regjistruar një seancë me ID-në e marrë dhe ajo duhet të jetë në statusin e hapur. Nëse numri i paketës > 1, në sistem duhet të jetë regjistruar marrja e suksesshme e paketës së mëparshme (package_id-1).
Në rastin e kontrollit të suksesshëm, sistemi i jashtëm parse dhe ruan të dhënat e tabelës.
Për më tepër, nëse në paketë është prania e flamurit final dhe serializimi ka kaluar me sukses, ndodh njoftimi i modulit të integrimit për përfundimin e suksesshëm të përpunimit të sesionit dhe moduli përditëson statusin e sesionit.
Në rast gabimi gjatë kontrolleve/parsing, gabimi regjistrohet dhe paketat për këtë seancë do të refuzohen nga sistemi i jashtëm.
Po ashtu, në rastin e kundërt, kur sistemi i jashtëm kthen një gabim, ai regjistrohet dhe ndalet transmetimi i paketave.
Për kërkesat e të dhënave në anën e SAP HCM është realizuar një shërbim integrimi. Shërbimi është realizuar në framework-un ICF (SAP Internet Communication Framework — ). Ai lejon marrëveshjen e të dhënave nga sistemi SAP HCM nga disa tabela të caktuara. Gjatë formimit të kërkesës për të dhëna, ka mundësi të caktosh një listë të fushave specifike dhe parametrat e filtrimit me qëllim marrjen e të dhënave të nevojshme. Ndërkohë, realizimi i shërbimit nuk parashikon ndonjë logjikë biznesi. Algoritmet e llogaritjes së dëlty, parametrat e kërkesës, kontrolli i integritetit, etj., gjithashtu realizohen në anën e sistemit të jashtëm.
Ky mekanizëm lejon mbledhjen dhe transmetimin e të dhënave të nevojshme brenda disa orëve. Kjo shpejtësi ndodhet në kufijtë e pranueshëm, prandaj kjo zgjidhje shqyrtohet nga ne si një opsion të përkohshëm, që i ka mundësuar përmbushjen e nevojës për një mjet ekstraktimi në projekt.
Në pamjen e synuar për zgjidhjen e problemit të ekstraktimit të të dhënave, po shqyrtohen opsionet e përdorimit të sistemeve CDC si Oracle Golden Gate ose mjete ETL si SAP DS.
Burimi: habr.com
