Si është e njohur, kompania SAP ofron një gamë të plotë të softuerëve, 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) është një mjete për ruajtjen dhe analizimin e të dhënave, e cila ka mundësi të gjera teknike. Megjithë të gjitha avantazheve të saj objektive, sistemi SAP BW ka një disavantazh të rëndësishëm. Kjo është kostoja e lartë e ruajtjes dhe përpunimit të të dhënave, e cila është veçanërisht e dukshme gjatë përdorimit të SAP BW on Hana në re.
Po çfarë nëse të fillojmë të përdorim një produkt tjetër për ruajtje, ndoshta non-SAP dhe idealisht një produkt OpenSource? Ne në X5 Retail Group e kemi zgjedhur GreenPlum. Kjo sigurisht zgjidh problemin e kostos, por menjëherë lindin pyetje që me përdorimin e SAP BW zgjidhen praktikisht nga vetë default-i.
Veçanërisht, si do të marrim të dhënat nga sistemet burim, të cilat në shumicën e rasteve janë zgjidhje SAP?
«HR-metrikat» ishte projekti i parë në të cilin duhej të zgjidheshin këto probleme. Qëllimi ynë ishte krijimi i një depo të të dhënave HR dhe ndërtimi i raportimit analitik në lidhje me punën me punonjësit. Burimi kryesor i të dhënave është sistemi transaksional SAP HCM, i cili regjistron të gjitha aktivitetet e punës, 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 dhe të përcaktojnë delta të 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 nga ai për një punonjës:
Nëse është e nevojshme, ky ekstraktues mund të modifikohet sipas kërkesave të veta ose mund të krijohet një ekstraktues i vetë.
Ideja për ripërdorimin e tyre erdhi e para. Fatkeqësisht, kjo u dëshmua të ishte një detyrë e paarritshme. Shumica e logjikës është realizuar në anën e SAP BW, dhe nuk arritëm të ndanim pa dhembshuri ekstraktuesin në burim nga SAP BW.
Ka qenë e qartë se do të nevojitej zhvillimi i një mekanizmi 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ë se cilat të dhëna na nevojiten.
Shumica e të dhënave në SAP HCM ruhet në tabela SQL të sheshta. Bazuar në këto të dhëna, aplikacionet SAP vizualizojnë për përdoruesin strukturat organizative, punonjësit dhe informacione të tjera HR. Për shembull, ja si duket struktura organizative në SAP HCM:
Fizikisht, kjo pemĂ« ruhet nĂ« dy tabela â nĂ« hrp1000 objekti dhe nĂ« hrp1001 lidhjet midis kĂ«tyre objekteve.
Objektet "Departamenti 1" dhe "Menaxhimi 1":
Lidhja midis objekteve:
Ka shumë lloje objektesh si dhe lloje lidhjesh midis tyre. Ekzistojnë lidhje standarde midis objekteve dhe të personalizuara për nevojat specifike. Për shembull, lidhja standarde B012 midis një njësie organizative dhe një pozite të caktuar tregon për udhëheqësin e një nënshtetësie.
Paraqitja e udhëheqësit në SAP:
Ruajtja në tabelën e DB:
Të dhënat për punonjësit ruhen në tabela pa*. P.sh., të dhënat për ngjarjet kadrovike për punonjësin ruhen në tabelën pa0000.
Ne vendosëm që GreenPlum do të merret me të dhëna "të papërpunuara", pra do t'i kopjojë ato nga tabelat SAP. Dhe pastaj në GreenPlum do të përpunohen dhe konvertohen në objekte fizike (p.sh., Departamenti ose Punonjësi) dhe metrika (p.sh., numri mesatar i punonjësve).
U përcaktuan rreth 70 tabela, të dhënat nga të cilat duhet të dërgohen në GreenPlum. Më pas, ne filluam të punojmë mbi mënyrën e transferimit të këtyre të dhënave.
SAP ofron njĂ« numĂ«r tĂ« konsiderueshĂ«m mekanizmash integrimi. Por mĂ«nyra mĂ« e thjeshtĂ« â qasja direkte nĂ« bazĂ«n e tĂ« dhĂ«nave Ă«shtĂ« e ndaluar pĂ«r shkak tĂ« kufizimeve tĂ« licencĂ«s. KĂ«shtu, tĂ« gjitha fluxet e integrimit duhet tĂ« kenĂ« vendosje nĂ« nivelin serverit e aplikacioneve.
Problemi tjetër ishte mungesa e të dhënave për regjistrat e fshirë në DB SAP. Kur një rresht fshihet në DB, ai fshihet fizikisht. Pra, formimi i diferencës së ndryshimeve sipas kohës së ndryshimit nuk ishte i mundur.
Sigurisht, në SAP HCM ka mekanizma për regjistrimin e ndryshimeve të të dhënave. Për shembull, për transferimin në sistemet e marrësve, ekzistojnë tregues ndryshimesh (change pointer), të cilët regjistrojnë çdo ndryshim dhe në bazë të të cilëve formohen IDoc (objekti për transferim në sisteme të jashtme).
Shembulli i IDoc për ndryshimin e infotypes 0302 për punonjësin me numrin e regjistrimit 1251445:
Ose mbajtja e logjeve të ndryshimeve të të dhënave në tabelën DBTABLOG.
Shembulli i logut të fshirjes së një shenimi me çelësin QK53216375 nga tabela hrp1000:
Por këta mekanizma nuk janë të disponueshëm për të gjitha të dhënat e nevojshme dhe procesimi i tyre në nivelin e serverit të aplikacioneve mund të konsumojë shumë 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 serioz ishin tabelat klaster. Të dhënat e vlerësimeve të kohës dhe llogaritjes së pagës në versionin RDBMS të SAP HCM ruhen si një set tabelash logjike për secilin punonjës për çdo llogaritje. Këto tabela logjike ruhet në formën e të dhënave binare në tabelën pcl2.
Klasteri i llogaritjes së pagës:
TĂ« dhĂ«nat nga tabelat e grupeve nuk mund tĂ« lexohen me komandĂ«n SQL, prandaj kĂ«rkohet pĂ«rdorimi i makro-komandave SAP HCM ose moduleve funksionale speciale. Si rezultat, shpejtĂ«sia e leximit tĂ« kĂ«tyre tabelave do tĂ« jetĂ« mjaft e ulĂ«t. NĂ« anĂ«n tjetĂ«r, nĂ« kĂ«to grupe ruhet informacioni qĂ« nevojitet vetĂ«m njĂ« herĂ« nĂ« muaj â llogaritja pĂ«rfundimtare e pagĂ«s dhe vlerĂ«simi i kohĂ«s. Prandaj, shpejtĂ«sia nĂ« kĂ«tĂ« rast nuk Ă«shtĂ« aq kritike.
Duke vlerësimit të mundësive për krijimin e deltës së ndryshimit të të dhënave, vendosëm të shqyrtojmë edhe mundësinë e shkarkimit të plotë. Opsioni për të transferuar çdo ditë gigabajt të dhënash të pandryshueshme midis sistemeve nuk mund të duket tërheqës. Megjithatë, ai ka disa avantazhe - nuk është e nevojshme të implementohet delta në anën e burimit, as implementimi i integrimit të kësaj delte në anën e marrësit. Si rezultat, reduktohen kostot dhe afatet e realizimit, dhe rritet besueshmëria e integrimit. Megjithatë, u përcaktua se pothuajse të gjitha ndryshimet në SAP HR ndodhin në horizontin e tre muajve deri në datën aktuale. Prandaj, u mor vendimi për të mbetur me shkarkimin e plotë të të dhënave nga SAP HR çdo ditë për N muaj para datës aktuale dhe një shkarkim të plotë mujor. Parametri N varet nga tabela specifike.
dhe varion nga 1 në 15.
Për ekstraktimin e të dhënave u propozua skema e mëposhtme:
Sistemi i jashtëm krijon një kërkesë dhe e dërgon atë në SAP HCM, ku kjo kërkesë kontrollohet për plotësinë e të dhënave dhe për autorizimin për akses në tabela. Në rastin e verifikimit të suksesshëm, në SAP HCM ekzekutohet një program që mbledh të dhënat e nevojshme dhe i transmeton ato në zgjidhjen integruese Fuse. Fuse përcakton temën e nevojshme në Kafka dhe e dërgon atje. Më pas, të dhënat nga Kafka dërgohen në Stage Area GP.
Në këtë zinxhir na intereson çështja e nxjerrjes së të dhënave nga SAP HCM. Le të ndalojmë në këtë më shumë.
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.
Procesi mund të nisë nga një timer ose ngjarje tjetër, duke përfshirë gjithashtu mundësinë e vendosjes së një kohë pritjeje për përgjigjen me të dhëna nga SAP dhe iniciimin e një kërkese të përsëritur. Pas kësaj, formulohet një kërkesë për ndryshimin dhe dërgohet në SAP.
Të dhënat e kërkesës dërgohen në body në formatin json.
Metoda http: POST.
Shembulli i kërkesës:
Shërbimi SAP kryen kontrollin e kërkesës për plotësinë, përputhshmërinë me strukturën aktuale të SAP, dhe mungesën e autorizimit për akses në tabelën e kërkuar.
Në rast gabimesh, shërbimi kthen një përgjigje me kodin dhe përshkrimin përkatës. Në rast të një kontrolli të suksesshëm, krijon një proces në sfond për të formuar mostrën, gjeneron dhe kthen një id unik seance në mënyrë sinkrone.
Sistemi i jashtëm, në rast gabimi, e regjistron atë në regjistër. Në rast të një përgjigjeje të suksesshme, transmeton id e seancës dhe emrin e tabelës për të cilën është bërë kërkesa.
Sistemi i jashtëm regjistron seancën aktuale si të hapur. Nëse ka seanca të tjera për këtë tabelë, ato mbyllen me regjistrimin e një paralajmërimi në regjistër.
Detyra nĂ« sfond SAP formon njĂ« kursator sipas parametrave tĂ« caktuar dhe njĂ« paketĂ« tĂ« dhĂ«nash tĂ« madhĂ«sisĂ« sĂ« caktuar. MadhĂ«sia e paketĂ«s â numri maksimal i regjistrimeve qĂ« procesi lexon nga Baza e tĂ« DhĂ«nave. NĂ« parazgjedhje, ky numĂ«r merret si i barabartĂ« me 2000. NĂ«se nĂ« mostrĂ«n e Bazeve tĂ« DhĂ«nash ka mĂ« shumĂ« regjistrime sesa madhĂ«sia e paketĂ«s sĂ« pĂ«rdorur, 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 nĂ« mĂ«nyrĂ« strikt tĂ« rregullt.
Më pas, SAP dërgon paketën në shërbimin web të sistemit të jashtëm. Ky sistem kryen kontrollin e paketës së ardhur. Në sistem duhet të jetë regjistruar një seancë me id-në e marrë dhe duhet të jetë në status të hapur. Nëse numri i paketës është > 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ë ka një flamur final dhe serializimi ka përfunduar me sukses, njoftohet moduli i integrimit mbi përfundimin e suksesshëm të trajtimit të seancës dhe moduli përditëson statusin e seancës.
Në rast të një gabimi në kontrolle/parse, 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 ndalohet dërgimi i paketave.
PĂ«r kĂ«rkesat e tĂ« dhĂ«nave nga ana e SAP HCM Ă«shtĂ« realizuar njĂ« shĂ«rbim integrimi. ShĂ«rbimi Ă«shtĂ« realizuar mbi framework-un ICF (SAP Internet Communication Framework â ). Ai lejon mundĂ«si pĂ«r tĂ« kĂ«rkoni tĂ« dhĂ«na nga sistemi SAP HCM nga tabela tĂ« caktuara. Kur formohet kĂ«rkesa pĂ«r tĂ« dhĂ«na, ekziston mundĂ«sia pĂ«r tĂ« caktuar njĂ« listĂ« tĂ« fushave specifike dhe parametrave tĂ« filtrimit pĂ«r tĂ« marrĂ« tĂ« dhĂ«nat e nevojshme. SidoqoftĂ«, realizimi i shĂ«rbimit nuk parashikon asnjĂ« logjikĂ« biznesi. Algoritmet e llogaritjes sĂ« deltas, parametrave tĂ« kĂ«rkesĂ«s, kontrollit tĂ« integritetit, etj. gjithashtu realizohen nĂ« anĂ«n e sistemit tĂ« jashtĂ«m.
Ky mekanizëm lejon grumbullimin dhe transmetimin e të gjitha të dhënave të nevojshme brenda disa orësh. Kjo shpejtësi është në kufirin e pranueshëm, prandaj ky zgjidhje konsiderohet nga ne si e përkohshme, e cila ka lejuar mbylljen e nevojës për një mjet nxjerrjeje në projekt.
Në vizionin synues për zgjidhjen e detyrës së nxjerrjes së të dhënave, po shqyrtohen opsionet e përdorimit të sistemeve CDC si Oracle Golden Gate ose mjeteve ETL si SAP DS.
Burimi: habr.com
