Dakizuenez, SAPek software sorta osoa eskaintzen du bai transakzio-datuak mantentzeko, bai datu horiek analisi- eta txosten-sistemetan prozesatzeko. Bereziki, SAP Business Warehouse (SAP BW) plataforma gaitasun tekniko zabalak dituen datuak gordetzeko eta aztertzeko tresna-kit bat da. Bere abantaila objektibo guztiengatik, SAP BW sistemak eragozpen nabarmen bat du. Datuak gordetzeko eta prozesatzeko kostu handia da, batez ere Hana-n hodeian oinarritutako SAP BW erabiltzean.
Zer gertatzen da biltegiratze gisa SAP ez den eta hobe OpenSource produktu bat erabiltzen hasten bazara? X5 Retail Group-en GreenPlum aukeratu dugu. Horrek, noski, kostuaren arazoa konpontzen du, baina, aldi berean, SAP BW erabiltzean ia lehenespenez konpondu ziren arazoak berehala sortzen dira.
Bereziki, nola berreskuratu iturburu-sistemetatik datuak, gehienbat SAP irtenbideak?
HR Metrics izan zen arazo hori konpontzeko beharrezkoa izan zen lehen proiektua. Gure helburua HR datuen biltegi bat sortzea eta langileekin lan egiteko alorrean txosten analitikoak sortzea zen. Kasu honetan, datu-iturri nagusia SAP HCM transakzio-sistema da, non langile, antolakuntza eta soldata jarduera guztiak egiten diren.
Datuak ateratzea
SAP BW-n SAP sistemetarako datu-erauzketa estandarrak daude. Erauzgailu hauek automatikoki bil ditzakete beharrezko datuak, haren osotasuna kontrolatu eta aldaketa-deltak zehaztu. Hona hemen, adibidez, 0EMPLOYEE_ATTR langile-atributuen datu-iturburu estandarra:
Langile bati bertatik datuak ateratzearen emaitza:
Beharrezkoa izanez gero, erauzitzaile hori alda daiteke zure beharretara egokitzeko edo zure erauzgailua sor daiteke.
Sortu zen lehen ideia horiek berrerabiltzeko aukera izan zen. Zoritxarrez, ezinezkoa izan zen zeregin hori. Logika gehiena SAP BW aldean inplementatuta dago, eta ezin izan zen erauzgailua jatorrian SAP BWtik minez bereizi.
Argi geratu zen SAP sistemetatik datuak ateratzeko gure mekanismo propioa garatu beharko genuela.
Datuak gordetzeko egitura SAP HCMn
Mekanismo horren baldintzak ulertzeko, lehenik eta behin zer datu behar ditugun zehaztu behar dugu.
SAP HCM-ko datu gehienak SQL taula lauetan gordetzen dira. Datu horietan oinarrituta, SAP aplikazioek antolakuntza-egiturak, langileak eta beste HR informazioa erakusten diote erabiltzaileari. Adibidez, hau da SAP HCM-n antolakuntza-egituraren itxura:
Fisikoki, zuhaitz hori bi tauletan gordetzen da: hrp1000 objektuetan eta hrp1001 objektu horien arteko konexioak.
"1. Saila" eta "1. Bulegoa" objektuak:
Objektuen arteko erlazioa:
Bi objektu mota eta haien arteko konexio mota ugari egon daitezke. Objektuen arteko konexio estandarrak eta zure behar zehatzetarako pertsonalizatuak daude. Adibidez, erakunde-unitate baten eta lanaldi osoko lanpostu baten arteko B012 harreman estandarrak sail bateko burua adierazten du.
Kudeatzailea SAPen bistaratzea:
Biltegiratzea datu-baseko taula batean:
Langileen datuak pa* tauletan gordetzen dira. Adibidez, langile baten gertaeren inguruko datuak pa0000 taulan gordetzen dira
GreenPlum-ek datu "gordinak" hartuko dituela erabaki genuen, hau da. kopiatu besterik ez dago SAP tauletatik. Eta zuzenean GreenPlum-en prozesatu eta objektu fisikoetan (adibidez, Saila edo Langilea) eta metrika (adibidez, batez besteko langile kopurua) bihurtuko dira.
70 taula inguru definitu ziren, eta horietatik datuak GreenPlum-era transferitu behar dira. Horren ostean datu hauek transmititzeko metodo bat lantzen hasi ginen.
SAPek integrazio-mekanismo kopuru nahiko handia eskaintzen du. Baina modurik errazena datu-baserako sarbide zuzena debekatuta egotea da lizentzien murrizketen ondorioz. Horrela, integrazio-fluxu guztiak aplikazio-zerbitzari mailan ezarri behar dira.
Hurrengo arazoa SAP datu-basean ezabatutako erregistroei buruzko datu falta izan zen. Datu-baseko errenkada bat ezabatzen duzunean, fisikoki ezabatzen da. Horiek. aldaketa-denboran oinarritutako aldaketa-delta eratzea ezin izan zen.
Jakina, SAP HCM-k datuen aldaketak erregistratzeko mekanismoak ditu. Esaterako, ondorengo sistema hartzaileetara transferitzeko, aldaketak erregistratzen dituzten eta horren oinarrian Idoc bat (kanpo sistemetara transferitzeko objektua) eratzen duten aldaketa-erakusleak daude.
0302 langile-zenbakia duen langile baten 1251445 infotipoa aldatzeko IDoc adibidea:
Edo datu-aldaketen erregistroak DBTABLOG taulan gordetzea.
hrp53216375 taulako QK1000 gakoarekin erregistro bat ezabatzeko erregistro baten adibidea:
Baina mekanismo hauek ez daude eskuragarri beharrezko datu guztietarako, eta aplikazio-zerbitzari mailan prozesatzeak baliabide asko kontsumi ditzake. Hori dela eta, beharrezkoak diren taula guztietan saio-saioa masiboki gaitzeak sistemaren errendimenduaren hondatze nabarmena ekar dezake.
Hurrengo arazo nagusia taula multzokatuak izan ziren. SAP HCM-ren RDBMS bertsioko denbora-kalkulua eta nomina-datuak kalkulu bakoitzeko langile bakoitzaren taula logikoen multzo gisa gordetzen dira. Taula logiko hauek datu bitar gisa gordetzen dira pcl2 taulan.
Soldata multzoa:
Klusteratutako tauletako datuak ezin dira SQL komando gisa hartu, baina SAP HCM makroak edo funtzio modulu bereziak erabiltzea eskatzen dute. Horren arabera, horrelako taulen irakurketa-abiadura nahiko baxua izango da. Bestalde, horrelako klusterrek hilean behin bakarrik behar diren datuak gordetzen dituzte: azken nominak eta denboraren estimazioa. Beraz, kasu honetan abiadura ez da hain kritikoa.
Datuen aldaketen delta bat osatzeko aukerak ebaluatuz, erabateko deskargaren aukera ere kontuan hartzea erabaki genuen. Aldaketarik gabeko datuen gigabyte sistemaren artean egunero transferitzeko aukerak agian ez du itxura ona. Hala ere, abantaila ugari ere baditu: ez dago delta iturburu aldean ezartzea eta hartzailearen aldean delta txertatzea ezartzea. Horren arabera, kostua eta ezarpen-denbora murrizten dira, eta integrazioaren fidagarritasuna handitzen da. Aldi berean, SAP HR-n ia aldaketa guztiak uneko data baino hiru hilabeteko horizonte batean gertatzen direla zehaztu zen. Hala, uneko data baino N hilabete lehenago SAP HR-tik datuen deskarga osoa eta hilero deskarga osoa aukeratzea erabaki zen. N parametroa taula zehatzaren araberakoa da
eta 1etik 15era bitartekoa da.
Datuak ateratzeko eskema hau proposatu zen:
Kanpoko sistemak eskaera bat sortzen du eta SAP HCMra bidaltzen du, non eskaera hori egiaztatzen den datuen eta tauletan sartzeko baimenen osotasuna. Egiaztapena arrakastatsua bada, SAP HCM-k beharrezko datuak bildu eta Fuse integrazio soluziora transferitzen dituen programa bat exekutatzen du. Fuse-k behar den gaia zehazten du Kafkan-en eta hara transferitzen ditu datuak. Ondoren, Kafkaren datuak Stage Area GPra transferitzen dira.
Kate honetan, SAP HCMtik datuak ateratzearen gaia interesatzen zaigu. Ikus dezagun zehatzago.
SAP HCM-FUSE elkarrekintza diagrama.
Kanpoko sistemak SAP-i egindako azken eskaera arrakastatsuaren ordua zehazten du.
Prozesua tenporizadore batek edo beste gertaera batek abiarazi dezake, denbora-muga ezarriz SAP-en datuekin erantzuna itxaron eta eskaera errepikatu bat abiarazteko barne. Ondoren, delta eskaera bat sortzen du eta SAPera bidaltzen du.
Eskaeraren datuak gorputzera bidaltzen dira json formatuan.
Metodoa http: POST.
Eskaera adibidea:
SAP zerbitzuak osotasuna, egungo SAP egitura betetzen den eta eskatutako taularako sarbide-baimenaren erabilgarritasuna kontrolatzen ditu.
Akatsen kasuan, zerbitzuak erantzun bat itzultzen du dagokion kodea eta deskribapenarekin. Kontrola arrakastatsua bada, atzeko planoko prozesu bat sortzen du lagin bat sortzeko, saio-id bakarra sortu eta sinkronoki itzultzen du.
Errore bat gertatuz gero, kanpoko sistemak erregistroan erregistratzen du. Erantzun arrakastatsua izanez gero, saioaren IDa eta eskaera egin den taularen izena transmititzen ditu.
Kanpoko sistemak uneko saioa irekita erregistratzen du. Taula honetarako beste saio batzuk badaude, abisu batekin itxiko dira.
SAP atzeko planoko lanak zehaztutako parametroetan eta zehaztutako tamainako datu-pakete batean oinarritutako kurtsorea sortzen du. Lotaren tamaina prozesu batek datu-basetik irakurtzen duen erregistro kopurua da. Lehenespenez, 2000-ren berdina dela suposatzen da. Datu-basean erabilitako pakete-tamaina baino erregistro gehiago badaude, lehenengo paketea transmititu ondoren, hurrengo blokea osatuko da dagokion desplazamendu eta pakete-zenbaki handituarekin. Zenbakiak 1 handitzen dira eta zorrozki sekuentzialki bidaltzen dira.
Ondoren, SAPek paketea sarrera gisa pasatzen dio kanpoko sistemaren web-zerbitzuari. Eta sistemak kontrolak egiten ditu sarrerako paketeari. Jasotako id-a duen saio bat sisteman erregistratu behar da eta irekita egon behar du. Pakete-zenbakia > 1 bada, sistemak aurreko paketearen ongi jaso izana erregistratu beharko luke (package_id-1).
Kontrola arrakastatsua bada, kanpoko sistemak taulako datuak analizatu eta gordetzen ditu.
Gainera, azken marka paketean badago eta serializazioa arrakastatsua izan bada, integrazio-moduluari saioaren prozesamendua ondo amaitu dela jakinaraziko zaio eta moduluak saioaren egoera eguneratzen du.
Kontrol/analisi akatsen bat izanez gero, errorea erregistratzen da eta saio honetako paketeak baztertuko ditu kanpoko sistemak.
Era berean, kontrako kasuan, kanpoko sistemak errore bat itzultzen duenean, erregistratzen da eta paketeen transmisioa gelditzen da.
SAP HΠ‘M aldean datuak eskatzeko, integrazio zerbitzu bat ezarri zen. Zerbitzua ICF esparruan ezartzen da (SAP Internet Communication Framework - ). SAP HCM sistemako datuak kontsultatzeko aukera ematen du taula zehatzak erabiliz. Datu-eskaera bat sortzean, eremu zehatzen eta iragazteko parametroen zerrenda zehaztea posible da beharrezko datuak lortzeko. Aldi berean, zerbitzua ezartzeak ez du inolako negozio logikarik suposatzen. Delta kalkulatzeko algoritmoak, kontsulta-parametroak, osotasunaren jarraipena eta abar ere ezartzen dira kanpoko sistemaren aldean.
Mekanismo honek ordu gutxitan beharrezko datu guztiak biltzeko eta transmititzeko aukera ematen du. Abiadura hori onartzeko zorian dago, beraz, irtenbide hau behin-behinekotzat jotzen dugu, proiektuan erauzketa tresna baten beharra betetzea ahalbidetu zuena.
Helburuko irudian, datuak erauzteko arazoa konpontzeko, Oracle Golden Gate bezalako CDC sistemak edo SAP DS bezalako ETL tresnak erabiltzeko aukerak aztertzen ari dira.
Iturria: www.habr.com