Seperti yang anda ketahui, SAP menawarkan rangkaian penuh perisian untuk menyelenggara data transaksi dan untuk memproses data ini dalam sistem analisis dan pelaporan. Khususnya, platform SAP Business Warehouse (SAP BW) ialah kit alat untuk menyimpan dan menganalisis data dengan keupayaan teknikal yang meluas. Untuk semua kelebihan objektifnya, sistem SAP BW mempunyai satu kelemahan yang ketara. Ini adalah kos yang tinggi untuk menyimpan dan memproses data, terutamanya ketara apabila menggunakan SAP BW berasaskan awan pada Hana.
Bagaimana jika anda mula menggunakan beberapa bukan SAP dan sebaik-baiknya produk OpenSource sebagai storan? Kami di X5 Retail Group memilih GreenPlum. Ini, sudah tentu, menyelesaikan isu kos, tetapi pada masa yang sama, isu-isu segera timbul yang diselesaikan hampir secara lalai apabila menggunakan SAP BW.
Khususnya, bagaimana untuk mendapatkan data daripada sistem sumber, yang kebanyakannya merupakan penyelesaian SAP?
HR Metrics ialah projek pertama yang memerlukan penyelesaian masalah ini. Matlamat kami adalah untuk mencipta repositori data HR dan membina pelaporan analitikal dalam bidang bekerja dengan pekerja. Dalam kes ini, sumber utama data ialah sistem transaksi SAP HCM, di mana semua aktiviti kakitangan, organisasi dan gaji dijalankan.
Pengekstrakan data
Dalam SAP BW terdapat pengekstrak data standard untuk sistem SAP. Pengekstrak ini secara automatik boleh mengumpul data yang diperlukan, memantau integritinya dan menentukan delta perubahan. Di sini, sebagai contoh, ialah sumber data standard untuk atribut pekerja 0EMPLOYEE_ATTR:
Hasil daripada mengekstrak data daripadanya untuk seorang pekerja:
Jika perlu, pengekstrak sedemikian boleh diubah suai untuk memenuhi keperluan anda sendiri atau pengekstrak anda sendiri boleh dibuat.
Idea pertama yang timbul ialah kemungkinan menggunakannya semula. Malangnya, ini ternyata menjadi tugas yang mustahil. Kebanyakan logik dilaksanakan pada bahagian SAP BW, dan tidak mungkin untuk memisahkan pengekstrak pada sumber daripada SAP BW tanpa rasa sakit.
Ia menjadi jelas bahawa kami perlu membangunkan mekanisme kami sendiri untuk mengekstrak data daripada sistem SAP.
Struktur penyimpanan data dalam SAP HCM
Untuk memahami keperluan untuk mekanisme sedemikian, pertama sekali kita perlu menentukan data yang kita perlukan.
Kebanyakan data dalam SAP HCM disimpan dalam jadual SQL rata. Berdasarkan data ini, aplikasi SAP menggambarkan struktur organisasi, pekerja dan maklumat HR lain kepada pengguna. Sebagai contoh, inilah rupa struktur organisasi dalam SAP HCM:
Secara fizikal, pokok sedemikian disimpan dalam dua jadual - dalam hrp1000 objek dan dalam hrp1001 sambungan antara objek ini.
Objek "Jabatan 1" dan "Pejabat 1":
Hubungan antara objek:
Terdapat sejumlah besar kedua-dua jenis objek dan jenis sambungan di antara mereka. Terdapat kedua-dua sambungan standard antara objek dan yang disesuaikan untuk keperluan khusus anda sendiri. Sebagai contoh, perhubungan standard B012 antara unit organisasi dan jawatan sepenuh masa menunjukkan ketua jabatan.
Paparan pengurus dalam SAP:
Penyimpanan dalam jadual pangkalan data:
Data pekerja disimpan dalam jadual pa*. Sebagai contoh, data tentang acara kakitangan untuk pekerja disimpan dalam jadual pa0000
Kami memutuskan bahawa GreenPlum akan mengambil data "mentah", i.e. salin sahaja daripada jadual SAP. Dan secara langsung dalam GreenPlum mereka akan diproses dan ditukar menjadi objek fizikal (contohnya, Jabatan atau Pekerja) dan metrik (contohnya, kiraan purata).
Kira-kira 70 jadual telah ditakrifkan, data daripadanya mesti dipindahkan ke GreenPlum. Selepas itu kami mula membuat kaedah untuk menghantar data ini.
SAP menawarkan sejumlah besar mekanisme integrasi. Tetapi cara paling mudah ialah akses terus ke pangkalan data adalah dilarang kerana sekatan pelesenan. Oleh itu, semua aliran integrasi mesti dilaksanakan di peringkat pelayan aplikasi.
Masalah seterusnya ialah kekurangan data mengenai rekod yang dipadam dalam pangkalan data SAP. Apabila anda memadamkan baris dalam pangkalan data, ia dipadamkan secara fizikal. Itu. pembentukan delta perubahan berdasarkan masa perubahan tidak dapat dilakukan.
Sudah tentu, SAP HCM mempunyai mekanisme untuk merekod perubahan data. Sebagai contoh, untuk pemindahan berikutnya kepada sistem penerima, terdapat penunjuk perubahan yang merekodkan sebarang perubahan dan berdasarkannya Idoc dibentuk (objek untuk pemindahan ke sistem luaran).
Contoh IDoc untuk menukar maklumat jenis 0302 untuk pekerja dengan nombor kakitangan 1251445:
Atau menyimpan log perubahan data dalam jadual DBTABLOG.
Contoh log untuk memadam rekod dengan kunci QK53216375 daripada jadual hrp1000:
Tetapi mekanisme ini tidak tersedia untuk semua data yang diperlukan, dan pemprosesannya di peringkat pelayan aplikasi boleh menggunakan banyak sumber. Oleh itu, mendayakan pengelogan secara besar-besaran pada semua jadual yang diperlukan boleh membawa kepada kemerosotan prestasi sistem yang ketara.
Masalah utama seterusnya ialah jadual berkelompok. Anggaran masa dan data gaji dalam versi RDBMS SAP HCM disimpan sebagai satu set jadual logik untuk setiap pekerja untuk setiap pengiraan. Jadual logik ini disimpan sebagai data binari dalam jadual pcl2.
Kluster Gaji:
Data daripada jadual berkelompok tidak boleh dianggap sebagai perintah SQL, tetapi memerlukan penggunaan makro SAP HCM atau modul fungsi khas. Oleh itu, kelajuan membaca jadual sedemikian akan menjadi agak rendah. Sebaliknya, kluster sedemikian menyimpan data yang diperlukan hanya sekali sebulan - gaji akhir dan anggaran masa. Jadi kelajuan dalam kes ini tidak begitu kritikal.
Menilai pilihan untuk membentuk delta perubahan data, kami memutuskan untuk turut mempertimbangkan pilihan pemunggahan penuh. Pilihan untuk memindahkan gigabait data yang tidak berubah antara sistem setiap hari mungkin tidak kelihatan baik. Walau bagaimanapun, ia juga mempunyai beberapa kelebihan - tidak perlu kedua-duanya melaksanakan delta pada bahagian sumber dan melaksanakan pembenaman delta ini pada bahagian penerima. Sehubungan itu, kos dan masa pelaksanaan dikurangkan, dan kebolehpercayaan integrasi meningkat. Pada masa yang sama, telah ditentukan bahawa hampir semua perubahan dalam SAP HR berlaku dalam tempoh tiga bulan sebelum tarikh semasa. Oleh itu, telah diputuskan untuk memilih muat turun penuh harian data daripada SAP HR N bulan sebelum tarikh semasa dan muat turun penuh bulanan. Parameter N bergantung pada jadual tertentu
dan berkisar antara 1 hingga 15.
Skim berikut telah dicadangkan untuk pengekstrakan data:
Sistem luaran menjana permintaan dan menghantarnya kepada SAP HCM, di mana permintaan ini disemak untuk kesempurnaan data dan kebenaran untuk mengakses jadual. Jika semakan berjaya, SAP HCM menjalankan program yang mengumpul data yang diperlukan dan memindahkannya ke penyelesaian penyepaduan Fius. Fius menentukan topik yang diperlukan dalam Kafka dan memindahkan data ke sana. Seterusnya, data daripada Kafka dipindahkan ke Stage Area GP.
Dalam rantaian ini, kami berminat dengan isu mengekstrak data daripada SAP HCM. Mari kita lihat dengan lebih terperinci.
Gambar rajah interaksi SAP HCM-FIUS.
Sistem luaran menentukan masa permintaan terakhir yang berjaya kepada SAP.
Proses ini boleh dilancarkan oleh pemasa atau acara lain, termasuk menetapkan tamat masa untuk menunggu respons dengan data daripada SAP dan memulakan permintaan ulangan. Kemudian ia menjana permintaan delta dan menghantarnya ke SAP.
Data permintaan dihantar ke badan dalam format json.
Kaedah http: POST.
Contoh permintaan:
Perkhidmatan SAP memantau permintaan untuk kesempurnaan, pematuhan dengan struktur SAP semasa dan ketersediaan kebenaran akses kepada jadual yang diminta.
Sekiranya berlaku ralat, perkhidmatan mengembalikan respons dengan kod dan perihalan yang sesuai. Jika kawalan berjaya, ia mewujudkan proses latar belakang untuk menjana sampel, menjana dan mengembalikan id sesi unik secara serentak.
Sekiranya berlaku ralat, sistem luaran merekodkannya dalam log. Sekiranya respons berjaya, ia menghantar id sesi dan nama jadual yang permintaan itu dibuat.
Sistem luaran mendaftarkan sesi semasa sebagai terbuka. Jika terdapat sesi lain untuk jadual ini, ia ditutup dengan amaran dilog.
Tugas latar belakang SAP menjana kursor berdasarkan parameter yang ditentukan dan paket data saiz yang ditentukan. Saiz kelompok ialah bilangan maksimum rekod yang dibaca oleh proses daripada pangkalan data. Secara lalai, ia diandaikan bersamaan dengan 2000. Jika terdapat lebih banyak rekod dalam sampel pangkalan data daripada saiz paket yang digunakan, selepas menghantar paket pertama, blok seterusnya dibentuk dengan mengimbangi yang sepadan dan nombor paket yang ditambah. Nombor ditambah dengan 1 dan dihantar dengan ketat mengikut urutan.
Seterusnya, SAP menghantar paket sebagai input kepada perkhidmatan web sistem luaran. Dan sistem melakukan kawalan pada paket masuk. Sesi dengan id yang diterima mesti didaftarkan dalam sistem dan ia mestilah dalam status terbuka. Jika nombor pakej > 1, sistem hendaklah merekodkan penerimaan pakej sebelumnya yang berjaya (package_id-1).
Jika kawalan berjaya, sistem luaran menghuraikan dan menyimpan data jadual.
Selain itu, jika bendera akhir hadir dalam pakej dan penyirian berjaya, modul penyepaduan dimaklumkan tentang kejayaan menyelesaikan pemprosesan sesi dan modul mengemas kini status sesi.
Sekiranya ralat kawalan/penghuraian, ralat direkodkan dan paket untuk sesi ini akan ditolak oleh sistem luaran.
Begitu juga, dalam kes yang bertentangan, apabila sistem luaran mengembalikan ralat, ia dilog dan penghantaran paket berhenti.
Untuk meminta data pada bahagian SAP HΠ‘M, perkhidmatan penyepaduan telah dilaksanakan. Perkhidmatan ini dilaksanakan pada rangka kerja ICF (SAP Internet Communication Framework - ). Ia membolehkan anda membuat pertanyaan data daripada sistem SAP HCM menggunakan jadual tertentu. Apabila membuat permintaan data, adalah mungkin untuk menentukan senarai medan tertentu dan parameter penapisan untuk mendapatkan data yang diperlukan. Pada masa yang sama, pelaksanaan perkhidmatan tidak membayangkan sebarang logik perniagaan. Algoritma untuk mengira delta, parameter pertanyaan, pemantauan integriti, dsb. juga dilaksanakan pada sisi sistem luaran.
Mekanisme ini membolehkan anda mengumpul dan menghantar semua data yang diperlukan dalam beberapa jam. Kelajuan ini berada di ambang boleh diterima, jadi kami menganggap penyelesaian ini sebagai penyelesaian sementara, yang memungkinkan untuk memenuhi keperluan alat pengekstrakan pada projek itu.
Dalam gambar sasaran, untuk menyelesaikan masalah pengekstrakan data, pilihan untuk menggunakan sistem CDC seperti Oracle Golden Gate atau alat ETL seperti SAP DS sedang diterokai.
Sumber: www.habr.com