Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Kā zināms, SAP piedāvā pilnu programmatÅ«ras klāstu gan darÄ«jumu datu uzturÄ“Å”anai, gan Å”o datu apstrādei analÄ«zes un atskaiÅ”u sistēmās. Konkrēti, SAP Business Warehouse (SAP BW) platforma ir rÄ«ku komplekts datu glabāŔanai un analÄ«zei ar plaŔām tehniskām iespējām. Neskatoties uz visām objektÄ«vajām priekÅ”rocÄ«bām, SAP BW sistēmai ir viens bÅ«tisks trÅ«kums. Tās ir augstas datu glabāŔanas un apstrādes izmaksas, kas ir Ä«paÅ”i pamanāmas, ja vietnē Hana izmantojat mākoņa bāzes SAP BW.

Ko darÄ«t, ja kā krātuvi sākat izmantot kādu, kas nav SAP, un, vēlams, atvērtā koda produktu? Mēs, X5 Retail Group, izvēlējāmies GreenPlum. Tas, protams, atrisina izmaksu jautājumu, taču tajā paŔā laikā uzreiz rodas problēmas, kuras tika atrisinātas gandrÄ«z pēc noklusējuma, izmantojot SAP BW.

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Konkrēti, kā izgūt datus no avota sistēmām, kas galvenokārt ir SAP risinājumi?

HR Metrics bija pirmais projekts, kurā bija nepiecieÅ”ams atrisināt Å”o problēmu. MÅ«su mērÄ·is bija izveidot HR datu repozitoriju un veidot analÄ«tiskos pārskatus darba ar darbiniekiem jomā. Å ajā gadÄ«jumā galvenais datu avots ir SAP HCM darÄ«jumu sistēma, kurā tiek veiktas visas personāla, organizatoriskās un algu darbÄ«bas.

Datu ieguve

SAP BW ir standarta datu ekstraktori SAP sistēmām. Å ie ekstraktori var automātiski savākt nepiecieÅ”amos datus, uzraudzÄ«t to integritāti un noteikt izmaiņu deltas. Å eit, piemēram, ir standarta datu avots darbinieku atribÅ«tiem 0EMPLOYEE_ATTR:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Viena darbinieka datu iegūŔanas rezultāts no tā:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Ja nepiecieÅ”ams, Ŕādu nosÅ«cēju var pārveidot atbilstoÅ”i savām prasÄ«bām vai izveidot savu nosÅ«cēju.

Pirmā ideja, kas radās, bija iespēja tos izmantot atkārtoti. Diemžēl tas izrādījās neiespējams uzdevums. Lielākā daļa loģikas ir ieviesta SAP BW pusē, un nebija iespējams nesāpīgi atdalīt nosūcēju avotā no SAP BW.

Kļuva skaidrs, ka mums bÅ«s jāizstrādā savs mehānisms datu iegÅ«Å”anai no SAP sistēmām.

Datu uzglabāŔanas struktūra SAP HCM

Lai saprastu prasības Ŕādam mehānismam, mums vispirms ir jānosaka, kādi dati mums ir nepiecieŔami.

Lielākā daļa datu SAP HCM tiek glabāti plakanās SQL tabulās. Pamatojoties uz Å”iem datiem, SAP lietojumprogrammas lietotājam vizualizē organizatoriskās struktÅ«ras, darbiniekus un citu personāla informāciju. Piemēram, Ŕādi izskatās organizatoriskā struktÅ«ra SAP HCM:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Fiziski Ŕāds koks tiek glabāts divās tabulās - hrp1000 objektos un hrp1001 savienojumi starp Ŕiem objektiem.

Objekti ā€œ1. nodaļaā€ un ā€œ1. birojsā€:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Attiecības starp objektiem:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Var bÅ«t ļoti daudz abu veidu objektu un savienojumu veidu starp tiem. Ir gan standarta savienojumi starp objektiem, gan pielāgoti jÅ«su Ä«paÅ”ajām vajadzÄ«bām. Piemēram, standarta B012 attiecÄ«bas starp organizācijas struktÅ«rvienÄ«bu un pilnas slodzes amatu norāda nodaļas vadÄ«tāju.

Pārziņa displejs SAP:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

UzglabāŔana datu bāzes tabulā:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Darbinieku dati tiek glabāti pa* tabulās. Piemēram, dati par personāla notikumiem darbiniekam tiek glabāti tabulā pa0000

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Nolēmām, ka GreenPlum ņems ā€œneapstrādātusā€ datus, t.i. vienkārÅ”i nokopējiet tos no SAP tabulām. Un tieÅ”i GreenPlum tie tiks apstrādāti un pārvērsti fiziskos objektos (piemēram, departamentā vai darbiniekā) un metrikā (piemēram, vidējais darbinieku skaits).

Tika definētas aptuveni 70 tabulas, no kurām dati jāpārsÅ«ta uz GreenPlum. Pēc tam mēs sākām izstrādāt metodi Å”o datu pārsÅ«tÄ«Å”anai.

SAP piedāvā diezgan lielu skaitu integrācijas mehānismu. Bet vienkārŔākais veids ir, ka tieÅ”a piekļuve datubāzei ir aizliegta licencÄ“Å”anas ierobežojumu dēļ. Tādējādi visas integrācijas plÅ«smas ir jāievieÅ” lietojumprogrammu servera lÄ«menÄ«.
Nākamā problēma bija datu trÅ«kums par dzēstiem ierakstiem SAP datu bāzē. DzÄ“Å”ot rindu datubāzē, tā tiek fiziski izdzēsta. Tie. pārmaiņu deltas veidoÅ”anās, pamatojoties uz pārmaiņu laiku, nebija iespējama.

Protams, SAP HCM ir datu izmaiņu reÄ£istrÄ“Å”anas mehānismi. Piemēram, turpmākai pārsÅ«tÄ«Å”anai uz adresātu sistēmām ir izmaiņu norādes, kas fiksē visas izmaiņas un uz kuru pamata tiek veidots Idoc (objekts pārsÅ«tÄ«Å”anai uz ārējām sistēmām).

IDoc piemērs informācijas tipa 0302 maiņai darbiniekam ar personāla numuru 1251445:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Vai datu izmaiņu žurnālu saglabāŔana tabulā DBTABLOG.

Žurnāla piemērs ieraksta dzÄ“Å”anai ar atslēgu QK53216375 no tabulas hrp1000:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Bet Å”ie mehānismi nav pieejami visiem nepiecieÅ”amajiem datiem, un to apstrāde lietojumprogrammu servera lÄ«menÄ« var patērēt diezgan daudz resursu. Tāpēc masveida reÄ£istrÄ“Å”anas iespējoÅ”ana visās nepiecieÅ”amajās tabulās var izraisÄ«t ievērojamu sistēmas veiktspējas pasliktināŔanos.

Nākamā galvenā problēma bija klasteru tabulas. Laika aprēķinu un algu dati SAP HCM RDBMS versijā tiek glabāti kā loģisku tabulu kopa katram darbiniekam katram aprēķinam. Šīs loģiskās tabulas tiek saglabātas kā binārie dati tabulā pcl2.

Algu kopa:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Datus no klasterizētām tabulām nevar uzskatÄ«t par SQL komandu, bet tiem ir jāizmanto SAP HCM makro vai Ä«paÅ”i funkciju moduļi. AttiecÄ«gi Ŕādu tabulu lasÄ«Å”anas ātrums bÅ«s diezgan zems. Savukārt Ŕādos klasteros tiek glabāti dati, kas nepiecieÅ”ami tikai reizi mēnesÄ« ā€“ galÄ«gais algu un laika aprēķins. Tātad ātrums Å”ajā gadÄ«jumā nav tik kritisks.

Izvērtējot datu izmaiņu delta veidoÅ”anas iespējas, nolēmām apsvērt arÄ« pilnas izkrauÅ”anas iespēju. Iespēja katru dienu pārsÅ«tÄ«t gigabaitus nemainÄ«tu datu starp sistēmām var neizskatÄ«ties labi. Tomēr tam ir arÄ« vairākas priekÅ”rocÄ«bas - nav nepiecieÅ”ams gan ieviest delta avota pusē, gan Ä«stenot Ŕīs delta iegulÅ”anu uztvērēja pusē. AttiecÄ«gi tiek samazinātas izmaksas un ievieÅ”anas laiks, kā arÄ« palielinās integrācijas uzticamÄ«ba. Vienlaikus tika noteikts, ka gandrÄ«z visas SAP HR izmaiņas notiek trÄ«s mēneÅ”u laikā pirms paÅ”reizējā datuma. Tādējādi tika nolemts izvēlēties ikdienas pilnu datu lejupielādi no SAP HR N mēneÅ”us pirms paÅ”reizējā datuma un ikmēneÅ”a pilnu lejupielādi. N parametrs ir atkarÄ«gs no konkrētās tabulas
un svārstās no 1 līdz 15.

Datu ieguvei tika piedāvāta Ŕāda shēma:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Ārējā sistēma Ä£enerē pieprasÄ«jumu un nosÅ«ta to SAP HCM, kur Å”is pieprasÄ«jums tiek pārbaudÄ«ts attiecÄ«bā uz datu pilnÄ«gumu un atļaujām piekļūt tabulām. Ja pārbaude ir veiksmÄ«ga, SAP HCM palaiž programmu, kas apkopo nepiecieÅ”amos datus un pārsÅ«ta tos uz Fuse integrācijas risinājumu. Fuse nosaka nepiecieÅ”amo tēmu Kafkā un pārsÅ«ta datus uz turieni. Pēc tam Kafkas dati tiek pārsÅ«tÄ«ti uz Stage Area GP.

Šajā ķēdē mūs interesē jautājums par datu ieguvi no SAP HCM. Apskatīsim to sīkāk.

SAP HCM-FUSE mijiedarbības diagramma.

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

Ārējā sistēma nosaka pēdējā veiksmīgā pieprasījuma laiku SAP.
Procesu var palaist taimeris vai cits notikums, tostarp iestatīt taimautu, lai gaidītu atbildi ar datiem no SAP un sāktu atkārtotu pieprasījumu. Pēc tam tas ģenerē delta pieprasījumu un nosūta to SAP.

Pieprasījuma dati tiek nosūtīti pamattekstam json formātā.
Metode http: POST.
Pieprasījuma piemērs:

Datu ieguve no SAP HCM uz ne-SAP datu noliktavām

SAP pakalpojums uzrauga pieprasÄ«jumu pilnÄ«gumu, atbilstÄ«bu paÅ”reizējai SAP struktÅ«rai un piekļuves atļaujas pieejamÄ«bu pieprasÄ«tajai tabulai.

Kļūdu gadÄ«jumā pakalpojums atgriež atbildi ar atbilstoÅ”u kodu un aprakstu. Ja vadÄ«ba ir veiksmÄ«ga, tā izveido fona procesu, lai Ä£enerētu paraugu, Ä£enerē un sinhroni atgriež unikālu sesijas ID.

Kļūdas gadījumā ārējā sistēma to ieraksta žurnālā. Veiksmīgas atbildes gadījumā tas nosūta sesijas ID un tās tabulas nosaukumu, kurai tika veikts pieprasījums.

Ārējā sistēma reÄ£istrē paÅ”reizējo sesiju kā atvērtu. Ja Å”ai tabulai ir citas sesijas, tās tiek aizvērtas ar reÄ£istrētu brÄ«dinājumu.

SAP fona darbs Ä£enerē kursoru, pamatojoties uz norādÄ«tajiem parametriem un norādÄ«tā izmēra datu paketi. Partijas lielums ir maksimālais ierakstu skaits, ko process nolasa no datu bāzes. Pēc noklusējuma tiek pieņemts, ka tas ir vienāds ar 2000. Ja datu bāzes izlasē ir vairāk ierakstu nekā izmantotais paketes lielums, pēc pirmās paketes pārsÅ«tÄ«Å”anas tiek veidots nākamais bloks ar atbilstoÅ”o nobÄ«di un palielināto paketes numuru. Skaitļi tiek palielināti par 1 un tiek nosÅ«tÄ«ti stingri secÄ«gi.

Pēc tam SAP nodod paketi kā ievadi ārējās sistēmas tÄ«mekļa pakalpojumam. Un sistēma kontrolē ienākoÅ”o paketi. Sesija ar saņemto id ir jāreÄ£istrē sistēmā un tai jābÅ«t atvērtā statusā. Ja pakas numurs ir > 1, sistēmai jāreÄ£istrē veiksmÄ«ga iepriekŔējās pakas saņemÅ”ana (package_id-1).

Ja vadība ir veiksmīga, ārējā sistēma parsē un saglabā tabulas datus.

Turklāt, ja pakotnē ir pēdējais karodziņŔ un serializācija bija veiksmÄ«ga, integrācijas modulis tiek informēts par veiksmÄ«gu sesijas apstrādes pabeigÅ”anu un modulis atjaunina sesijas statusu.

VadÄ«bas/parsÄ“Å”anas kļūdas gadÄ«jumā kļūda tiek reÄ£istrēta, un ārējā sistēma noraidÄ«s Ŕīs sesijas paketes.

Tāpat pretējā gadÄ«jumā, kad ārējā sistēma atgriež kļūdu, tā tiek reÄ£istrēta un pakeÅ”u pārraide apstājas.

Lai pieprasÄ«tu datus SAP HŠ”M pusē, tika ieviests integrācijas pakalpojums. Pakalpojums ir ieviests uz ICF ietvara (SAP Internet Communication Framework - help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html). Tas ļauj vaicāt datus no SAP HCM sistēmas, izmantojot Ä«paÅ”as tabulas. Veidojot datu pieprasÄ«jumu, ir iespējams norādÄ«t konkrētu lauku sarakstu un filtrÄ“Å”anas parametrus, lai iegÅ«tu nepiecieÅ”amos datus. Tajā paŔā laikā pakalpojuma ievieÅ”ana neietver nekādu biznesa loÄ£iku. Ārējās sistēmas pusē ir ieviesti arÄ« algoritmi delta aprēķināŔanai, vaicājuma parametriem, integritātes uzraudzÄ«bai utt.

Å is mehānisms ļauj apkopot un pārsÅ«tÄ«t visus nepiecieÅ”amos datus dažu stundu laikā. Å is ātrums ir uz pieņemama robežas, tāpēc mēs uzskatām Å”o risinājumu par pagaidu risinājumu, kas ļāva aizpildÄ«t vajadzÄ«bu pēc ieguves rÄ«ka projektā.
Mērķa attēlā, lai atrisinātu datu ieguves problēmu, tiek pētītas iespējas izmantot CDC sistēmas, piemēram, Oracle Golden Gate vai ETL rīkus, piemēram, SAP DS.

Avots: www.habr.com

Pievieno komentāru