Tulad ng alam mo, nag-aalok ang SAP ng buong hanay ng software para sa pagpapanatili ng transactional data at para sa pagproseso ng data na ito sa pagsusuri at mga sistema ng pag-uulat. Sa partikular, ang platform ng SAP Business Warehouse (SAP BW) ay isang toolkit para sa pag-iimbak at pagsusuri ng data na may malawak na teknikal na kakayahan. Para sa lahat ng layunin na pakinabang nito, ang SAP BW system ay may isang makabuluhang disbentaha. Ito ay isang mataas na halaga ng pag-iimbak at pagproseso ng data, lalo na kapansin-pansin kapag gumagamit ng cloud-based na SAP BW sa Hana.
Paano kung nagsimula kang gumamit ng ilang hindi SAP at mas mabuti ang isang produkto ng OpenSource bilang imbakan? Kami sa X5 Retail Group ay pumili ng GreenPlum. Siyempre, malulutas nito ang isyu ng gastos, ngunit sa parehong oras, agad na lumitaw ang mga isyu na nalutas halos bilang default kapag gumagamit ng SAP BW.
Sa partikular, paano kunin ang data mula sa mga source system, na karamihan ay mga solusyon sa SAP?
Ang HR Sukatan ay ang unang proyekto kung saan ito ay kinakailangan upang malutas ang problemang ito. Ang aming layunin ay lumikha ng isang repositoryo ng data ng HR at bumuo ng analytical na pag-uulat sa lugar ng pakikipagtulungan sa mga empleyado. Sa kasong ito, ang pangunahing mapagkukunan ng data ay ang SAP HCM transactional system, kung saan ang lahat ng mga tauhan, organisasyonal at mga aktibidad sa suweldo ay isinasagawa.
Pagkuha ng data
Sa SAP BW mayroong karaniwang data extractors para sa SAP system. Maaaring awtomatikong kolektahin ng mga extractor na ito ang kinakailangang data, subaybayan ang integridad nito, at matukoy ang pagbabago ng mga delta. Narito, halimbawa, ang karaniwang data source para sa mga attribute ng empleyado na 0EMPLOYEE_ATTR:
Ang resulta ng pagkuha ng data mula dito para sa isang empleyado:
Kung kinakailangan, ang naturang extractor ay maaaring baguhin upang umangkop sa iyong sariling mga kinakailangan o ang iyong sariling extractor ay maaaring gawin.
Ang unang ideya na lumitaw ay ang posibilidad na muling gamitin ang mga ito. Sa kasamaang palad, ito ay naging isang imposibleng gawain. Karamihan sa lohika ay ipinatupad sa panig ng SAP BW, at hindi posible na walang sakit na paghiwalayin ang extractor sa pinagmulan mula sa SAP BW.
Naging malinaw na kakailanganin naming bumuo ng sarili naming mekanismo para sa pagkuha ng data mula sa mga sistema ng SAP.
Istraktura ng imbakan ng data sa SAP HCM
Upang maunawaan ang mga kinakailangan para sa naturang mekanismo, kailangan muna nating tukuyin kung anong data ang kailangan natin.
Karamihan sa data sa SAP HCM ay nakaimbak sa mga flat SQL table. Batay sa data na ito, nakikita ng mga application ng SAP ang mga istruktura ng organisasyon, empleyado at iba pang impormasyon ng HR sa user. Halimbawa, ito ang hitsura ng istraktura ng organisasyon sa SAP HCM:
Sa pisikal, ang gayong puno ay nakaimbak sa dalawang talahanayan - sa hrp1000 na mga bagay at sa hrp1001 ang mga koneksyon sa pagitan ng mga bagay na ito.
Mga Bagay na "Department 1" at "Office 1":
Relasyon sa pagitan ng mga bagay:
Maaaring mayroong isang malaking bilang ng parehong mga uri ng mga bagay at mga uri ng mga koneksyon sa pagitan ng mga ito. Mayroong parehong mga karaniwang koneksyon sa pagitan ng mga bagay at mga na-customize para sa iyong sariling mga partikular na pangangailangan. Halimbawa, ang karaniwang B012 na relasyon sa pagitan ng isang unit ng organisasyon at isang full-time na posisyon ay nagpapahiwatig ng pinuno ng isang departamento.
Display ng manager sa SAP:
Imbakan sa isang talahanayan ng database:
Ang data ng empleyado ay iniimbak sa pa* na mga talahanayan. Halimbawa, ang data sa mga kaganapan ng tauhan para sa isang empleyado ay nakaimbak sa talahanayan pa0000
Napagpasyahan namin na ang GreenPlum ay kukuha ng "raw" na data, ibig sabihin. kopyahin lamang ang mga ito mula sa mga talahanayan ng SAP. At direkta sa GreenPlum, sila ay ipoproseso at iko-convert sa mga pisikal na bagay (halimbawa, Kagawaran o Empleyado) at mga sukatan (halimbawa, average na bilang ng mga tao).
Humigit-kumulang 70 talahanayan ang tinukoy, ang data kung saan dapat ilipat sa GreenPlum. Pagkatapos nito ay nagsimula kaming gumawa ng paraan para sa pagpapadala ng data na ito.
Nag-aalok ang SAP ng medyo malaking bilang ng mga mekanismo ng pagsasama. Ngunit ang pinakamadaling paraan ay ang direktang pag-access sa database ay ipinagbabawal dahil sa mga paghihigpit sa paglilisensya. Kaya, ang lahat ng mga daloy ng pagsasama ay dapat ipatupad sa antas ng server ng application.
Ang susunod na problema ay ang kakulangan ng data tungkol sa mga tinanggal na tala sa database ng SAP. Kapag tinanggal mo ang isang hilera sa database, ito ay pisikal na tatanggalin. Yung. ang pagbuo ng isang pagbabago delta batay sa oras ng pagbabago ay hindi posible.
Siyempre, ang SAP HCM ay may mga mekanismo para sa pagtatala ng mga pagbabago sa data. Halimbawa, para sa kasunod na paglipat sa mga sistema ng tatanggap, mayroong mga pointer ng pagbabago na nagtatala ng anumang mga pagbabago at batay sa kung saan nabuo ang isang Idoc (isang bagay para sa paglipat sa mga panlabas na sistema).
Halimbawa ng IDoc para sa pagpapalit ng infotype 0302 para sa isang empleyado na may numero ng tauhan 1251445:
O ang pag-iingat ng mga log ng mga pagbabago sa data sa talahanayan ng DBTABLOG.
Isang halimbawa ng log para sa pagtanggal ng record na may key na QK53216375 mula sa hrp1000 table:
Ngunit ang mga mekanismong ito ay hindi magagamit para sa lahat ng kinakailangang data, at ang kanilang pagproseso sa antas ng server ng application ay maaaring kumonsumo ng maraming mapagkukunan. Samakatuwid, ang malawakang pagpapagana ng pag-log sa lahat ng kinakailangang talahanayan ay maaaring humantong sa isang kapansin-pansing pagkasira ng pagganap ng system.
Ang susunod na malaking problema ay ang mga clustered table. Ang pagtatantya ng oras at data ng payroll sa bersyon ng RDBMS ng SAP HCM ay iniimbak bilang isang hanay ng mga lohikal na talahanayan para sa bawat empleyado para sa bawat pagkalkula. Ang mga lohikal na talahanayan na ito ay naka-imbak bilang binary data sa talahanayan pcl2.
Payroll Cluster:
Ang data mula sa mga clustered table ay hindi maaaring ituring bilang isang SQL command, ngunit nangangailangan ng paggamit ng SAP HCM macros o mga espesyal na function module. Alinsunod dito, ang bilis ng pagbabasa ng naturang mga talahanayan ay magiging medyo mababa. Sa kabilang banda, ang mga naturang cluster ay nag-iimbak ng data na kailangan lamang isang beses sa isang buwan - panghuling payroll at pagtatantya ng oras. Kaya ang bilis sa kasong ito ay hindi masyadong kritikal.
Pagsusuri ng mga opsyon para sa pagbuo ng delta ng mga pagbabago sa data, nagpasya kaming isaalang-alang din ang opsyon ng ganap na pag-unload. Ang opsyon ng paglilipat ng gigabytes ng hindi nagbabagong data sa pagitan ng mga system araw-araw ay maaaring hindi maganda ang hitsura. Gayunpaman, mayroon din itong isang bilang ng mga pakinabang - hindi na kailangang parehong ipatupad ang delta sa gilid ng pinagmulan at ipatupad ang pag-embed ng delta na ito sa gilid ng receiver. Alinsunod dito, ang gastos at oras ng pagpapatupad ay nabawasan, at ang pagiging maaasahan ng pagsasama ay tumataas. Kasabay nito, natukoy na halos lahat ng mga pagbabago sa SAP HR ay nangyayari sa loob ng abot-tanaw na tatlong buwan bago ang kasalukuyang petsa. Kaya, napagpasyahan na mag-opt para sa isang pang-araw-araw na buong pag-download ng data mula sa SAP HR N buwan bago ang kasalukuyang petsa at isang buwanang buong pag-download. Ang parameter ng N ay nakasalalay sa partikular na talahanayan
at saklaw mula 1 hanggang 15.
Ang sumusunod na scheme ay iminungkahi para sa pagkuha ng data:
Ang panlabas na sistema ay bumubuo ng isang kahilingan at ipinapadala ito sa SAP HCM, kung saan ang kahilingang ito ay sinusuri para sa pagkakumpleto ng data at mga pahintulot na ma-access ang mga talahanayan. Kung matagumpay ang pagsusuri, ang SAP HCM ay nagpapatakbo ng isang programa na nangongolekta ng kinakailangang data at inililipat ito sa Fuse integration solution. Tinutukoy ng fuse ang kinakailangang paksa sa Kafka at inililipat ang data doon. Susunod, ang data mula sa Kafka ay inilipat sa Stage Area GP.
Sa chain na ito, interesado kami sa isyu ng pagkuha ng data mula sa SAP HCM. Tingnan natin ito nang mas detalyado.
Diagram ng pakikipag-ugnayan ng SAP HCM-FUSE.
Tinutukoy ng panlabas na sistema ang oras ng huling matagumpay na kahilingan sa SAP.
Ang proseso ay maaaring ilunsad ng isang timer o isa pang kaganapan, kabilang ang isang timeout upang maghintay para sa isang tugon na may data mula sa SAP at simulan ang isang paulit-ulit na kahilingan. Pagkatapos ay bumubuo ito ng isang delta na kahilingan at ipinapadala ito sa SAP.
Ang data ng kahilingan ay ipinadala sa katawan sa json na format.
Paraan http: POST.
Halimbawa ng kahilingan:
Sinusubaybayan ng serbisyo ng SAP ang kahilingan para sa pagkakumpleto, pagsunod sa kasalukuyang istraktura ng SAP, at pagkakaroon ng pahintulot sa pag-access sa hiniling na talahanayan.
Sa kaso ng mga error, ang serbisyo ay nagbabalik ng tugon na may naaangkop na code at paglalarawan. Kung matagumpay ang kontrol, gagawa ito ng proseso sa background upang makabuo ng sample, bumuo at sabay-sabay na nagbabalik ng natatanging session id.
Sa kaso ng isang error, itinatala ito ng panlabas na sistema sa log. Sa kaso ng isang matagumpay na tugon, ipinapadala nito ang session id at ang pangalan ng talahanayan kung saan ginawa ang kahilingan.
Inirerehistro ng panlabas na sistema ang kasalukuyang session bilang bukas. Kung may iba pang mga session para sa talahanayang ito, sarado ang mga ito nang may naka-log na babala.
Ang trabaho sa background ng SAP ay bumubuo ng isang cursor batay sa mga tinukoy na parameter at isang data packet ng tinukoy na laki. Ang laki ng batch ay ang maximum na bilang ng mga tala na binabasa ng isang proseso mula sa database. Bilang default, ito ay ipinapalagay na katumbas ng 2000. Kung mayroong higit pang mga tala sa sample ng database kaysa sa ginamit na laki ng packet, pagkatapos ipadala ang unang packet, ang susunod na bloke ay nabuo na may katumbas na offset at incremented na numero ng packet. Ang mga numero ay dinaragdagan ng 1 at mahigpit na ipinadala nang sunud-sunod.
Susunod, ipinapasa ng SAP ang packet bilang input sa web service ng external system. At ang system ay nagsasagawa ng mga kontrol sa papasok na packet. Ang isang session na may natanggap na id ay dapat na nakarehistro sa system at dapat itong nasa bukas na katayuan. Kung ang numero ng package > 1, dapat itala ng system ang matagumpay na pagtanggap ng nakaraang package (package_id-1).
Kung matagumpay ang kontrol, ang panlabas na system ay nag-parse at nagse-save ng data ng talahanayan.
Bukod pa rito, kung ang huling flag ay nasa package at matagumpay ang serialization, ang integration module ay aabisuhan tungkol sa matagumpay na pagkumpleto ng session processing at ang module ay nag-a-update ng session status.
Sa kaso ng isang error sa control/parsing, ang error ay naka-log at ang mga packet para sa session na ito ay tatanggihan ng panlabas na system.
Gayundin, sa kabaligtaran ng kaso, kapag ang panlabas na sistema ay nagbalik ng isang error, ito ay naka-log at ang packet transmission ay hihinto.
Upang humiling ng data sa panig ng SAP HΠ‘M, ipinatupad ang isang serbisyo sa pagsasama. Ang serbisyo ay ipinatupad sa ICF framework (SAP Internet Communication Framework - ). Pinapayagan ka nitong mag-query ng data mula sa SAP HCM system gamit ang mga partikular na talahanayan. Kapag gumagawa ng kahilingan sa data, posibleng tumukoy ng listahan ng mga partikular na field at mga parameter ng pag-filter upang makuha ang kinakailangang data. Kasabay nito, ang pagpapatupad ng serbisyo ay hindi nagpapahiwatig ng anumang lohika ng negosyo. Ang mga algorithm para sa pagkalkula ng delta, mga parameter ng query, pagsubaybay sa integridad, atbp. ay ipinapatupad din sa gilid ng panlabas na sistema.
Ang mekanismong ito ay nagpapahintulot sa iyo na mangolekta at magpadala ng lahat ng kinakailangang data sa loob ng ilang oras. Ang bilis na ito ay nasa bingit ng katanggap-tanggap, kaya itinuturing namin ang solusyon na ito bilang isang pansamantalang solusyon, na naging posible upang mapunan ang pangangailangan para sa isang tool sa pagkuha sa proyekto.
Sa target na larawan, upang malutas ang problema sa pagkuha ng data, ang mga opsyon para sa paggamit ng mga sistema ng CDC tulad ng Oracle Golden Gate o mga tool ng ETL tulad ng SAP DS ay ginalugad.
Pinagmulan: www.habr.com