Kiel vi scias, SAP ofertas plenan gamon da programaro kaj por konservi transakciajn datumojn kaj por prilabori ĉi tiujn datumojn en analizaj kaj raportaj sistemoj. Aparte, la platformo SAP Business Warehouse (SAP BW) estas ilaro por stoki kaj analizi datumojn kun ampleksaj teknikaj kapabloj. Por ĉiuj ĝiaj objektivaj avantaĝoj, la SAP BW-sistemo havas unu gravan malavantaĝon. Ĉi tio estas alta kosto de stokado kaj prilaborado de datumoj, precipe videbla kiam oni uzas SAP BW-bazitan en nubo ĉe Hana.
Kio se vi komencas uzi iun ne-SAP kaj prefere OpenSource-produkton kiel stokado? Ni ĉe X5 Retail Group elektis GreenPlum. Ĉi tio, kompreneble, solvas la problemon de kosto, sed samtempe tuj aperas problemoj, kiuj preskaŭ defaŭlte estis solvitaj kiam oni uzas SAP BW.
Aparte, kiel retrovi datumojn de fontsistemoj, kiuj estas plejparte SAP-solvoj?
HR Metrics estis la unua projekto en kiu necesis solvi ĉi tiun problemon. Nia celo estis krei deponejon de HR-datumoj kaj konstrui analizajn raportojn en la areo de laboro kun dungitoj. En ĉi tiu kazo, la ĉefa fonto de datumoj estas la transakcia sistemo SAP HCM, en kiu ĉiuj personaj, organizaj kaj salajraj agadoj estas efektivigitaj.
Eltiro de datumoj
En SAP BW ekzistas normaj daten-ekstraktiloj por SAP-sistemoj. Ĉi tiuj ĉerpiloj povas aŭtomate kolekti la necesajn datumojn, kontroli ĝian integrecon kaj determini ŝanĝajn deltojn. Jen, ekzemple, la norma datumfonto por dungitaj atributoj 0EMPLOYEE_ATTR:
La rezulto de eltiro de datumoj de ĝi por unu dungito:
Se necese, tia eltilo povas esti modifita laŭ viaj propraj postuloj aŭ via propra eltilo povas esti kreita.
La unua ideo estiĝinta estis la ebleco reuzi ilin. Bedaŭrinde, ĉi tio montriĝis neebla tasko. La plej granda parto de la logiko estas efektivigita sur la SAP BW-flanko, kaj ne eblis sendolore apartigi la eltirilon ĉe la fonto de SAP BW.
Evidentiĝis, ke ni bezonus evoluigi nian propran mekanismon por ĉerpi datumojn el SAP-sistemoj.
Datumstoka strukturo en SAP HCM
Por kompreni la postulojn por tia mekanismo, ni unue devas determini kiajn datumojn ni bezonas.
Plej multaj datumoj en SAP HCM estas konservitaj en plataj SQL-tabeloj. Surbaze de ĉi tiuj datumoj, SAP-aplikoj bildigas organizajn strukturojn, dungitojn kaj aliajn HR-informojn al la uzanto. Ekzemple, jen kiel aspektas la organiza strukturo en SAP HCM:
Fizike, tia arbo estas konservita en du tabeloj - en hrp1000 objektoj kaj en hrp1001 la ligoj inter tiuj objektoj.
Objektoj "Departemento 1" kaj "Oficejo 1":
Rilato inter objektoj:
Povas ekzisti grandega nombro da ambaŭ specoj de objektoj kaj specoj de ligoj inter ili. Estas ambaŭ normaj ligoj inter objektoj kaj personecigitaj por viaj propraj specifaj bezonoj. Ekzemple, la norma B012-rilato inter organiza unuo kaj plentempa pozicio indikas la estron de fako.
Manaĝera ekrano en SAP:
Stokado en datumbaza tabelo:
Datenoj de dungitoj estas konservitaj en tabeloj de pa*. Ekzemple, datumoj pri personarokazaĵoj por dungito estas konservitaj en tabelo pa0000
Ni decidis, ke GreenPlum prenos "krudajn" datumojn, t.e. simple kopiu ilin el SAP-tabeloj. Kaj rekte en GreenPlum ili estos prilaboritaj kaj konvertitaj en fizikajn objektojn (ekzemple, Fako aŭ Dungito) kaj metrikojn (ekzemple, averaĝa nombro).
Ĉirkaŭ 70 tabeloj estis difinitaj, datumoj de kiuj devas esti transdonitaj al GreenPlum. Post tio ni komencis ellabori metodon por transdoni ĉi tiujn datumojn.
SAP ofertas sufiĉe grandan nombron da integrigaj mekanismoj. Sed la plej facila maniero estas, ke rekta aliro al la datumbazo estas malpermesita pro licencaj limigoj. Tiel, ĉiuj integriĝfluoj devas esti efektivigitaj sur la aplikaĵservila nivelo.
La sekva problemo estis la manko de datumoj pri forigitaj rekordoj en la datumbazo de SAP. Kiam vi forigas vicon en la datumbazo, ĝi estas fizike forigita. Tiuj. la formado de ŝanĝdelto bazita sur la tempo de ŝanĝo ne estis ebla.
Kompreneble, SAP HCM havas mekanismojn por registri datumajn ŝanĝojn. Ekzemple, por posta translokigo al ricevantaj sistemoj, ekzistas ŝanĝmontriloj kiuj registras ajnajn ŝanĝojn kaj surbaze de kiuj estas formita Idoc (objekto por translokigo al eksteraj sistemoj).
Ekzemplo IDoc por ŝanĝi infotipo 0302 por dungito kun personara numero 1251445:
Aŭ konservante protokolojn de datenŝanĝoj en la DBTABLOG-tabelo.
Ekzemplo de protokolo por forigi rekordon per la ŝlosilo QK53216375 de la hrp1000-tabelo:
Sed ĉi tiuj mekanismoj ne disponeblas por ĉiuj necesaj datumoj, kaj ilia prilaborado ĉe la aplika servilo povas konsumi sufiĉe multajn rimedojn. Sekve, amase ebligi ensalutadon sur ĉiuj necesaj tabloj povas konduki al rimarkinda degenero de sistema rendimento.
La sekva grava problemo estis amasigitaj tabloj. Tempotakso kaj salajro-datumoj en la RDBMS-versio de SAP HCM estas stokitaj kiel aro de logikaj tabeloj por ĉiu dungito por ĉiu kalkulo. Ĉi tiuj logikaj tabeloj estas konservitaj kiel binaraj datumoj en tabelo pcl2.
Salajrogrupo:
Datenoj de amasigitaj tabloj ne povas esti konsiderataj kiel SQL-komando, sed postulas la uzon de SAP HCM-makrooj aŭ specialaj funkciomoduloj. Sekve, la legado de tiaj tabeloj estos sufiĉe malalta. Aliflanke, tiaj aretoj stokas datumojn, kiuj estas bezonataj nur unufoje monate - fina etato kaj tempa takso. Do rapideco en ĉi tiu kazo ne estas tiel kritika.
Taksante eblojn por formi delton de datumaj ŝanĝoj, ni decidis ankaŭ konsideri la opcion de plena malŝarĝo. La eblo transdoni gigabajtojn da senŝanĝaj datumoj inter sistemoj ĉiutage eble ne aspektas bone. Tamen ĝi ankaŭ havas kelkajn avantaĝojn - ne necesas ambaŭ efektivigi la delton ĉe la fonta flanko kaj efektivigi la enkonstruadon de ĉi tiu delto ĉe la ricevilo. Sekve, la kosto kaj efektiviga tempo estas reduktitaj, kaj la fidindeco de integriĝo pliiĝas. Samtempe, estis determinite, ke preskaŭ ĉiuj ŝanĝoj en SAP HR okazas ene de horizonto de tri monatoj antaŭ la nuna dato. Tiel, oni decidis elekti ĉiutagan plenan elŝuton de datumoj de SAP HR N monatojn antaŭ la aktuala dato kaj ĉiumonatan plenan elŝuton. La N parametro dependas de la specifa tabelo
kaj varias de 1 ĝis 15.
La sekva skemo estis proponita por datenekstraktado:
La ekstera sistemo generas peton kaj sendas ĝin al SAP HCM, kie ĉi tiu peto estas kontrolita por kompleteco de datumoj kaj permesoj aliri tabelojn. Se la kontrolo sukcesas, SAP HCM funkcias programon, kiu kolektas la necesajn datumojn kaj transdonas ĝin al la integriga solvo de Fuse. Fuse determinas la postulatan temon en Kafka kaj transdonas la datumojn tien. Poste, la datumoj de Kafka estas transdonitaj al Stage Area GP.
En ĉi tiu ĉeno, ni interesiĝas pri la afero ĉerpi datumojn de SAP HCM. Ni rigardu ĝin pli detale.
SAP HCM-FUSE-interagodiagramo.
La ekstera sistemo determinas la tempon de la lasta sukcesa peto al SAP.
La procezo povas esti lanĉita per tempigilo aŭ alia evento, inkluzive de fiksado de tempotempo por atendi respondon kun datumoj de SAP kaj komenci ripetan peton. Tiam ĝi generas deltan peton kaj sendas ĝin al SAP.
La petaj datumoj estas senditaj al la korpo en json-formato.
Metodo http: POST.
Ekzempla peto:
La SAP-servo kontrolas la peton pri kompleteco, konformeco al la nuna SAP-strukturo kaj havebleco de alirpermeso al la petita tablo.
En kazo de eraroj, la servo resendas respondon kun la taŭga kodo kaj priskribo. Se kontrolo sukcesas, ĝi kreas fonan procezon por generi specimenon, generas kaj sinkrone resendas unikan seanididentigilon.
En kazo de eraro, la ekstera sistemo registras ĝin en la protokolo. En kazo de sukcesa respondo, ĝi transdonas la seanidaron kaj la nomon de la tabelo por kiu la peto estis farita.
La ekstera sistemo registras la nunan sesion kiel malfermita. Se estas aliaj sesioj por ĉi tiu tabelo, ili estas fermitaj kun averto registrita.
La fona laboro de SAP generas kursoron bazitan sur la specifitaj parametroj kaj datumpakaĵo de la specifita grandeco. Bata grandeco estas la maksimuma nombro da rekordoj kiujn procezo legas el la datumbazo. Defaŭlte, ĝi estas supozita esti egala al 2000. Se estas pli da rekordoj en la datumbaza specimeno ol la uzita pakaĵeto, post elsendado de la unua pakaĵeto, la sekva bloko estas formita kun la responda ofseto kaj pliigita pakaĵeto. La nombroj estas pliigitaj je 1 kaj senditaj strikte sinsekve.
Poste, SAP pasas la pakaĵon kiel enigaĵon al la retservo de la ekstera sistemo. Kaj la sistemo faras kontrolojn sur la envenanta pako. Sesio kun la ricevita identigilo devas esti registrita en la sistemo kaj ĝi devas esti en malferma stato. Se la pakaĵnumero > 1, la sistemo devus registri la sukcesan kvitancon de la antaŭa pako (package_id-1).
Se kontrolo sukcesas, la ekstera sistemo analizas kaj konservas la tabelajn datumojn.
Aldone, se la fina flago ĉeestas en la pakaĵo kaj seriigo estis sukcesa, la integriga modulo estas sciigita pri la sukcesa kompletigo de seanca pretigo kaj la modulo ĝisdatigas la sean statuson.
En kazo de kontrola/analiza eraro, la eraro estas registrita kaj pakoj por ĉi tiu sesio estos malakceptitaj de la ekstera sistemo.
Same, en la kontraŭa kazo, kiam la ekstera sistemo resendas eraron, ĝi estas registrita kaj paka transdono ĉesas.
Por peti datumojn pri la flanko de SAP HСM, integriga servo estis efektivigita. La servo estas efektivigita sur la ICF-kadro (SAP Interreta Komunikado-Kadro - ). Ĝi permesas vin pridemandi datumojn de la SAP HCM-sistemo uzante specifajn tabelojn. Kreante datuman peton, eblas specifi liston de specifaj kampoj kaj filtraj parametroj por akiri la necesajn datumojn. Samtempe, la efektivigo de la servo ne implicas ajnan komercan logikon. Algoritmoj por kalkulado de delto, demandaj parametroj, monitorado de integreco, ktp. ankaŭ estas efektivigitaj flanke de la ekstera sistemo.
Ĉi tiu mekanismo permesas kolekti kaj transdoni ĉiujn necesajn datumojn en kelkaj horoj. Ĉi tiu rapido estas akceptebla, do ni konsideras ĉi tiun solvon kiel provizoran, kiu ebligis plenigi la bezonon de eltira ilo en la projekto.
En la cela bildo, por solvi la problemon de eltiro de datumoj, oni esploras eblojn por uzi CDC-sistemojn kiel Oracle Golden Gate aŭ ETL-iloj kiel SAP DS.
fonto: www.habr.com