Come è noto, l'azienda SAP offre un'ampia gamma di software, sia per la gestione 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) rappresenta uno strumento per la memorizzazione e l'analisi dei dati, dotato di ampie capacità tecniche. Nonostante i suoi indiscutibili vantaggi, il sistema SAP BW presenta un notevole svantaggio: i costi elevati per la memorizzazione e l'elaborazione dei dati, particolarmente evidenti nell'uso del cloud SAP BW on Hana.
E se invece di utilizzare SAP si optasse per un prodotto non SAP, preferibilmente open source, come soluzione di archiviazione? Noi di X5 Retail Group abbiamo scelto GreenPlum. Questo, ovviamente, risolve il problema dei costi, ma solleva immediatamente interrogativi che con SAP BW venivano gestiti praticamente per impostazione predefinita.
In particolare, come prelevare i dati dai sistemi sorgente, che nella maggior parte dei casi sono soluzioni SAP?
«HR-Metrics» è stato il primo progetto in cui è stato necessario affrontare questo problema. Il nostro obiettivo era creare un repository di dati HR e sviluppare report analitici sulla gestione dei dipendenti. La principale fonte di dati è il sistema transazionale SAP HCM, dove vengono gestite tutte le attività relative al personale, all'organizzazione e alla retribuzione.
Estrazione dei dati
In SAP BW esistono estrattori di dati standard per i sistemi SAP. Questi estrattori possono raccogliere automaticamente i dati necessari, monitorarne l'integrità e determinare le variazioni. Ecco, ad esempio, la fonte di dati standard sugli attributi del dipendente 0EMPLOYEE_ATTR:
Risultato dell'estrazione dei dati da esso per un singolo dipendente:
Se necessario, tale estrattore può essere modificato in base alle proprie esigenze o può essere creato un estrattore personalizzato.
Per primo è sorto l'idea della possibilità di riutilizzarli. Sfortunatamente, si è rivelato un compito irrealizzabile. Gran parte della logica è implementata sul lato SAP BW, e non è stato possibile separare indolore l'estrattore dalla fonte da SAP BW.
È diventato evidente che sarà necessario sviluppare un meccanismo personalizzato per l'estrazione dei dati dai sistemi SAP.
Struttura di archiviazione dei dati in SAP HCM
Per comprendere i requisiti di tale meccanismo, è necessario prima determinare quali dati ci serviranno.
La maggior parte dei dati in SAP HCM è memorizzata in tabelle SQL flat. Sulla base di questi dati, le applicazioni SAP visualizzano agli utenti le strutture organizzative, i dipendenti e altre informazioni HR. Ad esempio, questa è come appare la struttura organizzativa in SAP HCM:
Fisicamente, un albero del genere è memorizzato in due tabelle: hrp1000 per gli oggetti e hrp1001 per le relazioni tra questi oggetti.
Oggetti "Dipartimento 1" e "Ufficio 1":
Relazione tra oggetti:
Ci possono essere un numero enorme sia di tipi di oggetti che di tipi di relazioni tra di essi. Esistono sia relazioni standard tra oggetti che personalizzate per esigenze specifiche. Ad esempio, la relazione standard B012 tra l'unità organizzativa e la posizione di personale indica il responsabile del dipartimento.
Visualizzazione del responsabile in SAP:
Memorizzazione nella tabella DB:
I dati sui dipendenti sono conservati nelle tabelle pa*. Ad esempio, i dati sulle attività del personale per un dipendente sono nella tabella pa0000.
Abbiamo deciso che GreenPlum preleverà i dati "grezzi", ovvero semplicemente copierà da tabelle SAP. Saranno quindi elaborati e trasformati in oggetti fisici (ad esempio, Reparto o Dipendente) e metriche (ad esempio, numero medio di dipendenti).
Sono state identificate circa 70 tabelle da cui è necessario trasferire i dati in GreenPlum. Dopo di che, abbiamo iniziato a lavorare sul metodo di trasferimento di questi dati.
SAP offre un numero significativo di meccanismi di integrazione. Tuttavia, il modo più semplice – l'accesso diretto al database – è vietato a causa di limitazioni di licenza. Pertanto, tutti i flussi di integrazione devono essere implementati a livello di server applicazioni.
Un altro problema era la mancanza di dati sulle registrazioni eliminate nel database SAP. Quando una riga viene eliminata nel database, viene fisicamente rimossa. Quindi, non è stato possibile generare il delta delle modifiche in base al tempo di modifica.
Certo, in SAP HCM ci sono meccanismi per la registrazione delle modifiche ai dati. Ad esempio, per il successivo trasferimento ai sistemi destinatari, esistono i puntatori di cambiamento (change pointer), che registrano qualsiasi modifica e sulla base dei quali vengono generati gli Idoc (oggetti per il trasferimento verso sistemi esterni).
Esempio di IDoc per la modifica dell'infotipo 0302 per il dipendente con numero di matricola 1251445:
Oppure la registrazione dei log delle modifiche nei dati nella tabella DBTABLOG.
Esempio di log per la cancellazione del record con chiave QK53216375 dalla tabella hrp1000:
Ma questi meccanismi non sono disponibili per tutti i dati necessari e il loro trattamento a livello del server applicazioni può consumare molte risorse. Pertanto, abilitare il logging su tutte le tabelle necessarie può portare a una significativa degradazione delle prestazioni del sistema.
Un'altra seria problematica sono state le tabelle cluster. I dati di stima del tempo e il calcolo degli stipendi nella versione RDBMS di SAP HCM sono archiviati come un insieme di tabelle logiche per ciascun dipendente per ogni calcolo. Queste tabelle logiche sono memorizzate come dati binari nella tabella pcl2.
Cluster di calcolo delle retribuzioni:
I dati delle tabelle cluster non possono essere letti tramite comandi SQL, ma richiedono l'uso di macro comandi SAP HCM o moduli funzionali speciali. Di conseguenza, la velocità di lettura di tali tabelle sarà piuttosto bassa. D'altra parte, in questi cluster vengono memorizzati dati necessari solo una volta al mese – il calcolo finale degli stipendi e la valutazione del tempo. Quindi, la velocità in questo caso non è così critica.
Valutando le opzioni per la creazione della delta dei dati, abbiamo deciso di considerare anche l'opzione del caricamento completo. Trasferire ogni giorno gigabyte di dati invariati tra i sistemi non può sembrare una soluzione elegante. Tuttavia, presenta alcuni vantaggi: non è necessaria né l'implementazione della delta sul lato sorgente, né l'integrazione di questa delta sul lato ricevente. Di conseguenza, si riducono i costi e i tempi di realizzazione, e si aumenta l'affidabilità dell'integrazione. È stato stabilito che praticamente tutte le modifiche in SAP HR avvengono nei tre mesi precedenti alla data attuale. Pertanto, è stata presa la decisione di fermarsi sul caricamento completo giornaliero dei dati da SAP HR per N mesi fino alla data attuale e su un caricamento completo mensile. Il parametro N dipende dalla specifica tabella.
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 questa richiesta viene controllata per la completezza dei dati e l'autorizzazione ad accedere alle tabelle. In caso di verifica positiva, in SAP HCM viene eseguito un programma che raccoglie i dati necessari e li invia alla soluzione di integrazione Fuse. Fuse determina il topic necessario in Kafka e vi trasferisce i dati. Successivamente, i dati da Kafka vengono inviati all'Area di Stage GP.
Nella presente catena ci interessa il tema dell'estrazione dei dati da SAP HCM. Approfondiamo questo aspetto.
Schema di interazione tra SAP HCM e FUSE.
Il sistema esterno determina l'ora dell'ultima richiesta riuscita a SAP.
Il processo può essere avviato tramite timer o altro evento, inclusa l'impostazione di un timeout per l'attesa di una risposta da SAP e l'inizio di una nuova richiesta. Dopodiché, genera la richiesta delle delta e la invia a SAP.
I dati della richiesta vengono trasmessi nel body in formato json.
Metodo http: POST.
Esempio di richiesta:
Il servizio SAP effettua il controllo della richiesta per completezza, conformità alla struttura attuale di SAP e disponibilità di autorizzazione per accedere alla tabella richiesta.
In caso di errori, il servizio restituisce una risposta con il codice e la descrizione corrispondenti. In caso di controllo riuscito, crea un processo in background per generare il campione, genera e restituisce sincronicamente un ID sessione unico.
Il sistema esterno, in caso di errore, lo registra nel log. In caso di risposta positiva, trasmette l'ID sessione e il nome della tabella su cui è stata effettuata la richiesta.
Il sistema esterno registra la sessione corrente come aperta. Se ci sono altre sessioni per questa tabella, vengono chiuse con registrazione di un avviso nel log.
Il job in background di SAP forma un cursore in base ai parametri forniti e un pacchetto di dati di dimensioni specificate. La dimensione del pacchetto è il numero massimo di record che il processo legge dal database. Di default è impostata a 2000. Se nel campione del database ci sono più record rispetto alla dimensione del pacchetto utilizzata, dopo la trasmissione del primo pacchetto viene generato un nuovo blocco con l'offset appropriato e il numero di pacchetto incrementato. I numeri vengono incrementati di 1 e inviati in modo strettamente sequenziale.
Successivamente, SAP invia il pacchetto al web service del sistema esterno. Questo sistema esegue i controlli necessari sul pacchetto in ingresso. Deve essere registrata una sessione nel sistema con l'ID ricevuto e questa deve trovarsi in stato aperto. Se il numero del pacchetto è maggiore di 1, deve essere registrata la ricezione riuscita del pacchetto precedente (package_id-1).
In caso di controllo riuscito, il sistema esterno analizza e salva i dati della tabella.
Inoltre, se nel pacchetto è presente il flag finale e la serializzazione è andata a buon fine, il modulo di integrazione viene informato del completamento riuscito della sessione e il modulo aggiorna lo stato della sessione.
In caso di errore nei controlli/analisi, l'errore viene registrato e i pacchetti per questa sessione saranno rifiutati dal sistema esterno.
Analogamente, se il sistema esterno restituisce un errore, questo viene registrato e la trasmissione dei pacchetti viene interrotta.
Per richiedere dati dal lato SAP HCM è stato implementato un servizio di integrazione. Il servizio è realizzato sul framework ICF (SAP Internet Communication Framework — ). Permette di effettuare richieste di dati dal sistema SAP HCM su specifiche tabelle. Durante la creazione della richiesta di dati, è possibile specificare un elenco di campi e parametri di filtraggio per ottenere i dati necessari. Tuttavia, l'implementazione del servizio non prevede alcuna logica di business. Gli algoritmi per il calcolo della delta, dei parametri di richiesta, del controllo dell'integrità, e altri sono anch'essi implementati sul lato del sistema esterno.
Questo meccanismo consente di raccogliere e trasmettere tutti i dati necessari in poche ore. Questa velocità è ai limiti della tollerabilità, quindi consideriamo questa soluzione come temporanea, che ha permesso di soddisfare la necessità di uno strumento di estrazione nel progetto.
Nella visione complessiva per affrontare la questione dell'estrazione dei dati, vengono esaminati l'uso di sistemi CDC come Oracle Golden Gate o strumenti ETL come SAP DS.
Fonte: habr.com
