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) è uno strumento per l'archiviazione e l'analisi dei dati, dotato di ampie capacità tecniche. Nonostante i suoi oggettivi vantaggi, il sistema SAP BW presenta un'importante svantaggio. Si tratta dell'elevato costo di archiviazione e elaborazione dei dati, particolarmente evidente quando si utilizza SAP BW on Hana in cloud.
E se si iniziasse a utilizzare un prodotto non-SAP, preferibilmente OpenSource, come archiviazione? Noi di X5 Retail Group abbiamo scelto GreenPlum. Questo risolve sicuramente la questione dei costi, ma sorgono immediatamente delle domande che con SAP BW venivano quasi risolte per default.
In particolare, come prelevare i dati dai sistemi sorgente, che per la maggior parte sono soluzioni SAP?
«HR-metriche» è stato il primo progetto in cui è stata affrontata questa problematica. Il nostro obiettivo era creare un repository di dati HR e costruire report di analisi sul lavoro con i dipendenti. In questo caso, la principale fonte di dati è il sistema transazionale SAP HCM, che gestisce 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. Ad esempio, la fonte di dati standard per gli attributi del dipendente 0EMPLOYEE_ATTR:
Il 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 prima cosa è nata l'idea di riutilizzarli. Sfortunatamente, si è rivelata un compito irrealizzabile. La maggior parte della logica è implementata lato SAP BW e separare indolore l'estrattore dalla fonte da SAP BW non è stato possibile.
È diventato chiaro che era necessaria la creazione di un proprio meccanismo di estrazione dei dati dai sistemi SAP.
Struttura di archiviazione dei dati in SAP HCM
Per comprendere i requisiti di un meccanismo del genere, è necessario innanzitutto definire quali dati ci serviranno.
La maggior parte dei dati in SAP HCM è memorizzata in tabelle SQL semplici. Sulla base di questi dati, le applicazioni SAP visualizzano all'utente le strutture organizzative, i dipendenti e altre informazioni HR. Ad esempio, ecco come appare la struttura organizzativa in SAP HCM:
Fisicamente, questo albero è memorizzato in due tabelle: hrp1000 per gli oggetti e hrp1001 per le relazioni tra questi oggetti.
Oggetti "Dipartimento 1" e "Direzione 1":
Relazione tra gli oggetti:
Ci può essere un numero enorme di tipi di oggetti e 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 unità organizzative e posizioni lavorative indica il responsabile del dipartimento.
Visualizzazione del responsabile in SAP:
Memorizzazione nella tabella del database:
I dati dei dipendenti sono memorizzati nelle tabelle pa*. Ad esempio, i dati sugli eventi di personale per un dipendente sono memorizzati nella tabella pa0000.
Abbiamo deciso che GreenPlum avrebbe prelevato i dati "grezzi", cioè semplicemente copiandoli dalle tabelle SAP. E solo in GreenPlum verranno elaborati e trasformati in oggetti fisici (ad esempio, Dipartimento o Dipendente) e metriche (ad esempio, numero medio di dipendenti).
Sono state identificate circa 70 tabelle da cui è necessario trasferire i dati a GreenPlum. Dopodiché, abbiamo iniziato a studiare il modo di trasferire questi dati.
SAP offre un numero piuttosto elevato di meccanismi di integrazione. Ma il modo più semplice – l'accesso diretto al database è vietato a causa di restrizioni di licenza. Pertanto, tutti i flussi di integrazione devono essere implementati a livello di server applicazioni.
Il problema successivo era l'assenza di dati sulle registrazioni eliminate nel database SAP. Quando una riga viene eliminata nel database, essa viene effettivamente cancellata. Cioè, non era possibile generare delta delle modifiche nel tempo delle modifiche.
Naturalmente, in SAP HCM ci sono meccanismi per la registrazione delle modifiche dei dati. Ad esempio, per la successiva trasmissione ai sistemi di destinazione esistono puntatori di modifica (change pointer), che registrano qualsiasi modifica e sulla base dei quali vengono formati gli Idoc (oggetto per la trasmissione a sistemi esterni).
Esempio di modifica del tipo di infotipo 0302 per un dipendente con il numero di busta paga 1251445:
Oppure la registrazione dei log delle modifiche ai dati nella tabella DBTABLOG.
Esempio di log per l'eliminazione di una registrazione con chiave QK53216375 dalla tabella hrp1000:
Tuttavia, questi meccanismi non sono disponibili per tutti i dati necessari e il loro trattamento a livello del server applicativo può richiedere molte risorse. Pertanto, l'attivazione massiccia del logging su tutte le tabelle necessarie può portare a un notevole degrado delle prestazioni del sistema.
Un altro serio problema riguardava le tabelle cluster. I dati relativi alla stima del tempo e al calcolo della retribuzione nella versione RDBMS di SAP HCM sono memorizzati come un insieme di tabelle logiche per ogni dipendente per ogni calcolo. Queste tabelle logiche sono memorizzate in forma binaria nella tabella pcl2.
Cluster per il calcolo della retribuzione:
I dati delle tabelle cluster non possono essere letti con un comando SQL; è necessario utilizzare i macro comandi di SAP HCM o moduli funzionali speciali. Pertanto, la velocità di lettura di tali tabelle sarà piuttosto bassa. D'altra parte, in questi cluster sono memorizzati dati necessari solo una volta al mese – il calcolo finale della retribuzione e la stima del tempo. Quindi la velocità in questo caso non è così critica.
Valutando le opzioni per la generazione della delta delle modifiche ai dati, si è deciso di considerare anche l'opzione di un'estrazione completa. L'idea di trasferire gigabyte di dati invariati tra i sistemi ogni giorno non appare molto allettante. Tuttavia, ha alcuni vantaggi: non è necessario implementare la delta lato sorgente e nemmeno integrarla lato ricevente. Di conseguenza, i costi e i tempi di implementazione si riducono, migliorando l'affidabilità dell'integrazione. È stato inoltre stabilito che praticamente tutte le modifiche in SAP HR avvengono entro un orizzonte di tre mesi dalla data attuale. Pertanto, si è deciso di procedere con un'estrazione completa giornaliera dei dati da SAP HR per N mesi dalla data attuale e con un'estrazione completa mensile. Il parametro N dipende dalla specifica tabella
e varia da 1 a 15.
È stato proposto il seguente schema per l'estrazione dei dati:
Il sistema esterno genera una richiesta e la invia a SAP HCM, dove questa richiesta viene controllata per completezza dei dati e diritti di accesso 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 Stage GP.
In questa catena, ci interessa la questione dell'estrazione dei dati da SAP HCM. Approfondiamo questo aspetto.
Schema di interazione tra SAP HCM e FUSE.
Il sistema esterno determina l'orario dell'ultima richiesta riuscita a SAP.
Il processo può essere avviato da un timer o da un altro evento, inclusa l'impostazione di un timeout in attesa della risposta con i dati da SAP e l'inizializzazione di una richiesta ripetuta. Successivamente, viene generata una richiesta di differenza e inviata a SAP.
I dati della richiesta vengono trasmessi nel corpo in formato json.
Metodo http: POST.
Esempio di richiesta:
Il servizio SAP controlla la richiesta per completezza, corrispondenza con la struttura attuale di SAP e presenza di autorizzazione per accedere alla tabella richiesta.
In caso di errori, il servizio restituisce una risposta con il codice corrispondente e una descrizione. In caso di controllo positivo, crea un processo in background per la generazione del campione, genera e restituisce sincronicamente un id unico della sessione.
Il sistema esterno, in caso di errore, lo registra nel registro. In caso di risposta positiva, trasmette l'id della sessione e il nome della tabella da 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 registro.
Il compito in background di SAP genera un cursore in base ai parametri specificati e un pacchetto di dati di dimensioni specificate. La dimensione del pacchetto è il numero massimo di record che il processo legge dal DB. Per impostazione predefinita, è fissata a 2000. Se ci sono più record nel campione del DB rispetto alla dimensione del pacchetto utilizzato, dopo la trasmissione del primo pacchetto, viene generato il blocco successivo con l'offset corrispondente e il numero di pacchetto incrementato. I numeri vengono incrementati di 1 e inviati in modo rigorosamente sequenziale.
Successivamente, SAP invia il pacchetto al web service del sistema esterno. Questo sistema esegue i controlli sul pacchetto in ingresso. Deve essere registrata una sessione con l'id ricevuto e deve trovarsi in stato aperto. Se il numero del pacchetto è > 1, deve essere registrata la ricezione avvenuta con successo del pacchetto precedente (package_id-1).
In caso di controllo positivo, il sistema esterno analizza e salva i dati della tabella.
Inoltre, se nel pacchetto è presente il flag final e la serializzazione è avvenuta con successo, si notifica il modulo di integrazione del completamento positivo dell'elaborazione 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.
Allo stesso modo, nel caso in cui il sistema esterno restituisca un errore, viene registrato e la trasmissione dei pacchetti viene interrotta.
Per la richiesta di dati sul lato SAP HCM è stato realizzato un servizio di integrazione. Il servizio è implementato sulla piattaforma ICF (SAP Internet Communication Framework - ). Permette di richiedere dati dal sistema SAP HCM da specifiche tabelle. Durante la formazione della richiesta di dati, è possibile specificare un elenco di campi specifici e parametri di filtraggio per ottenere i dati necessari. L'implementazione del servizio non prevede alcuna logica di business. Gli algoritmi di calcolo della delta, dei parametri della richiesta, dei controlli di integrità, ecc., 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à è al limite dell'accettabile, quindi questa soluzione è considerata temporanea e ha permesso di soddisfare la necessità di uno strumento di estrazione nel progetto.
Nella visione target per affrontare la questione dell'estrazione dei dati, vengono esaminate le opzioni per l'uso di sistemi CDC come Oracle Golden Gate o strumenti ETL come SAP DS.
Fonte: habr.com
