Sakumaha anjeun terang, SAP nawiskeun sajumlah lengkep parangkat lunak pikeun ngajaga data transaksi sareng ngolah data ieu dina sistem analisa sareng ngalaporkeun. Khususna, platform SAP Business Warehouse (SAP BW) mangrupikeun toolkit pikeun nyimpen sareng nganalisis data kalayan kamampuan téknis anu éksténsif. Pikeun sakabéh kaunggulan obyektif na, sistem SAP BW boga hiji aral signifikan. Ieu mangrupikeun biaya anu luhur pikeun nyimpen sareng ngolah data, khususna katingali nalika nganggo SAP BW dumasar-awan dina Hana.
Kumaha upami anjeun mimiti nganggo sababaraha non-SAP sareng langkung saé produk OpenSource salaku panyimpenan? Kami di X5 Retail Group milih GreenPlum. Ieu, tangtosna, ngarengsekeun masalah biaya, tapi dina waktos anu sami, masalah langsung timbul anu direngsekeun ampir sacara standar nalika nganggo SAP BW.
Utamana, kumaha carana meunangkeun data tina sistem sumber, nu lolobana solusi SAP?
HR metrics mangrupikeun proyek anu munggaran anu peryogi pikeun ngabéréskeun masalah ieu. Tujuanana kami nya éta nyieun gudang data HR sarta ngawangun laporan analitik di wewengkon gawé bareng karyawan. Dina hal ieu, sumber data utama nyaéta sistem transaksional SAP HCM, dimana sadaya kagiatan tanaga, organisasi sareng gaji dilaksanakeun.
ékstraksi data
Dina SAP BW aya ékstraktor data standar pikeun sistem SAP. extractors ieu otomatis bisa ngumpulkeun data diperlukeun, ngawas integritas na, sarta nangtukeun delta robah. Ieu, contona, sumber data standar pikeun atribut karyawan 0EMPLOYEE_ATTR:
Hasil ékstraksi data ti éta pikeun hiji pagawé:
Upami diperlukeun, extractor misalna hiji bisa dirobah pikeun nyocogkeun ka kabutuhan Anjeun sorangan atawa extractor sorangan bisa dijieun.
Gagasan anu mimiti muncul nyaéta kamungkinan ngagunakeunana deui. Hanjakalna, ieu tétéla janten tugas anu teu mungkin. Kalolobaan logika dilaksanakeun di sisi SAP BW, sarta ieu teu mungkin mun painlessly misahkeun extractor dina sumber ti SAP BW.
Janten écés yén urang kedah ngembangkeun mékanisme sorangan pikeun nimba data tina sistem SAP.
Struktur gudang data dina SAP HCM
Pikeun ngartos sarat pikeun mékanisme sapertos kitu, urang mimiti kedah nangtukeun data naon anu urang peryogikeun.
Paling data dina SAP HCM disimpen dina tabel SQL datar. Dumasar data ieu, aplikasi SAP visualize struktur organisasi, pagawé sarta informasi HR séjén pikeun pamaké. Salaku conto, ieu mangrupikeun struktur organisasi dina SAP HCM:
Sacara fisik, tangkal sapertos kitu disimpen dina dua tabel - dina hrp1000 objék sareng dina hrp1001 sambungan antara objék ieu.
Objék "Departemen 1" sareng "Kantor 1":
Hubungan antara objék:
Aya tiasa sajumlah ageung dua jinis objék sareng jinis sambungan antara aranjeunna. Aya duanana sambungan baku antara objék jeung leuwih ngaropéa pikeun kaperluan husus Anjeun sorangan. Salaku conto, hubungan B012 standar antara unit organisasi sareng posisi full-time nunjukkeun kapala jabatan.
Tampilan manajer di SAP:
Panyimpen dina tabel database:
data pagawe disimpen dina pa * tabél. Contona, data dina acara tanaga pikeun hiji pagawe disimpen dina tabel pa0000
Kami mutuskeun yén GreenPlum bakal nyandak data "atah", nyaéta. ngan nyalin aranjeunna tina tabel SAP. Sareng langsung di GreenPlum aranjeunna bakal diolah sareng dirobih janten objék fisik (contona, Jurusan atanapi Karyawan) sareng métrik (contona, rata-rata headcount).
Sakitar 70 tabel ditetepkeun, data anu kedah ditransfer ka GreenPlum. Saatos éta kami mimiti damel metode pikeun ngirimkeun data ieu.
SAP nawiskeun sajumlah mékanisme integrasi anu lumayan ageung. Tapi cara panggampangna nyaéta aksés langsung kana pangkalan data dilarang kusabab larangan lisénsi. Ku kituna, sadaya aliran integrasi kudu dilaksanakeun di tingkat server aplikasi.
Masalah salajengna éta kurangna data ngeunaan rékaman dihapus dina database SAP. Nalika anjeun ngahapus barisan dina pangkalan data, éta sacara fisik dihapus. Jelema. formasi délta robah dumasar kana waktu robah éta teu mungkin.
Tangtosna, SAP HCM gaduh mékanisme pikeun ngarékam parobahan data. Contona, pikeun mindahkeun saterusna ka sistem panarima, aya pointers robah anu ngarekam parobahan naon jeung dina dasar nu hiji Idoc kabentuk (obyek pikeun mindahkeun ka sistem éksternal).
Conto IDoc pikeun ngarobih infotype 0302 pikeun karyawan kalayan nomer tanaga 1251445:
Atawa ngajaga log parobahan data dina tabel DBTABLOG.
Conto log pikeun ngahapus rékaman nganggo konci QK53216375 tina tabel hrp1000:
Tapi mékanisme ieu teu sadia pikeun sakabéh data diperlukeun, sarta ngolah maranéhanana di tingkat server aplikasi bisa meakeun cukup loba sumberdaya. Ku alatan éta, massively sangkan logging dina sagala tabel diperlukeun bisa ngakibatkeun degradasi noticeable kinerja sistem.
Masalah utama salajengna nyaéta tabel clustered. Estimasi waktos na data gaji dina versi RDBMS of SAP HCM disimpen salaku susunan tabel logis pikeun tiap pagawe pikeun tiap itungan. tabél logis ieu disimpen salaku data binér dina tabel pcl2.
Kluster Gaji:
Data tina tabel clustered teu bisa dianggap salaku paréntah SQL, tapi merlukeun pamakéan SAP HCM macros atawa modul fungsi husus. Sasuai, laju maca tabel sapertos bakal rada handap. Di sisi anu sanésna, klaster sapertos nyimpen data anu diperyogikeun ngan ukur sabulan sakali - gaji akhir sareng estimasi waktos. Jadi speed dina hal ieu teu jadi kritis.
Evaluating pilihan pikeun ngabentuk délta parobahan data, urang mutuskeun ogé mertimbangkeun pilihan unloading pinuh. Pilihan pikeun nransferkeun gigabytes data anu teu dirobih antara sistem unggal dinten panginten henteu saé. Nanging, éta ogé ngagaduhan sajumlah kaunggulan - henteu kedah ngalaksanakeun délta dina sisi sumber sareng ngalaksanakeun embedding délta ieu dina sisi panarima. Sasuai, biaya sareng waktos palaksanaan dikirangan, sareng réliabilitas integrasi ningkat. Dina waktos anu sami, ditetepkeun yén ampir sadaya parobihan dina SAP HR lumangsung dina cakrawala tilu bulan sateuacan tanggal ayeuna. Ku kituna, diputuskeun pikeun milih undeuran lengkep unggal dinten tina data SAP HR N sasih sateuacan tanggal ayeuna sareng unduhan lengkep bulanan. Parameter N gumantung kana tabel husus
jeung rentang ti 1 nepi ka 15.
Skéma ieu diusulkeun pikeun ékstraksi data:
Sistim éksternal ngahasilkeun pamundut sarta ngirimkeunana ka SAP HCM, dimana pamundut ieu dipariksa pikeun completeness data jeung idin pikeun ngakses tabel. Upami cékna suksés, SAP HCM ngajalankeun program anu ngumpulkeun data anu diperyogikeun sareng mindahkeun kana solusi integrasi Fuse. Fuse nangtukeun topik diperlukeun dina Kafka sarta mindahkeun data dinya. Salajengna, data ti Kafka ditransfer ka Stage Area GP.
Dina ranté ieu, urang museurkeun masalah extracting data ti SAP HCM. Hayu urang nempo eta dina leuwih jéntré.
SAP HCM-FUSE diagram interaksi.
Sistim éksternal nangtukeun waktu pamundut suksés panungtungan pikeun SAP.
Prosésna tiasa diluncurkeun ku timer atanapi acara anu sanés, kalebet waktos waktos ngantosan réspon sareng data tina SAP sareng ngamimitian pamundut ulang. Lajeng dibangkitkeun pamundut délta sarta ngirimkeun ka SAP.
Data pamundut dikirim ka awak dina format json.
Métode http: POST.
Conto pamundut:
Ladenan SAP ngawas paménta pikeun kasampurnaan, patuh kana struktur SAP ayeuna, sareng kasadiaan idin aksés kana méja anu dipénta.
Upami aya kasalahan, jasa éta ngabalikeun réspon kalayan kode sareng katerangan anu pas. Upami kontrol suksés, éta nyiptakeun prosés latar pikeun ngahasilkeun sampel, ngahasilkeun sareng sakaligus mulihkeun sési id anu unik.
Upami aya kasalahan, sistem éksternal ngarékam éta dina log. Dina hal réspon anu suksés, éta ngirimkeun id sési sareng nami tabel dimana pamundut éta dilakukeun.
Sistem éksternal ngadaptar sési ayeuna salaku kabuka. Lamun aya sesi séjén pikeun tabel ieu, aranjeunna ditutup ku warning asup.
Proyék tukang SAP ngahasilkeun kursor dumasar kana parameter anu ditangtukeun sareng pakét data tina ukuran anu ditangtukeun. Ukuran bets nyaéta jumlah maksimum rékaman anu dibaca prosés tina pangkalan data. Sacara standar, eta dianggap sarua jeung 2000. Lamun aya leuwih rékaman dina sampel database ti ukuran pakét dipaké, sanggeus ngirimkeun pakét munggaran, blok salajengna kabentuk jeung offset pakait jeung angka pakét incremented. Jumlah na incremented ku 1 sarta dikirim mastikeun sequentially.
Salajengna, SAP ngalangkungan pakét salaku input kana jasa wéb sistem éksternal. Jeung sistem ngalakukeun kadali dina pakét asup. Sesi sareng id anu ditampi kedah didaptarkeun dina sistem sareng kedah aya dina status kabuka. Upami nomer pakét> 1, sistem kedah ngarékam resi suksés tina pakét sateuacana (package_id-1).
Lamun kontrol suksés, sistem éksternal parses tur nyimpen data tabel.
Sajaba ti, lamun bendera final hadir dina pakét jeung serialization éta suksés, modul integrasi dibere beja ngeunaan parantosan suksés ngolah sési sarta modul ngamutahirkeun status sési.
Dina kasus kasalahan kontrol / parsing, kasalahan ieu asup jeung pakét pikeun sési ieu bakal ditolak ku sistem éksternal.
Kitu ogé, dina kasus sabalikna, nalika sistem éksternal mulangkeun kasalahan, éta log sarta pangiriman pakét eureun.
Pikeun nyuhunkeun data dina sisi SAP HСM, jasa integrasi dilaksanakeun. Ladenan ieu dilaksanakeun dina kerangka ICF (SAP Internet Communication Framework - ). Eta ngidinan Anjeun pikeun query data tina sistem SAP HCM ngagunakeun tabel husus. Nalika nyieun pamundut data, kasebut nyaéta dimungkinkeun pikeun nangtukeun daptar widang husus sarta parameter nyaring dina urutan pikeun ménta data diperlukeun. Dina waktos anu sami, palaksanaan jasa henteu nunjukkeun logika bisnis. Algoritma keur ngitung délta, parameter query, monitoring integritas, jsb ogé dilaksanakeun di sisi sistem éksternal.
Mékanisme ieu ngamungkinkeun anjeun pikeun ngumpulkeun sareng ngirimkeun sadaya data anu diperyogikeun dina sababaraha jam. speed ieu dina verge of ditarima, jadi anggap we solusi ieu salaku samentara, nu ngamungkinkeun pikeun ngeusian kabutuhan alat ékstraksi dina proyék.
Dina gambar target, pikeun ngajawab masalah ékstraksi data, pilihan pikeun ngagunakeun sistem CDC kayaning Oracle Golden Gate atawa parabot ETL kayaning SAP DS keur digali.
sumber: www.habr.com