După cum știți, SAP oferă o gamă completă de software atât pentru menținerea datelor tranzacționale, cât și pentru procesarea acestor date în sisteme de analiză și raportare. În special, platforma SAP Business Warehouse (SAP BW) este un set de instrumente pentru stocarea și analiza datelor cu capacități tehnice extinse. Cu toate avantajele sale obiective, sistemul SAP BW are un dezavantaj semnificativ. Acesta este un cost ridicat de stocare și procesare a datelor, mai ales vizibil atunci când utilizați SAP BW bazat pe cloud pe Hana.
Ce se întâmplă dacă începeți să utilizați un produs non-SAP și, de preferință, un produs OpenSource ca stocare? Noi, cei de la X5 Retail Group, am ales GreenPlum. Acest lucru, desigur, rezolvă problema costurilor, dar, în același timp, apar imediat probleme care au fost rezolvate aproape implicit când se folosește SAP BW.
În special, cum să preluăm date din sistemele sursă, care sunt în mare parte soluții SAP?
HR Metrics a fost primul proiect în care a fost necesar să se rezolve această problemă. Scopul nostru a fost să creăm un depozit de date de HR și să construim rapoarte analitice în domeniul lucrului cu angajații. În acest caz, principala sursă de date este sistemul tranzacțional SAP HCM, în care se desfășoară toate activitățile de personal, organizatorice și salariale.
Extragerea datelor
În SAP BW există extractoare de date standard pentru sistemele SAP. Aceste extractoare pot colecta automat datele necesare, pot monitoriza integritatea acestora și pot determina deltele de modificare. Iată, de exemplu, sursa de date standard pentru atributele angajaților 0EMPLOYEE_ATTR:
Rezultatul extragerii datelor din acesta pentru un angajat:
Dacă este necesar, un astfel de extractor poate fi modificat pentru a se potrivi propriilor cerințe sau poate fi creat propriul dvs. extractor.
Prima idee care a apărut a fost posibilitatea de a le reutiliza. Din păcate, aceasta s-a dovedit a fi o sarcină imposibilă. Cea mai mare parte a logicii este implementată pe partea SAP BW și nu a fost posibilă separarea fără durere a extractorului la sursă de SAP BW.
A devenit evident că ar trebui să ne dezvoltăm propriul mecanism pentru extragerea datelor din sistemele SAP.
Structura de stocare a datelor în SAP HCM
Pentru a înțelege cerințele pentru un astfel de mecanism, trebuie mai întâi să stabilim de ce date avem nevoie.
Majoritatea datelor din SAP HCM sunt stocate în tabele SQL plate. Pe baza acestor date, aplicațiile SAP vizualizează către utilizator structurile organizaționale, angajații și alte informații de HR. De exemplu, așa arată structura organizațională în SAP HCM:
Din punct de vedere fizic, un astfel de arbore este stocat în două tabele - în obiecte hrp1000 și în hrp1001 conexiunile dintre aceste obiecte.
Obiectele „Departamentul 1” și „Biroul 1”:
Relația dintre obiecte:
Poate exista un număr mare de ambele tipuri de obiecte și tipuri de conexiuni între ele. Există atât conexiuni standard între obiecte, cât și unele personalizate pentru propriile nevoi specifice. De exemplu, relația standard B012 dintre o unitate organizațională și un post cu normă întreagă indică șeful unui departament.
Afișare manager în SAP:
Stocare într-un tabel de bază de date:
Datele angajaților sunt stocate în tabele pa*. De exemplu, datele despre evenimentele de personal pentru un angajat sunt stocate în tabelul pa0000
Am decis că GreenPlum va prelua date „brute”, adică. doar copiați-le din tabelele SAP. Și direct în GreenPlum vor fi procesate și convertite în obiecte fizice (de exemplu, Departament sau Angajat) și valori (de exemplu, numărul mediu de angajați).
Au fost definite aproximativ 70 de tabele, din care datele trebuie transferate către GreenPlum. După care am început să elaborăm o metodă de transmitere a acestor date.
SAP oferă un număr destul de mare de mecanisme de integrare. Dar cel mai simplu mod este ca accesul direct la baza de date să fie interzis din cauza restricțiilor de licențiere. Astfel, toate fluxurile de integrare trebuie implementate la nivel de server de aplicații.
Următoarea problemă a fost lipsa datelor despre înregistrările șterse din baza de date SAP. Când ștergeți un rând din baza de date, acesta este șters fizic. Acestea. formarea unei delte de schimbare bazată pe timpul schimbării nu a fost posibilă.
Desigur, SAP HCM are mecanisme de înregistrare a modificărilor datelor. De exemplu, pentru transferul ulterior către sistemele destinatare, există indicatori de modificare care înregistrează orice modificări și pe baza cărora se formează un Idoc (un obiect pentru transferul către sisteme externe).
Exemplu de IDoc pentru modificarea infotipului 0302 pentru un angajat cu număr de personal 1251445:
Sau păstrarea jurnalelor de modificări ale datelor în tabelul DBTABLOG.
Un exemplu de jurnal pentru ștergerea unei înregistrări cu cheia QK53216375 din tabelul hrp1000:
Dar aceste mecanisme nu sunt disponibile pentru toate datele necesare, iar procesarea lor la nivel de server de aplicații poate consuma destul de multe resurse. Prin urmare, activarea masivă a logării pe toate tabelele necesare poate duce la o degradare vizibilă a performanței sistemului.
Următoarea problemă majoră au fost tabelele grupate. Datele de estimare a timpului și de salarizare în versiunea RDBMS a SAP HCM sunt stocate ca un set de tabele logice pentru fiecare angajat pentru fiecare calcul. Aceste tabele logice sunt stocate ca date binare în tabelul pcl2.
Cluster de salarizare:
Datele din tabelele grupate nu pot fi considerate o comandă SQL, dar necesită utilizarea macrocomenzilor SAP HCM sau a modulelor cu funcții speciale. În consecință, viteza de citire a unor astfel de tabele va fi destul de scăzută. Pe de altă parte, astfel de clustere stochează date care sunt necesare doar o dată pe lună - salarizarea finală și estimarea timpului. Deci viteza în acest caz nu este atât de critică.
Evaluând opțiunile pentru formarea unei delte a modificărilor datelor, am decis să luăm în considerare și opțiunea de descărcare completă. Opțiunea de a transfera gigaocteți de date neschimbate între sisteme în fiecare zi poate să nu arate bine. Cu toate acestea, are și o serie de avantaje - nu este nevoie să implementați atât delta pe partea sursă, cât și să implementați încorporarea acestei delte pe partea receptorului. În consecință, costurile și timpul de implementare sunt reduse, iar fiabilitatea integrării crește. În același timp, s-a stabilit că aproape toate modificările în SAP HR au loc într-un orizont de trei luni înainte de data curentă. Astfel, s-a decis să opteze pentru o descărcare zilnică completă a datelor din SAP HR cu N luni înainte de data curentă și o descărcare completă lunară. Parametrul N depinde de tabelul specific
și variază de la 1 la 15.
Pentru extragerea datelor a fost propusă următoarea schemă:
Sistemul extern generează o solicitare și o trimite către SAP HCM, unde această solicitare este verificată pentru caracterul complet al datelor și permisiunile de acces la tabele. Dacă verificarea are succes, SAP HCM rulează un program care colectează datele necesare și le transferă în soluția de integrare Fuse. Fuse determină subiectul necesar în Kafka și transferă datele acolo. Apoi, datele de la Kafka sunt transferate către Stage Area GP.
În acest lanț, ne interesează problema extragerii datelor din SAP HCM. Să ne uităm la asta mai detaliat.
Diagrama de interacțiune SAP HCM-FUSE.
Sistemul extern determină ora ultimei solicitări reușite către SAP.
Procesul poate fi lansat printr-un cronometru sau alt eveniment, inclusiv setarea unui timeout pentru a aștepta un răspuns cu date de la SAP și a iniția o solicitare repetată. Apoi generează o cerere delta și o trimite către SAP.
Datele de solicitare sunt trimise corpului în format json.
Metoda http: POST.
Exemplu de solicitare:
Serviciul SAP monitorizează cererea de completitudine, conformitate cu structura SAP actuală și disponibilitatea permisiunii de acces la tabelul solicitat.
În caz de erori, serviciul returnează un răspuns cu codul și descrierea corespunzătoare. Dacă controlul are succes, acesta creează un proces de fundal pentru a genera un eșantion, generează și returnează sincron un ID de sesiune unic.
În cazul unei erori, sistemul extern o înregistrează în jurnal. În cazul unui răspuns cu succes, transmite id-ul sesiunii și numele tabelului pentru care a fost făcută cererea.
Sistemul extern înregistrează sesiunea curentă ca deschisă. Dacă există alte sesiuni pentru acest tabel, acestea sunt închise cu un avertisment înregistrat.
Lucrarea de fundal SAP generează un cursor bazat pe parametrii specificați și un pachet de date de dimensiunea specificată. Dimensiunea lotului este numărul maxim de înregistrări pe care un proces le citește din baza de date. În mod implicit, se presupune că este egal cu 2000. Dacă în eșantionul de bază de date există mai multe înregistrări decât dimensiunea pachetului utilizat, după transmiterea primului pachet, următorul bloc este format cu offset-ul și numărul de pachet incrementat corespunzător. Numerele sunt incrementate cu 1 și trimise strict secvenţial.
Apoi, SAP transmite pachetul ca intrare către serviciul web al sistemului extern. Și sistemul efectuează controale asupra pachetului primit. O sesiune cu id-ul primit trebuie să fie înregistrată în sistem și trebuie să fie în stare deschisă. Dacă numărul pachetului > 1, sistemul ar trebui să înregistreze primirea cu succes a pachetului anterior (package_id-1).
Dacă controlul are succes, sistemul extern analizează și salvează datele din tabel.
În plus, dacă indicatorul final este prezent în pachet și serializarea a avut succes, modulul de integrare este notificat despre finalizarea cu succes a procesării sesiunii și modulul actualizează starea sesiunii.
În cazul unei erori de control/parsare, eroarea este înregistrată și pachetele pentru această sesiune vor fi respinse de sistemul extern.
La fel, în cazul opus, când sistemul extern returnează o eroare, aceasta este înregistrată și transmisia pachetelor se oprește.
Pentru a solicita date pe partea SAP HСM, a fost implementat un serviciu de integrare. Serviciul este implementat pe cadrul ICF (SAP Internet Communication Framework - ). Vă permite să interogați date din sistemul SAP HCM folosind tabele specifice. La crearea unei cereri de date, este posibilă specificarea unei liste de câmpuri specifice și parametri de filtrare pentru a obține datele necesare. În același timp, implementarea serviciului nu implică nicio logică de business. Pe partea sistemului extern sunt implementați și algoritmi pentru calcularea deltei, parametrii de interogare, monitorizarea integrității etc.
Acest mecanism vă permite să colectați și să transmiteți toate datele necesare în câteva ore. Această viteză este pe punctul de a fi acceptabilă, așa că considerăm această soluție ca fiind una temporară, care a făcut posibilă satisfacerea necesității unui instrument de extracție pe proiect.
În imaginea țintă, pentru a rezolva problema extragerii datelor, sunt explorate opțiuni de utilizare a sistemelor CDC precum Oracle Golden Gate sau instrumente ETL precum SAP DS.
Sursa: www.habr.com