Comu sapete, SAP offre una gamma completa di software sia per mantene e dati transazzione sia per trasfurmà queste dati in sistemi di analisi è di rapportu. In particulare, a piattaforma SAP Business Warehouse (SAP BW) hè un toolkit per almacenà è analizà e dati cù capacità tecniche estensive. Per tutti i so vantaghji oggettivi, u sistema SAP BW hà un inconveniente significativu. Questu hè un altu costu di almacenamentu è trasfurmazioni di dati, soprattuttu notevuli quandu si usa SAP BW basatu in nuvola nantu à Hana.
E se cuminciassi à aduprà qualchì non-SAP è preferibile un pruduttu OpenSource cum'è almacenamiento? Avemu à X5 Retail Group hà sceltu GreenPlum. Questu, sicuru, risolve u prublema di u costu, ma à u stessu tempu, i prublemi sò subitu chì sò stati risolti quasi per difettu quandu si usa SAP BW.
In particulare, cumu ritruvà dati da i sistemi di fonte, chì sò principalmente suluzioni SAP?
HR Metrics era u primu prughjettu in quale era necessariu di risolve stu prublema. U nostru scopu era di creà un repository di dati HR è di custruisce rapporti analitici in l'area di travaglià cù l'impiegati. In questu casu, a fonti principale di dati hè u sistema transazionale SAP HCM, in quale tutte l'attività di u persunale, l'urganizazione è u salariu sò realizati.
Estrazione di dati
In SAP BW ci sò estrattori di dati standard per i sistemi SAP. Questi extractors ponu automaticamente raccoglie i dati necessarii, monitorizà a so integrità, è determinà cambiate deltas. Eccu, per esempiu, hè a fonte di dati standard per l'attributi di l'impiegati 0EMPLOYEE_ATTR:
U risultatu di l'estrazione di dati da ellu per un impiegatu:
Se necessariu, un tali extractor pò esse mudificatu per adattà à i vostri bisogni o u vostru propiu extractor pò esse creatu.
A prima idea chì nasce era a pussibilità di riutilizà. Sfurtunatamente, questu hè diventatu un compitu impussibile. A maiò parte di a logica hè implementata da u latu SAP BW, è ùn era micca pussibule di separà senza dolore l'estrattore à a fonte da SAP BW.
Hè diventatu evidenti chì avemu bisognu di sviluppà u nostru propiu mecanismu per l'estrazione di dati da i sistemi SAP.
Struttura di almacenamiento di dati in SAP HCM
Per capisce i requisiti per un tali mecanismu, avemu prima bisognu di determinà quale dati avemu bisognu.
A maiò parte di i dati in SAP HCM sò almacenati in tabelle SQL flat. Basatu nantu à questi dati, l'applicazioni SAP visualizeghjanu strutture organizzative, impiegati è altre informazioni HR à l'utilizatori. Per esempiu, questu hè ciò chì a struttura urganisazione pare in SAP HCM:
Fisicamente, un tali arbulu hè guardatu in dui tavulini - in hrp1000 oggetti è in hrp1001 i ligami trà questi ogetti.
Oggetti "Dipartimentu 1" è "Uffiziu 1":
Relazione trà l'uggetti:
Ci pò esse un gran numaru di dui tipi d'uggetti è tipi di cunnessione trà elli. Ci sò dui cunnessione standard trà l'uggetti è quelli persunalizati per i vostri bisogni specifichi. Per esempiu, a relazione standard B012 trà una unità urganisazione è un postu full-time indica u capu di un dipartimentu.
Display Manager in SAP:
Storage in una tabella di basa di dati:
I dati di l'impiegati sò almacenati in tabelle pa*. Per esempiu, i dati nantu à l'avvenimenti di u persunale per un impiigatu sò guardati in a table pa0000
Avemu decisu chì GreenPlum pigliarà dati "crudi", i.e. basta copiate da e tabelle SAP. È direttamente in GreenPlum seranu trasfurmati è cunvertiti in oggetti fisichi (per esempiu, Dipartimentu o Impiegatu) è metriche (per esempiu, u numeru mediu).
Circa 70 tavule sò state definite, dati da quale deve esse trasferitu à GreenPlum. Dopu chì avemu cuminciatu à travaglià un metudu per trasmette sta dati.
SAP offre un numeru abbastanza grande di meccanismi di integrazione. Ma u modu più faciule hè chì l'accessu direttu à a basa di dati hè pruibitu per via di restrizioni di licenza. Cusì, tutti i flussi di integrazione devenu esse implementati à u livellu di u servitore di l'applicazione.
U prublema dopu era a mancanza di dati nantu à i registri eliminati in a basa di dati SAP. Quandu sguassate una fila in a basa di dati, hè sguassata fisicamente. Quelli. a furmazione di un delta di cambiamentu basatu annantu à u tempu di cambiamentu ùn era micca pussibule.
Di sicuru, SAP HCM hà meccanismi per registrà cambiamenti di dati. Per esempiu, per u trasferimentu sussegwente à i sistemi di destinatariu, ci sò punters di cambiamentu chì registranu ogni cambiamentu è nantu à a basa di quale hè furmatu un Idoc (un ughjettu per u trasferimentu à i sistemi esterni).
Esempiu IDoc per cambià l'infotipu 0302 per un impiigatu cù u numeru di persunale 1251445:
O mantene logs di cambiamenti di dati in a tavola DBTABLOG.
Un esempiu di un logu per sguassà un registru cù a chjave QK53216375 da a tavola hrp1000:
Ma sti miccanismi ùn sò micca dispunibili per tutti i dati necessarii, è u so processu à u livellu di u servitore di l'applicazioni pò cunsumà assai risorse. Per quessa, l'attivazione massiva di logging in tutte e tavule necessarie pò purtà à una degradazione notevuli di u rendiment di u sistema.
U prossimu prublema maiò era tavule clustered. L'estimazione di u tempu è i dati di paga in a versione RDBMS di SAP HCM sò guardati cum'è un inseme di tabelle logiche per ogni impiigatu per ogni calculu. Queste tabelle logiche sò guardate cum'è dati binari in a table pcl2.
Cluster Payroll:
I dati da e tavule raggruppate ùn ponu micca esse cunsideratu cum'è un cumandamentu SQL, ma esige l'usu di macros SAP HCM o moduli funziunali speciali. Per quessa, a velocità di lettura di tali tavule serà abbastanza bassu. Per d 'altra banda, tali clusters almacenanu dati chì sò necessarii solu una volta à u mese - stimi finali di paga è tempu. Allora a velocità in questu casu ùn hè micca cusì critica.
Evaluendu l'opzioni per furmà un delta di cambiamenti di dati, avemu decisu di cunsiderà ancu l'opzione di scaricamentu cumpletu. L'opzione di trasferimentu di gigabytes di dati invariati trà i sistemi ogni ghjornu ùn pò micca vede bè. Tuttavia, hà ancu una quantità di vantaghji - ùn hè micca bisognu di implementà u delta da u latu di a fonte è di implementà l'incrustazione di stu delta da u latu di u receptore. Per quessa, u costu è u tempu di implementazione sò ridotti, è l'affidabilità di l'integrazione aumenta. À u listessu tempu, hè statu determinatu chì quasi tutti i cambiamenti in SAP HR sò in un orizzonte di trè mesi prima di a data attuale. Cusì, hè statu decisu di optà per una scaricamentu cumpletu ogni ghjornu di dati da SAP HR N mesi prima di a data attuale è una scaricamentu mensuale cumpletu. U paràmetru N dipende da a tabella specifica
è varia da 1 à 15.
U schema seguente hè statu prupostu per l'estrazione di dati:
U sistema esternu genera una dumanda è l'invia à SAP HCM, induve sta dumanda hè verificata per completezza di dati è permessi per accede à e tavule. Se u cuntrollu hè successu, SAP HCM eseguisce un prugramma chì raccoglie i dati necessarii è u trasferisce à a suluzione di integrazione Fuse. Fuse determina u tema necessariu in Kafka è trasferisce i dati quì. Dopu, i dati da Kafka sò trasferiti à Stage Area GP.
In questa catena, avemu interessatu in u prublema di estrazione di dati da SAP HCM. Fighjemu in più detail.
Diagramma di interazione SAP HCM-FUSE.
U sistema esternu determina l'ora di l'ultima dumanda successu à SAP.
U prucessu pò esse lanciatu da un timer o un altru avvenimentu, cumpresu stabilisce un timeout per aspittà una risposta cù dati da SAP è inizià una dumanda ripetuta. Allora genera una dumanda delta è l'invia à SAP.
I dati di dumanda sò mandati à u corpu in formatu json.
Metudu http: POST.
Esempiu di dumanda:
U serviziu SAP monitoreghja a dumanda di cumpletu, rispettu di a struttura SAP attuale, è dispunibilità di permessu di accessu à a tavola dumandata.
In casu d'errore, u serviziu torna una risposta cù u codice appropritatu è a descrizzione. Se u cuntrollu hè successu, crea un prucessu di fondo per generà una mostra, genera è torna in modu sincronu un ID di sessione unicu.
In casu d'errore, u sistema esternu registra in u logu. In casu di una risposta riescita, trasmette l'id di sessione è u nome di a tavola per a quale a dumanda hè stata fatta.
U sistema esternu registra a sessione attuale cum'è aperta. Se ci sò altre sessioni per questa tabella, sò chjusi cù un avvisu registratu.
U travagliu di fondo SAP genera un cursore basatu annantu à i paràmetri specificati è un pacchettu di dati di a dimensione specifica. A dimensione di batch hè u numeru massimu di registri chì un prucessu leghje da a basa di dati. Per automaticamente, hè assuciatu à esse uguali à 2000. Se ci sò più records in a mostra di basa di dati chì a dimensione di u pacchettu utilizatu, dopu a trasmissione di u primu pacchettu, u prossimu blocu hè furmatu cù u numeru di pacchettu currispundenti è aumentatu. I numeri sò aumentati da 1 è mandati strettamente sequenziale.
Dopu, SAP passa u pacchettu cum'è input à u serviziu web di u sistema esternu. È u sistema esegue cuntrolli nantu à u pacchettu in entrata. Una sessione cù l'id ricevutu deve esse registrata in u sistema è deve esse in u statu apertu. Se u numeru di pacchettu> 1, u sistema deve registrà a ricezione successu di u pacchettu precedente (package_id-1).
Se u cuntrollu hè successu, u sistema esternu analizza è salva i dati di a tavola.
Inoltre, se a bandiera finale hè presente in u pacchettu è a serializazione hè stata riescita, u modulu di integrazione hè notificatu annantu à a fine di u prucessu di sessione è u modulu aghjurnà u statutu di a sessione.
In casu di un errore di cuntrollu / analisi, l'errore hè registratu è i pacchetti per sta sessione seranu rifiutati da u sistema esternu.
Inoltre, in u casu cuntrariu, quandu u sistema esternu torna un errore, hè registratu è a trasmissione di pacchetti si ferma.
Per dumandà dati nantu à u latu SAP HСM, hè statu implementatu un serviziu di integrazione. U serviziu hè implementatu nantu à u framework ICF (SAP Internet Communication Framework - ). Permette di dumandà dati da u sistema SAP HCM utilizendu tavule specifiche. Quandu crea una dumanda di dati, hè pussibule specificà una lista di campi specifichi è parametri di filtrazione per ottene e dati necessarii. À u listessu tempu, l'implementazione di u serviziu ùn implica micca una logica cummerciale. L'algoritmi per u calculu di delta, i paràmetri di quistione, u monitoraghju di l'integrità, etc. sò ancu implementati da u latu di u sistema esternu.
Stu mekanismu vi permette di cullà è trasmette tutti i dati nicissariu in uni pochi ore. Questa velocità hè in u puntu di accettabile, cusì cunsideremu sta suluzione cum'è una pruvisoria, chì hà permessu di cumpensà a necessità di un strumentu d'estrazione nantu à u prugettu.
In a stampa di destinazione, per risolve u prublema di l'estrazione di dati, l'opzioni per l'usu di sistemi CDC cum'è Oracle Golden Gate o strumenti ETL cum'è SAP DS sò stati esplorati.
Source: www.habr.com