Seperti yang Anda ketahui, SAP menawarkan rangkaian lengkap perangkat lunak baik untuk memelihara data transaksional maupun untuk memproses data ini dalam sistem analisis dan pelaporan. Secara khusus, platform SAP Business Warehouse (SAP BW) adalah perangkat untuk menyimpan dan menganalisis data dengan kemampuan teknis yang luas. Terlepas dari semua kelebihan obyektifnya, sistem SAP BW memiliki satu kelemahan signifikan. Ini adalah biaya penyimpanan dan pemrosesan data yang tinggi, terutama terlihat saat menggunakan SAP BW berbasis cloud di Hana.
Bagaimana jika Anda mulai menggunakan produk non-SAP dan sebaiknya produk OpenSource sebagai penyimpanan? Kami di Grup Ritel X5 memilih GreenPlum. Hal ini, tentu saja, menyelesaikan masalah biaya, tetapi pada saat yang sama, masalah segera muncul yang diselesaikan hampir secara default saat menggunakan SAP BW.
Secara khusus, bagaimana cara mengambil data dari sistem sumber, yang sebagian besar merupakan solusi SAP?
Metrik SDM adalah proyek pertama yang diperlukan untuk memecahkan masalah ini. Tujuan kami adalah membuat gudang data SDM dan membangun pelaporan analitis di bidang kerja dengan karyawan. Dalam hal ini, sumber data utama adalah sistem transaksional SAP HCM, di mana seluruh aktivitas personel, organisasi, dan penggajian dilakukan.
Ekstraksi data
Di SAP BW terdapat ekstraktor data standar untuk sistem SAP. Ekstraktor ini dapat secara otomatis mengumpulkan data yang diperlukan, memantau integritasnya, dan menentukan delta perubahan. Sebagai contoh, berikut adalah sumber data standar untuk atribut karyawan 0EMPLOYEE_ATTR:
Hasil penggalian data untuk satu karyawan:
Jika perlu, ekstraktor tersebut dapat dimodifikasi sesuai kebutuhan Anda atau ekstraktor Anda sendiri dapat dibuat.
Ide pertama yang muncul adalah kemungkinan untuk menggunakannya kembali. Sayangnya, hal ini ternyata merupakan tugas yang mustahil. Sebagian besar logika diimplementasikan di sisi SAP BW, dan tidak mungkin memisahkan ekstraktor pada sumbernya dari SAP BW tanpa kesulitan.
Menjadi jelas bahwa kita perlu mengembangkan mekanisme kita sendiri untuk mengekstraksi data dari sistem SAP.
Struktur penyimpanan data di SAP HCM
Untuk memahami persyaratan mekanisme tersebut, pertama-tama kita perlu menentukan data apa yang kita perlukan.
Sebagian besar data di SAP HCM disimpan dalam tabel SQL datar. Berdasarkan data ini, aplikasi SAP memvisualisasikan struktur organisasi, karyawan, dan informasi SDM lainnya kepada pengguna. Misalnya saja struktur organisasi di SAP HCM:
Secara fisik, pohon seperti itu disimpan dalam dua tabel - di objek hrp1000 dan di hrp1001 hubungan antara objek-objek ini.
Objek βDepartemen 1β dan βKantor 1β:
Hubungan antar objek:
Ada banyak sekali jenis objek dan jenis hubungan di antara keduanya. Ada koneksi standar antar objek dan koneksi yang disesuaikan untuk kebutuhan spesifik Anda. Misalnya, hubungan standar B012 antara unit organisasi dan posisi penuh waktu menunjukkan kepala departemen.
Tampilan manajer di SAP:
Penyimpanan dalam tabel database:
Data karyawan disimpan dalam tabel pa*. Misalnya, data kejadian personalia untuk seorang karyawan disimpan di tabel pa0000
Kami memutuskan bahwa GreenPlum akan mengambil data "mentah", mis. cukup salin dari tabel SAP. Dan langsung di GreenPlum mereka akan diproses dan diubah menjadi objek fisik (misalnya Departemen atau Karyawan) dan metrik (misalnya, jumlah pegawai rata-rata).
Sekitar 70 tabel telah ditentukan, datanya harus ditransfer ke GreenPlum. Setelah itu kami mulai menemukan metode untuk mengirimkan data ini.
SAP menawarkan sejumlah besar mekanisme integrasi. Namun cara termudah adalah akses langsung ke database dilarang karena pembatasan lisensi. Oleh karena itu, semua alur integrasi harus diterapkan di tingkat server aplikasi.
Masalah berikutnya adalah kurangnya data tentang catatan yang dihapus di database SAP. Saat Anda menghapus baris dalam database, baris tersebut akan terhapus secara fisik. Itu. pembentukan delta perubahan berdasarkan waktu perubahan tidak mungkin dilakukan.
Tentu saja SAP HCM memiliki mekanisme untuk mencatat perubahan data. Misalnya, untuk transfer selanjutnya ke sistem penerima, terdapat penunjuk perubahan yang mencatat setiap perubahan dan menjadi dasar pembentukan Idoc (objek untuk transfer ke sistem eksternal).
Contoh IDoc untuk mengubah infotype 0302 untuk pegawai dengan nomor personalia 1251445:
Atau menyimpan log perubahan data di tabel DBTABLOG.
Contoh log untuk menghapus record dengan kunci QK53216375 dari tabel hrp1000:
Namun mekanisme ini tidak tersedia untuk semua data yang diperlukan, dan pemrosesannya di tingkat server aplikasi dapat menghabiskan banyak sumber daya. Oleh karena itu, mengaktifkan logging secara besar-besaran pada semua tabel yang diperlukan dapat menyebabkan penurunan kinerja sistem yang nyata.
Masalah besar berikutnya adalah tabel berkerumun. Estimasi waktu dan data penggajian dalam versi RDBMS SAP HCM disimpan sebagai kumpulan tabel logis untuk setiap karyawan untuk setiap perhitungan. Tabel logis ini disimpan sebagai data biner di tabel pcl2.
Klaster Penggajian:
Data dari tabel berkerumun tidak dapat dianggap sebagai perintah SQL, namun memerlukan penggunaan makro SAP HCM atau modul fungsi khusus. Oleh karena itu, kecepatan membaca tabel tersebut akan cukup rendah. Di sisi lain, cluster tersebut menyimpan data yang dibutuhkan hanya sebulan sekali - penggajian akhir dan estimasi waktu. Jadi kecepatan dalam hal ini tidak begitu penting.
Mengevaluasi opsi untuk membentuk delta perubahan data, kami memutuskan untuk juga mempertimbangkan opsi pembongkaran penuh. Pilihan untuk mentransfer gigabyte data yang tidak berubah antar sistem setiap hari mungkin tidak terlihat bagus. Namun, ia juga memiliki sejumlah keuntungan - tidak perlu mengimplementasikan delta di sisi sumber dan mengimplementasikan penyematan delta ini di sisi penerima. Dengan demikian, biaya dan waktu implementasi berkurang, dan keandalan integrasi meningkat. Pada saat yang sama, ditentukan bahwa hampir semua perubahan dalam SAP HR terjadi dalam jangka waktu tiga bulan sebelum tanggal saat ini. Oleh karena itu, diputuskan untuk memilih pengunduhan penuh harian data dari SAP HR N beberapa bulan sebelum tanggal sekarang dan pengunduhan penuh bulanan. Parameter N bergantung pada tabel tertentu
dan berkisar dari 1 hingga 15.
Skema berikut diusulkan untuk ekstraksi data:
Sistem eksternal menghasilkan permintaan dan mengirimkannya ke SAP HCM, di mana permintaan ini diperiksa kelengkapan data dan izin untuk mengakses tabel. Jika pemeriksaan berhasil, SAP HCM menjalankan program yang mengumpulkan data yang diperlukan dan mentransfernya ke solusi integrasi Fuse. Fuse menentukan topik yang diperlukan di Kafka dan mentransfer data ke sana. Selanjutnya, data dari Kafka ditransfer ke Stage Area GP.
Dalam rantai ini, kami tertarik pada masalah ekstraksi data dari SAP HCM. Mari kita lihat lebih detail.
Diagram interaksi SAP HCM-FUSE.
Sistem eksternal menentukan waktu permintaan terakhir yang berhasil ke SAP.
Prosesnya dapat diluncurkan oleh pengatur waktu atau peristiwa lainnya, termasuk mengatur waktu tunggu untuk menunggu respons dengan data dari SAP dan memulai permintaan berulang. Kemudian menghasilkan permintaan delta dan mengirimkannya ke SAP.
Data permintaan dikirim ke badan dalam format json.
Metode http: POSTING.
Contoh permintaan:
Layanan SAP memantau permintaan kelengkapan, kepatuhan terhadap struktur SAP saat ini, dan ketersediaan izin akses ke tabel yang diminta.
Jika terjadi kesalahan, layanan mengembalikan respons dengan kode dan deskripsi yang sesuai. Jika kontrol berhasil, ini akan membuat proses latar belakang untuk menghasilkan sampel, menghasilkan, dan secara sinkron mengembalikan id sesi unik.
Jika terjadi kesalahan, sistem eksternal mencatatnya di log. Jika respons berhasil, ia mengirimkan id sesi dan nama tabel tempat permintaan dibuat.
Sistem eksternal mendaftarkan sesi saat ini sebagai sesi terbuka. Jika ada sesi lain untuk tabel ini, sesi tersebut ditutup dengan peringatan yang dicatat.
Pekerjaan latar belakang SAP menghasilkan kursor berdasarkan parameter yang ditentukan dan paket data dengan ukuran yang ditentukan. Ukuran batch adalah jumlah maksimum record yang dibaca suatu proses dari database. Secara default, diasumsikan sama dengan 2000. Jika ada lebih banyak catatan dalam sampel database daripada ukuran paket yang digunakan, setelah paket pertama ditransmisikan, blok berikutnya dibentuk dengan offset yang sesuai dan nomor paket yang bertambah. Angka-angka tersebut bertambah 1 dan dikirim secara berurutan.
Selanjutnya, SAP meneruskan paket tersebut sebagai masukan ke layanan web sistem eksternal. Dan sistem melakukan kontrol terhadap paket yang masuk. Sesi dengan id yang diterima harus terdaftar di sistem dan harus dalam status terbuka. Jika nomor paket > 1, maka sistem akan mencatat keberhasilan penerimaan paket sebelumnya (id_paket-1).
Jika kontrol berhasil, sistem eksternal mem-parsing dan menyimpan data tabel.
Selain itu, jika tanda terakhir ada dalam paket dan serialisasi berhasil, modul integrasi akan diberitahu tentang keberhasilan penyelesaian pemrosesan sesi dan modul memperbarui status sesi.
Jika terjadi kesalahan kontrol/parsing, kesalahan tersebut dicatat dan paket untuk sesi ini akan ditolak oleh sistem eksternal.
Demikian pula, dalam kasus sebaliknya, ketika sistem eksternal mengembalikan kesalahan, kesalahan tersebut dicatat dan transmisi paket berhenti.
Untuk meminta data di sisi SAP HΠ‘M, layanan integrasi diterapkan. Layanan ini diimplementasikan pada kerangka ICF (SAP Internet Communication Framework - ). Ini memungkinkan Anda untuk menanyakan data dari sistem SAP HCM menggunakan tabel tertentu. Saat membuat permintaan data, dimungkinkan untuk menentukan daftar bidang tertentu dan parameter pemfilteran untuk mendapatkan data yang diperlukan. Pada saat yang sama, penerapan layanan tidak menyiratkan logika bisnis apa pun. Algoritma untuk menghitung delta, parameter kueri, pemantauan integritas, dll. juga diterapkan di sisi sistem eksternal.
Mekanisme ini memungkinkan Anda mengumpulkan dan mengirimkan semua data yang diperlukan dalam beberapa jam. Kecepatan ini hampir dapat diterima, jadi kami menganggap solusi ini sebagai solusi sementara, yang memungkinkan untuk memenuhi kebutuhan alat ekstraksi pada proyek tersebut.
Dalam gambaran target, untuk memecahkan masalah ekstraksi data, opsi untuk menggunakan sistem CDC seperti Oracle Golden Gate atau alat ETL seperti SAP DS sedang dijajaki.
Sumber: www.habr.com