După cum se știe, compania SAP oferă o gamă completă de software, atât pentru gestionarea datelor de tranzacție, cât și pentru procesarea acestor date în sistemele de analiză și raportare. În special, platforma SAP Business Warehouse (SAP BW) reprezintă un instrument pentru stocarea și analiza datelor, având capacități tehnice extinse. Cu toate avantajele sale obiective, sistemul SAP BW are un dezavantaj semnificativ: costurile ridicate de stocare și procesare a datelor, mai ales în utilizarea SAP BW pe Hana în cloud.
Și ce s-ar întâmpla dacă am începe să utilizăm un produs non-SAP și ideal, OpenSource, ca stocare? Noi, la X5 Retail Group, am ales GreenPlum. Acest lucru ajută cu siguranță la reducerea costurilor, însă apar imediat întrebări pe care utilizarea SAP BW le rezolvă practic de la sine.
În special, cum putem extrage datele din sistemele sursă, care, în cea mai mare parte, sunt soluții SAP?
Proiectul „HR-metrice” a fost primul în care a trebuit să abordăm această problemă. Scopul nostru a fost să creăm un depozit de date HR și să construim raportări analitice pe tema managementului resurselor umane. Principala sursă de date este sistemul de tranzacții SAP HCM, în care sunt gestionate toate activitățile legate de personal, organizație și salarii.
Extracția datelor
În SAP BW pentru sistemele SAP există extractori standard de date. Acești extractori pot colecta automat datele necesare, monitorizându-le integritatea și determinând delfele schimbărilor. De exemplu, un standard de sursă de date pentru atributele angajatului 0EMPLOYEE_ATTR:
Rezultatul extracției de date din acesta pentru un singur angajat:
Dacă este necesar, un astfel de extractor poate fi modificat pentru cerințele proprii sau poate fi creat un extractor personalizat.
Prima idee a fost posibilitatea reutilizării acestora. Din păcate, s-a dovedit a fi o sarcină imposibilă. Mare parte din logică este implementată pe partea SAP BW și nu a fost posibil să separăm fără durere extractorul de sursă de SAP BW.
A devenit evident că va fi necesară dezvoltarea unui mecanism propriu de extragere a 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ă definim ce date ne vor fi necesare.
Cele mai multe date din SAP HCM sunt stocate în tabele SQL plate. Pe baza acestor date, aplicațiile SAP vizualizează utilizatorului structurile organizaționale, angajații și alte informații HR. De exemplu, iată cum arată structura organizațională în SAP HCM:
Fizic, acest arbore este stocat în două tabele – în hrp1000 obiectele și în hrp1001 relațiile dintre aceste obiecte.
Obiectele „Departament 1” și „Conducere 1”:
Relația dintre obiecte:
Atât tipurile de obiecte, cât și tipurile de relații dintre acestea pot fi extrem de variate. Există atât relații standard între obiecte, cât și personalizate pentru nevoile specifice. De exemplu, relația standard B012 între unitatea organizațională și funcția de personal indică managerul departamentului.
Afișarea managerului în SAP:
Stocarea în tabelă Baza de date:
Datele angajaților sunt stocate în tabelele pa*. De exemplu, datele despre activitățile de personal pentru un angajat sunt stocate în tabela pa0000.
Am decis că GreenPlum va prelua datele „brute”, adică va copia pur și simplu din tabelele SAP. Iar în GreenPlum acestea vor fi prelucrate și transformate în obiecte fizice (de exemplu, Departament sau Angajat) și metrici (de exemplu, numărul mediu de angajați).
Au fost identificate aproximativ 70 de tabele ale căror date trebuie transmise în GreenPlum. După care am început să lucrăm la metoda de transfer al acestor date.
SAP oferă un număr considerabil de mecanisme de integrare. Dar cea mai simplă metodă – accesul direct la baza de date este interzis din cauza restricțiilor de licențiere. Astfel, toate fluxurile de integrare trebuie implementate la nivelul server aplicațiilor.
Următoarea problemă a fost absența datelor despre înregistrările șterse din baza de date SAP. Atunci când o linie este ștearsă din baza de date, aceasta este eliminată fizic. Adică, generarea unei delta a modificărilor în funcție de momentul modificării nu era posibilă.
Desigur, în SAP HCM există mecanisme pentru înregistrarea modificărilor datelor. De exemplu, pentru transmiterea ulterioară în sistemele primitoare, există puncte de modificare (change pointer), care înregistrează orice modificare și pe baza cărora se formează Idoc (obiect pentru transmiterea în sisteme externe).
Exemplu de modificare a infotype-ului 0302 pentru angajatul cu numărul de înregistrare 1251445:
Sau înregistrarea jurnalului modificărilor de date în tabela DBTABLOG.
Exemplu de jurnal pentru ștergerea înregistrării cu cheia QK53216375 din tabela hrp1000:
Însă aceste mecanisme nu sunt disponibile pentru toate datele necesare, iar procesarea lor la nivelul serverului de aplicații poate consuma destul de multe resurse. Prin urmare, activarea în masă a jurnalizării pentru toate tabelele necesare poate duce la o degradare semnificativă a performanței sistemului.
Următoarea problemă serioasă a fost tabelele cluster. Datele privind evaluarea timpului și calculul salariului în RDBMS versiunea SAP HCM sunt stocate sub formă de set de tabele logice pentru fiecare angajat pentru fiecare calcul. Aceste tabele logice sunt stocate sub formă de date binare în tabela pcl2.
Clusterul pentru calculul salariului:
Datele din tabelul cluster nu pot fi citite cu comenzi SQL, ci este necesară utilizarea macrocomenzilor SAP HCM sau modulelor funcționale speciale. Prin urmare, viteza de citire a acestor tabele va fi destul de mică. Pe de altă parte, în aceste clustere sunt stocate date care sunt necesare doar o dată pe lună – calculul final al salariului și evaluarea timpului. Astfel, viteza în acest caz nu este atât de critică.
Evaluând opțiunile pentru generarea delta-ului de modificare a datelor, s-a decis, de asemenea, să se examineze opțiunea cu export complet. Opțiunea de a transfera zilnic gigaocte de date neschimbate între sisteme nu poate părea plăcută. Cu toate acestea, are și o serie de avantaje – nu este necesară implementarea delta-ului pe partea sursă, precum și implementarea integrării acestui delta pe partea receptorului. Prin urmare, costurile și termenele de implementare scad, iar fiabilitatea integrării crește. A fost determinat că aproape toate modificările în SAP HR au loc în orizontul de trei luni până la data curentă. Astfel, s-a decis să ne oprim la exportul zilnic complet al datelor din SAP HR pentru N luni înainte de data curentă și la exportul complet lunar. Parametrul N depinde de tabela specifică
și variază de la 1 la 15.
Pentru extragerea datelor a fost propus următorul plan:
Sistemul extern formează o solicitare și o trimite către SAP HCM, unde această solicitare este verificată pentru completitudinea datelor și pentru permisiunile de acces la tabele. În cazul unei verificări reușite, în SAP HCM rulează un program care colectează datele necesare și le transmite în soluția de integrare Fuse. Fuse determină topicul necesar în Kafka și transmite datele acolo. Apoi, datele din Kafka sunt transmise în Stage Area GP.
În această lanț de procese, ne interesează problema extragerii datelor din SAP HCM. Să ne oprim mai în detaliu asupra acestui subiect.
Schema de interacțiune SAP HCM-FUSE.
Sistemul extern determină timpul ultimei solicitări reușite către SAP.
Procesul poate fi inițiat de un temporizator sau de un alt eveniment, inclusiv un timeout pentru așteptarea răspunsului cu date de la SAP și inițierea unei noi solicitări. După aceea, formează o solicitare de tip delta și o trimite către SAP.
Datele solicitării sunt transmise în corp în format json.
Metoda http: POST.
Exemplu de cerere:
Serviciul SAP efectuează un control al solicitării pentru completitudine, conformitate cu structura curentă SAP, și verifica existența permisiunii de acces la tabelul solicitat.
În cazul unor erori, serviciul returnează un răspuns cu codul și descrierea corespunzătoare. În cazul unui control reușit, acesta creează un proces în fundal pentru generarea selecției, genera și returna sincronizat un id unic al sesiunii.
Sistemul extern, în cazul unei erori, o înregistrează în jurnal. În cazul unui răspuns reușit, transmite id-ul sesiunii și numele tabelului pentru care a fost efectuată solicitarea.
Sistemul extern înregistrează sesiunea curentă ca fiind deschisă. Dacă există alte sesiuni pentru acest tabel, acestea sunt închise cu înregistrarea unui avertisment în jurnal.
Sarcina de fundal SAP formează un cursor pe baza unor parametrii specificați și un pachet de date de dimensiune specificată. Dimensiunea pachetului este numărul maxim de înregistrări pe care procesul le citește din baza de date. În mod implicit, se acceptă ca fiind 2000. Dacă în selecția bazei de date există mai multe înregistrări decât dimensiunea pachetului utilizat, după transmiterea primului pachet se formează următorul bloc cu offset-ul corespunzător și numărul pachetului incrementat. Numerele sunt incrementate cu 1 și trimise strict în ordine.
Apoi, SAP trimite pachetul către serviciul web al sistemului extern. Acesta din urmă efectuează verificări asupra pachetului recepționat. În sistem trebuie să fie înregistrată o sesiune cu ID-ul primit și aceasta trebuie să se afle în stare deschisă. Dacă numărul pachetului > 1, în sistem trebuie să fie înregistrată primirea cu succes a pachetului anterior (package_id-1).
În cazul unui control reușit, sistemul extern analizează și salvează datele din tabel.
În plus, dacă pachetul conține flag-ul final și serializarea a avut loc cu succes, se trimite o notificare modulului de integrare despre finalizarea reușită a procesării sesiunii, iar modulul actualizează starea sesiunii.
În cazul unei erori la verificări/analiză, eroarea este înregistrată, iar pachetele pentru această sesiune vor fi respinse de sistemul extern.
De asemenea, în cazul invers, când sistemul extern returnează o eroare, aceasta este înregistrată și transmiterea pachetelor este oprită.
Pentru solicitarea datelor din partea SAP HCM a fost realizat un serviciu de integrare. Serviciul este implementat pe cadrul ICF (SAP Internet Communication Framework - ). Acesta permite trimiterea de solicitări pentru date din sistemul SAP HCM pe anumite tabele. La formarea solicitării de date, există posibilitatea de a defini un set specific de câmpuri și parametrii de filtrare pentru a obține datele necesare. Implementarea serviciului nu presupune nicio logică de afaceri. Algoritmii de calcul al delta, parametrii cererii, verificarea integrității etc., sunt implementați în sistemul extern.
Acest mecanism permite colectarea și transmiterea tuturor datelor necesare în câteva ore. Această viteză se află la limita acceptabilității, de aceea această soluție este considerată temporară și a închis necesitatea unui instrument de extracție în cadrul proiectului.
În imaginea țintă pentru soluția de extracție a datelor sunt analizate opțiuni de utilizare a sistemelor CDC, precum Oracle Golden Gate, sau instrumente ETL cum ar fi SAP DS.
Sursa: habr.com
