Come sapete, SAP offre una gamma completa di software sia per il mantenimento dei dati transazionali che per l'elaborazione di questi dati nei sistemi di analisi e reporting. In particolare, la piattaforma SAP Business Warehouse (SAP BW) è un toolkit per l'archiviazione e l'analisi dei dati con ampie capacità tecniche. Nonostante tutti i suoi vantaggi oggettivi, il sistema SAP BW presenta uno svantaggio significativo. Si tratta di un costo elevato per l'archiviazione e l'elaborazione dei dati, particolarmente evidente quando si utilizza SAP BW basato su cloud su Hana.
Cosa succede se inizi a utilizzare un prodotto non SAP e preferibilmente un prodotto OpenSource come storage? Noi di X5 Retail Group abbiamo scelto GreenPlum. Questo, ovviamente, risolve il problema dei costi, ma allo stesso tempo sorgono immediatamente problemi che sono stati risolti quasi per impostazione predefinita quando si utilizza SAP BW.
In particolare, come recuperare i dati dai sistemi sorgente, che sono per lo più soluzioni SAP?
HR Metrics è stato il primo progetto in cui è stato necessario risolvere questo problema. Il nostro obiettivo era creare un archivio di dati sulle risorse umane e creare report analitici nell'area di lavoro con i dipendenti. In questo caso la principale fonte di dati è il sistema transazionale SAP HCM, nel quale vengono svolte tutte le attività personali, organizzative e retributive.
Estrazione dati
In SAP BW sono disponibili estrattori di dati standard per i sistemi SAP. Questi estrattori possono raccogliere automaticamente i dati necessari, monitorarne l'integrità e determinare i delta delle modifiche. Ecco, ad esempio, l'origine dati standard per gli attributi dei dipendenti 0EMPLOYEE_ATTR:
Il risultato dell'estrazione dei dati da esso per un dipendente:
Se necessario, tale estrattore può essere modificato per soddisfare le proprie esigenze oppure è possibile creare il proprio estrattore.
La prima idea che è venuta fuori è stata la possibilità di riutilizzarli. Sfortunatamente, questo si è rivelato un compito impossibile. La maggior parte della logica è implementata sul lato SAP BW e non è stato possibile separare in modo semplice l'estrattore alla fonte da SAP BW.
È diventato ovvio che avremmo dovuto sviluppare un nostro meccanismo per estrarre i dati dai sistemi SAP.
Struttura di archiviazione dei dati in SAP HCM
Per comprendere i requisiti di un tale meccanismo, dobbiamo prima determinare di quali dati abbiamo bisogno.
La maggior parte dei dati in SAP HCM viene archiviata in tabelle SQL flat. Sulla base di questi dati, le applicazioni SAP visualizzano all'utente strutture organizzative, dipendenti e altre informazioni sulle risorse umane. Ad esempio, ecco come appare la struttura organizzativa in SAP HCM:
Fisicamente, tale albero è memorizzato in due tabelle: negli oggetti hrp1000 e nelle connessioni tra questi oggetti in hrp1001.
Oggetti “Dipartimento 1” e “Ufficio 1”:
Relazione tra oggetti:
Può esserci un numero enorme di entrambi i tipi di oggetti e tipi di connessioni tra loro. Esistono sia connessioni standard tra gli oggetti che connessioni personalizzate per le vostre esigenze specifiche. Ad esempio, la relazione standard B012 tra un'unità organizzativa e una posizione a tempo pieno indica il capo di un dipartimento.
Visualizzazione del gestore in SAP:
Archiviazione in una tabella di database:
I dati dei dipendenti vengono archiviati nelle tabelle pa*. Ad esempio, i dati sugli eventi del personale per un dipendente sono archiviati nella tabella pa0000
Abbiamo deciso che GreenPlum prenderà dati "grezzi", vale a dire basta copiarli dalle tabelle SAP. E direttamente in GreenPlum verranno elaborati e convertiti in oggetti fisici (ad esempio Dipartimento o Dipendente) e metriche (ad esempio numero medio di dipendenti).
Sono state definite circa 70 tabelle i cui dati dovranno essere trasferiti a GreenPlum. Successivamente abbiamo iniziato a elaborare un metodo per trasmettere questi dati.
SAP offre un numero abbastanza elevato di meccanismi di integrazione. Ma il modo più semplice è che l’accesso diretto al database sia vietato a causa delle restrizioni di licenza. Pertanto, tutti i flussi di integrazione devono essere implementati a livello del server delle applicazioni.
Il problema successivo era la mancanza di dati sui record eliminati nel database SAP. Quando elimini una riga nel database, viene eliminata fisicamente. Quelli. non è stato possibile formare un delta di cambio in base al momento del cambio.
Naturalmente, SAP HCM dispone di meccanismi per la registrazione delle modifiche ai dati. Ad esempio per il successivo trasferimento ai sistemi riceventi esistono dei change pointer che registrano eventuali modifiche e sulla base dei quali viene formato un Idoc (un oggetto per il trasferimento a sistemi esterni).
Esempio IDoc per la modifica dell'infotype 0302 per un dipendente con numero personale 1251445:
Oppure mantenendo i registri delle modifiche ai dati nella tabella DBTABLOG.
Un esempio di log per eliminare un record con la chiave QK53216375 dalla tabella hrp1000:
Ma questi meccanismi non sono disponibili per tutti i dati necessari e la loro elaborazione a livello del server delle applicazioni può consumare molte risorse. Pertanto, abilitare in modo massiccio la registrazione su tutte le tabelle necessarie può portare a un notevole degrado delle prestazioni del sistema.
Il successivo grosso problema riguardava le tabelle in cluster. La stima del tempo e i dati sulle buste paga nella versione RDBMS di SAP HCM vengono archiviati come un insieme di tabelle logiche per ciascun dipendente per ciascun calcolo. Queste tabelle logiche vengono archiviate come dati binari nella tabella pcl2.
Gruppo buste paga:
I dati provenienti da tabelle cluster non possono essere considerati un comando SQL, ma richiedono l'uso di macro SAP HCM o moduli funzionali speciali. Di conseguenza, la velocità di lettura di tali tabelle sarà piuttosto bassa. D'altra parte, tali cluster memorizzano i dati necessari solo una volta al mese: buste paga finali e stima del tempo. Quindi la velocità in questo caso non è così critica.
Valutando le opzioni per formare un delta di modifiche ai dati, abbiamo deciso di considerare anche l'opzione di scarico completo. L'opzione di trasferire ogni giorno gigabyte di dati invariati tra sistemi potrebbe non sembrare buona. Tuttavia, presenta anche una serie di vantaggi: non è necessario implementare il delta sul lato sorgente e implementare l'incorporamento di questo delta sul lato ricevente. Di conseguenza, i costi e i tempi di implementazione si riducono e l’affidabilità dell’integrazione aumenta. Allo stesso tempo, è stato stabilito che quasi tutti i cambiamenti in SAP HR avvengono entro un orizzonte di tre mesi prima della data attuale. Pertanto, si è deciso di optare per un download completo giornaliero dei dati da SAP HR N mesi prima della data corrente e per un download completo mensile. Il parametro N dipende dalla tabella specifica
e varia da 1 a 15.
Per l’estrazione dei dati è stato proposto il seguente schema:
Il sistema esterno genera una richiesta e la invia a SAP HCM, dove viene verificata la completezza dei dati e le autorizzazioni per l'accesso alle tabelle di questa richiesta. Se la verifica ha esito positivo, SAP HCM esegue un programma che raccoglie i dati necessari e li trasferisce alla soluzione di integrazione Fuse. Fuse determina l'argomento richiesto in Kafka e trasferisce lì i dati. Successivamente, i dati di Kafka vengono trasferiti a Stage Area GP.
In questa catena, siamo interessati alla questione dell'estrazione dei dati da SAP HCM. Diamo un'occhiata più in dettaglio.
Diagramma di interazione SAP HCM-FUSE.
Il sistema esterno determina l'ora dell'ultima richiesta riuscita a SAP.
Il processo può essere avviato da un timer o da un altro evento, incluso un timeout per attendere una risposta con i dati da SAP e avviare una richiesta ripetuta. Quindi genera una richiesta delta e la invia a SAP.
I dati della richiesta vengono inviati al body in formato json.
Metodo http:POST.
Richiesta di esempio:
Il servizio SAP monitora la richiesta di completezza, conformità con l'attuale struttura SAP e disponibilità dei permessi di accesso alla tabella richiesta.
In caso di errori il servizio restituisce una risposta con il codice e la descrizione appropriati. Se il controllo ha esito positivo, crea un processo in background per generare un campione, genera e restituisce in modo sincrono un ID di sessione univoco.
In caso di errore, il sistema esterno lo registra nel log. In caso di risposta positiva trasmette l'id di sessione e il nome della tabella per la quale è stata effettuata la richiesta.
Il sistema esterno registra la sessione corrente come aperta. Se sono presenti altre sessioni per questa tabella, verranno chiuse con un avviso registrato.
Il processo in background SAP genera un cursore in base ai parametri specificati e a un pacchetto di dati della dimensione specificata. La dimensione batch è il numero massimo di record che un processo legge dal database. Per impostazione predefinita, si presuppone che sia uguale a 2000. Se nel campione del database sono presenti più record rispetto alla dimensione del pacchetto utilizzato, dopo aver trasmesso il primo pacchetto, viene formato il blocco successivo con il corrispondente offset e numero di pacchetto incrementato. I numeri vengono incrementati di 1 e inviati rigorosamente in sequenza.
Successivamente, SAP trasmette il pacchetto come input al servizio web del sistema esterno. E il sistema esegue controlli sul pacchetto in arrivo. Una sessione con l'ID ricevuto deve essere registrata nel sistema e deve essere in stato aperto. Se il numero del pacco > 1, il sistema dovrebbe registrare l'avvenuta ricezione del pacco precedente (pacchetto_id-1).
Se il controllo ha esito positivo, il sistema esterno analizza e salva i dati della tabella.
Inoltre, se nel pacchetto è presente il flag finale e la serializzazione ha avuto esito positivo, il modulo di integrazione viene informato del completamento corretto dell'elaborazione della sessione e il modulo aggiorna lo stato della sessione.
In caso di errore di controllo/analisi, l'errore viene registrato e i pacchetti per questa sessione verranno rifiutati dal sistema esterno.
Allo stesso modo, nel caso opposto, quando il sistema esterno restituisce un errore, questo viene registrato e la trasmissione dei pacchetti si interrompe.
Per richiedere i dati lato SAP HСM è stato implementato un servizio di integrazione. Il servizio è implementato su framework ICF (SAP Internet Communication Framework - ). Consente di interrogare i dati dal sistema SAP HCM utilizzando tabelle specifiche. Quando si crea una richiesta dati è possibile specificare un elenco di campi specifici e parametri di filtraggio per ottenere i dati necessari. Allo stesso tempo, l'implementazione del servizio non implica alcuna logica aziendale. Anche sul lato del sistema esterno sono implementati algoritmi per il calcolo del delta, parametri di query, monitoraggio dell’integrità, ecc.
Questo meccanismo permette di raccogliere e trasmettere in poche ore tutti i dati necessari. Questa velocità è quasi accettabile, quindi consideriamo questa soluzione temporanea, che ha permesso di soddisfare la necessità di uno strumento di estrazione nel progetto.
Nell'ottica di risolvere il problema dell'estrazione dei dati si stanno esplorando le opzioni per l'utilizzo di sistemi CDC come Oracle Golden Gate o strumenti ETL come SAP DS.
Fonte: habr.com