Soos u weet, bied SAP 'n volledige reeks sagteware, beide vir die instandhouding van transaksionele data en vir die verwerking van hierdie data in analise- en verslagdoeningstelsels. Die SAP Business Warehouse-platform (SAP BW) is veral 'n gereedskapstel vir databerging en -analise met breë tegniese vermoëns. Met al sy objektiewe voordele het die SAP BW-stelsel een beduidende nadeel. Dit is 'n hoë koste van databerging en verwerking, veral opvallend wanneer wolkgebaseerde SAP BW op Hana gebruik word.
Maar wat as jy een of ander nie-SAP en verkieslik 'n OpenSource-produk as 'n bewaarplek begin gebruik? Ons by X5 Retail Group het GreenPlum gekies. Dit los natuurlik die kostekwessie op, maar terselfdertyd verskyn daar dadelik vrae wat by die gebruik van SAP BW amper by verstek opgelos is.
In die besonder, hoe om data uit bronstelsels te neem, wat meestal SAP-oplossings is?
"HR Metrics" was die eerste projek waarin dit nodig was om hierdie probleem op te los. Ons doel was om 'n bewaarplek van HR-data te skep en analitiese verslagdoening te bou in die rigting van werk met werknemers. Terselfdertyd is die hoofdatabron die SAP HCM-transaksiestelsel, waarin alle personeel-, organisatoriese en betaalstaataktiwiteite onderhou word.
Data onttrekking
SAP BW vir SAP-stelsels het standaard data-onttrekkings. Hierdie onttrekkers kan outomaties die nodige data insamel, die integriteit daarvan opspoor en veranderingsdeltas bepaal. Hier is byvoorbeeld die standaard databron vir werknemerkenmerke 0EMPLOYEE_ATTR:
Die resultaat van die onttrekking van data daaruit vir een werknemer:
Indien nodig, kan so 'n afzuiger aangepas word om aan jou eie vereistes te voldoen, of jy kan jou eie afzuiger skep.
Die eerste idee was om hulle te hergebruik. Ongelukkig was dit 'n onmoontlike taak. Die meeste van die logika word aan die SAP BW-kant geïmplementeer, en dit was nie moontlik om die onttrekker by die bron pynloos van SAP BW te skei nie.
Dit het duidelik geword dat dit nodig sou wees om ons eie meganisme te ontwikkel om data uit SAP-stelsels te onttrek.
Databergingstruktuur in SAP HCM
Om die vereistes vir so 'n meganisme te verstaan, moet ons eers bepaal watter soort data ons benodig.
Die meeste van die data in SAP HCM word in plat SQL-tabelle gestoor. Op grond van hierdie data visualiseer SAP-toepassings organisatoriese strukture, werknemers en ander HR-inligting aan die gebruiker. Byvoorbeeld, dit is hoe die organisasiestruktuur in SAP HCM lyk:
Fisies word so 'n boom in twee tabelle gestoor - in hrp1000 voorwerpe en in hrp1001 die skakels tussen hierdie voorwerpe.
Voorwerpe "Departement 1" en "Departement 1":
Kommunikasie tussen voorwerpe:
Daar kan 'n groot aantal soorte voorwerpe wees, sowel as tipes verbindings tussen hulle. Daar is beide standaardverbindings tussen voorwerpe en pasgemaakte vir jou eie spesifieke behoeftes. Byvoorbeeld, die standaardverhouding B012 tussen 'n organisatoriese eenheid en 'n personeelpos dui op die hoof van 'n departement.
Wys 'n bestuurder in SAP:
Berging in 'n DB-tabel:
Werknemerdata word in pa*-tabelle gestoor. Byvoorbeeld, data oor personeelaktiwiteite vir 'n werknemer word in die tabel pa0000 gestoor
Ons het die besluit geneem dat GreenPlum "rou" data sal insamel, dws. kopieer hulle net van SAP-tabelle af. En reeds direk in GreenPlum sal hulle verwerk en omskep word in fisiese voorwerpe (byvoorbeeld departement of werknemer) en maatstawwe (byvoorbeeld gemiddelde personeeltelling).
Ongeveer 70 tabelle is gedefinieer, waarvan die data na GreenPlum oorgedra moet word. Daarna het ons begin om 'n manier uit te werk om hierdie data oor te dra.
SAP bied 'n redelike groot aantal integrasiemeganismes. Maar die maklikste manier is dat direkte toegang tot die databasis weens lisensiebeperkings verbied word. Alle integrasievloeie moet dus op die toepassingsbedienervlak geïmplementeer word.
Die volgende probleem was die gebrek aan data oor geskrap rekords in die SAP-databasis. Wanneer jy 'n ry in die databasis uitvee, word dit fisies uitgevee. Dié. die vorming van 'n delta van veranderinge oor die tyd van verandering was nie moontlik nie.
Natuurlik het SAP HCM meganismes om dataveranderinge reg te stel. Byvoorbeeld, vir daaropvolgende oordrag na ontvangerstelsels is daar veranderingswysers wat enige veranderinge regstel en op grond waarvan Idoc gevorm word ('n objek vir oordrag na eksterne stelsels).
'n Voorbeeld van 'n IDoc vir die verandering van inligtingtipe 0302 vir 'n werknemer met personeelnommer 1251445:
Of log data veranderinge in die DBTABLOG tabel.
'n Voorbeeld van 'n logboek om 'n inskrywing met die sleutel QK53216375 uit die hrp1000-tabel uit te vee:
Maar hierdie meganismes is nie beskikbaar vir al die nodige data nie, en die verwerking daarvan op die toepassingsbedienervlak kan nogal baie hulpbronne verbruik. Daarom kan die massa-insluiting van aanteken op alle nodige tabelle lei tot 'n merkbare agteruitgang van stelselwerkverrigting.
Die volgende groot probleem was gegroepeerde tafels. Tyd-evaluering en betaalstaatdata in die RDBMS-weergawe van SAP HCM word gestoor as 'n stel logiese tabelle per werknemer per betaalstaat. Hierdie logiese tabelle word as binêre data in die pcl2-tabel gestoor.
Betaalstaatgroepering:
Data van gegroepeerde tabelle kan nie as 'n SQL-opdrag gelees word nie, maar die gebruik van SAP HCM-makro's of spesiale funksiemodules word vereis. Gevolglik sal die leesspoed van sulke tabelle redelik laag wees. Aan die ander kant stoor sulke groepe data wat slegs een keer per maand benodig word - die finale betaalstaat en tydskattings. Dus is die spoed in hierdie geval nie so krities nie.
Deur die opsies te evalueer met die vorming van 'n dataveranderingsdelta, het ons ook besluit om die opsie met 'n volledige oplaai te oorweeg. Die opsie om elke dag gigagrepe onveranderde data tussen stelsels oor te dra, kan nie mooi lyk nie. Dit het egter ook 'n aantal voordele - dit is nie nodig om beide die delta aan die bronkant te implementeer en die inbedding van hierdie delta aan die ontvangerkant te implementeer nie. Gevolglik word die koste en implementeringstyd verminder, en die betroubaarheid van integrasie word verhoog. Terselfdertyd is vasgestel dat feitlik alle veranderinge in SAP HR binne 'n horison van drie maande voor die huidige datum plaasvind. Daar is dus besluit om te stop by 'n daaglikse volledige oplaai van data vanaf SAP HR N maande voor die huidige datum en 'n maandelikse volle oplaai. Die N parameter hang af van die spesifieke tabel
en wissel van 1 tot 15.
Die volgende skema is voorgestel vir data-onttrekking:
Die eksterne stelsel genereer 'n versoek en stuur dit na SAP HCM, waar hierdie versoek nagegaan word vir volledigheid van data en toestemmings om toegang tot tabelle te verkry. In die geval van 'n suksesvolle kontrole, loop SAP HCM 'n program wat die nodige data insamel en dit na die Fuse-integrasie-oplossing oordra. Fuse bepaal die vereiste onderwerp in Kafka en gee die data daarheen. Verder word die data van Kafka na die Stage Area GP oorgedra.
In hierdie ketting stel ons belang in die kwessie van die onttrekking van data uit SAP HCM. Laat ons in meer detail daaroor stilstaan.
SAP HCM-FUSE interaksiediagram.
Die eksterne stelsel bepaal die tyd van die laaste suksesvolle versoek aan SAP.
Die proses kan geaktiveer word deur 'n timer of ander gebeurtenis, insluitend die opstel van 'n uitteltyd vir wag vir 'n antwoord met data van SAP en die inisieer van 'n herprobeerversoek. Dan genereer dit 'n delta-navraag en stuur dit na SAP.
Die versoekdata word in json-formaat na die liggaam deurgegee.
http metode: POST.
Versoek voorbeeld:
Die SAP-diens beheer die versoek vir volledigheid, voldoening aan die huidige SAP-struktuur en die beskikbaarheid van toestemming om toegang tot die gevraagde tabel te verkry.
In die geval van foute, stuur die diens 'n antwoord terug met die toepaslike kode en beskrywing. In die geval van suksesvolle beheer, skep dit 'n agtergrondproses vir steekproefneming, genereer en gee dit sinchronies 'n unieke sessie-ID terug.
Die eksterne stelsel teken die fout aan in die geval van 'n fout. In die geval van 'n suksesvolle antwoord, stuur dit die sessie-ID en die naam van die tabel waarop die versoek gemaak is, deur.
Die eksterne stelsel registreer die huidige sessie as oop. As daar ander sessies op hierdie tabel is, word hulle gesluit met 'n waarskuwing aangeteken.
Die SAP agtergrond werk genereer 'n wyser met die gespesifiseerde parameters en 'n data pakkie van die gespesifiseerde grootte. Bondelgrootte - die maksimum aantal rekords wat die proses vanaf die databasis lees. Die verstekwaarde is 2000. As daar meer rekords in die databasisseleksie is as die gebruikte pakkiegrootte, word die volgende blok na die transmissie van die eerste pakkie gevorm met die ooreenstemmende offset en verhoogde pakkienommer. Die getalle word met 1 verhoog en word streng opeenvolgend gestuur.
Vervolgens gee SAP die pakkie deur na die insette van die webdiens van die eksterne stelsel. En dit is die stelsel wat beheer van die inkomende pakkie uitvoer. 'n Sessie met die ontvangde ID moet in die stelsel geregistreer wees en dit moet in 'n oop status wees. As die pakketnommer > 1, moet die stelsel die suksesvolle ontvangs van die vorige pakket (package_id-1) aanteken.
In die geval van suksesvolle beheer, ontleed en stoor die eksterne stelsel die tabeldata.
Verder, as die finale vlag in die pakket teenwoordig is en die serialisering suksesvol was, word die integrasiemodule in kennis gestel dat die sessieverwerking suksesvol voltooi is en die module dateer die sessiestatus op.
In die geval van 'n beheer/ontledingsfout, word die fout aangeteken en pakkies vir hierdie sessie sal deur die eksterne stelsel verwerp word.
Net so, in die teenoorgestelde geval, wanneer die eksterne stelsel 'n fout terugstuur, word dit aangeteken en die oordrag van pakkies stop.
Om data aan die SAP HCM-kant te versoek, is 'n integrasiediens geïmplementeer. Die diens word geïmplementeer op die ICF-raamwerk (SAP Internet Communication Framework - ). Dit laat jou toe om data van die SAP HCM-stelsel navraag te doen vir spesifieke tabelle. Wanneer 'n dataversoek gevorm word, is dit moontlik om 'n lys van spesifieke velde en filterparameters te spesifiseer om die nodige data te verkry. Terselfdertyd impliseer die implementering van die diens geen besigheidslogika nie. Algoritmes vir die berekening van delta, navraagparameters, integriteitsbeheer, ens. word ook aan die kant van die eksterne stelsel geïmplementeer.
Hierdie meganisme laat jou toe om al die nodige data in 'n paar uur te versamel en oor te dra. Hierdie spoed is op die rand van aanvaarbaar, so hierdie besluit word deur ons as 'n tydelike een beskou, wat ons in staat gestel het om die behoefte aan 'n onttrekkingsinstrument vir die projek te sluit.
In die teikenprent, om die probleem van data-onttrekking op te los, word opsies ontwikkel vir die gebruik van CDC-stelsels soos Oracle Golden Gate of ETL-instrumente soos SAP DS.
Bron: will.com