Som du ved, tilbyder SAP et komplet udvalg af software både til vedligeholdelse af transaktionsdata og til behandling af disse data i analyse- og rapporteringssystemer. Specielt SAP Business Warehouse (SAP BW) platformen er et værktøjssæt til lagring og analyse af data med omfattende tekniske muligheder. På trods af alle dets objektive fordele har SAP BW-systemet en væsentlig ulempe. Dette er en høj omkostning ved lagring og behandling af data, især mærkbar, når du bruger cloud-baseret SAP BW på Hana.
Hvad hvis du begynder at bruge noget ikke-SAP og helst et OpenSource-produkt som lager? Vi hos X5 Retail Group valgte GreenPlum. Dette løser selvfølgelig spørgsmålet om omkostninger, men samtidig opstår der straks problemer, som nærmest blev løst som standard ved brug af SAP BW.
Især hvordan henter man data fra kildesystemer, som for det meste er SAP-løsninger?
HR Metrics var det første projekt, hvor det var nødvendigt at løse dette problem. Vores mål var at skabe et lager af HR-data og opbygge analytisk rapportering inden for arbejdet med medarbejdere. I dette tilfælde er hovedkilden til data SAP HCM transaktionssystemet, hvor alle personale-, organisations- og lønaktiviteter udføres.
Dataudtræk
I SAP BW er der standard dataudtrækkere til SAP-systemer. Disse ekstraktorer kan automatisk indsamle de nødvendige data, overvåge deres integritet og bestemme ændringsdeltaer. Her er for eksempel standarddatakilden for medarbejderattributter 0EMPLOYEE_ATTR:
Resultatet af at udtrække data fra det for en medarbejder:
Om nødvendigt kan en sådan udsugning modificeres, så den passer til dine egne krav, eller din egen udsugning kan oprettes.
Den første idé, der opstod, var muligheden for at genbruge dem. Det viste sig desværre at være en umulig opgave. Det meste af logikken er implementeret på SAP BW-siden, og det var ikke muligt smertefrit at adskille ekstraktoren ved kilden fra SAP BW.
Det blev tydeligt, at vi skulle udvikle vores egen mekanisme til at udtrække data fra SAP-systemer.
Datalagringsstruktur i SAP HCM
For at forstå kravene til en sådan mekanisme skal vi først bestemme, hvilke data vi har brug for.
De fleste data i SAP HCM er gemt i flade SQL-tabeller. Baseret på disse data visualiserer SAP-applikationer organisationsstrukturer, medarbejdere og anden HR-information til brugeren. For eksempel ser den organisatoriske struktur således ud i SAP HCM:
Fysisk er et sådant træ gemt i to tabeller - i hrp1000 objekter og i hrp1001 forbindelserne mellem disse objekter.
Objekter "Afdeling 1" og "Kontor 1":
Relation mellem objekter:
Der kan være et stort antal af begge typer objekter og typer forbindelser mellem dem. Der er både standardforbindelser mellem objekter og tilpassede til dine egne specifikke behov. For eksempel angiver standard B012-forholdet mellem en organisatorisk enhed og en fuldtidsstilling lederen af en afdeling.
Managervisning i SAP:
Lagring i en databasetabel:
Medarbejderdata gemmes i pa*-tabeller. For eksempel gemmes data om personalehændelser for en medarbejder i tabel pa0000
Vi besluttede, at GreenPlum vil tage "rå" data, dvs. bare kopier dem fra SAP-tabeller. Og direkte i GreenPlum vil de blive behandlet og konverteret til fysiske objekter (for eksempel afdeling eller medarbejder) og målinger (for eksempel gennemsnitligt antal ansatte).
Der blev defineret omkring 70 tabeller, hvorfra data skal overføres til GreenPlum. Hvorefter vi begyndte at udarbejde en metode til at overføre disse data.
SAP tilbyder et ret stort antal integrationsmekanismer. Men den nemmeste måde er, at direkte adgang til databasen er forbudt på grund af licensbegrænsninger. Alle integrationsflows skal således implementeres på applikationsserverniveau.
Det næste problem var manglen på data om slettede poster i SAP-databasen. Når du sletter en række i databasen, slettes den fysisk. De der. dannelsen af et ændringsdelta baseret på ændringstidspunktet var ikke mulig.
Selvfølgelig har SAP HCM mekanismer til registrering af dataændringer. For eksempel ved efterfølgende overførsel til modtagersystemer er der ændringspointere, der registrerer eventuelle ændringer, og på grundlag af hvilke der dannes en Idoc (et objekt til overførsel til eksterne systemer).
Eksempel IDoc til ændring af infotype 0302 for en medarbejder med personalenummer 1251445:
Eller føre logfiler over dataændringer i DBTABLOG-tabellen.
Et eksempel på en log til sletning af en post med nøglen QK53216375 fra hrp1000-tabellen:
Men disse mekanismer er ikke tilgængelige for alle nødvendige data, og deres behandling på applikationsserverniveau kan forbruge ret mange ressourcer. Derfor kan massiv aktivering af logning på alle nødvendige tabeller føre til en mærkbar forringelse af systemets ydeevne.
Det næste store problem var klyngede tabeller. Tidsestimering og løndata i RDBMS-versionen af SAP HCM gemmes som et sæt logiske tabeller for hver medarbejder for hver beregning. Disse logiske tabeller gemmes som binære data i tabel pcl2.
Lønklynge:
Data fra klyngede tabeller kan ikke betragtes som en SQL-kommando, men kræver brug af SAP HCM-makroer eller specielle funktionsmoduler. Følgelig vil læsehastigheden af sådanne tabeller være ret lav. På den anden side gemmer sådanne klynger data, der kun er nødvendige én gang om måneden - endelig løn og tidsestimering. Så hastigheden i dette tilfælde er ikke så kritisk.
Ved at evaluere mulighederne for at danne et delta af dataændringer besluttede vi også at overveje muligheden for fuld aflæsning. Muligheden for at overføre gigabyte uændrede data mellem systemer hver dag ser måske ikke godt ud. Det har dog også en række fordele - der er ingen grund til både at implementere deltaet på kildesiden og implementere indlejringen af dette delta på modtagersiden. Følgelig reduceres omkostningerne og implementeringstiden, og integrationens pålidelighed øges. Samtidig blev det fastslået, at næsten alle ændringer i SAP HR sker inden for en horisont på tre måneder før den aktuelle dato. Det blev således besluttet at vælge en daglig fuld download af data fra SAP HR N måneder før den aktuelle dato og en månedlig fuld download. N-parameteren afhænger af den specifikke tabel
og går fra 1 til 15.
Følgende ordning blev foreslået til dataudtræk:
Det eksterne system genererer en anmodning og sender den til SAP HCM, hvor denne anmodning kontrolleres for fuldstændighed af data og tilladelser til at få adgang til tabeller. Hvis kontrollen lykkes, kører SAP HCM et program, der indsamler de nødvendige data og overfører dem til Fuse integrationsløsningen. Fuse bestemmer det nødvendige emne i Kafka og overfører dataene dertil. Dernæst overføres dataene fra Kafka til Stage Area GP.
I denne kæde er vi interesserede i spørgsmålet om at udtrække data fra SAP HCM. Lad os se på det mere detaljeret.
SAP HCM-FUSE interaktionsdiagram.
Det eksterne system bestemmer tidspunktet for den sidste vellykkede anmodning til SAP.
Processen kan startes af en timer eller anden hændelse, herunder indstilling af en timeout for at vente på et svar med data fra SAP og starte en gentagelsesanmodning. Derefter genererer den en delta-anmodning og sender den til SAP.
Anmodningsdataene sendes til kroppen i json-format.
Metode http: POST.
Eksempel på anmodning:
SAP-tjenesten overvåger anmodningen om fuldstændighed, overholdelse af den aktuelle SAP-struktur og tilgængeligheden af adgangstilladelse til den anmodede tabel.
I tilfælde af fejl returnerer tjenesten et svar med den relevante kode og beskrivelse. Hvis kontrollen lykkes, opretter den en baggrundsproces til at generere en prøve, genererer og returnerer synkront et unikt sessions-id.
I tilfælde af en fejl, registrerer det eksterne system det i loggen. I tilfælde af et vellykket svar, transmitterer den sessions-id'et og navnet på den tabel, som anmodningen blev foretaget for.
Det eksterne system registrerer den aktuelle session som åben. Hvis der er andre sessioner for denne tabel, lukkes de med en advarsel logget.
SAP-baggrundsjobbet genererer en markør baseret på de angivne parametre og en datapakke af den angivne størrelse. Batchstørrelse er det maksimale antal poster, som en proces læser fra databasen. Som standard antages det at være lig med 2000. Hvis der er flere poster i databaseeksemplet end den anvendte pakkestørrelse, dannes den næste blok efter transmittering af den første pakke med den tilsvarende forskydning og inkrementerede pakkenummer. Tallene øges med 1 og sendes strengt sekventielt.
Dernæst sender SAP pakken som input til det eksterne systems webservice. Og systemet udfører kontroller på den indgående pakke. En session med det modtagne id skal registreres i systemet, og den skal være i åben status. Hvis pakkenummeret > 1, bør systemet registrere den vellykkede modtagelse af den forrige pakke (pakke_id-1).
Hvis kontrollen lykkes, parser og gemmer det eksterne system tabeldataene.
Derudover, hvis det endelige flag er til stede i pakken, og serialiseringen var vellykket, underrettes integrationsmodulet om den vellykkede afslutning af sessionsbehandlingen, og modulet opdaterer sessionsstatussen.
I tilfælde af en kontrol-/parsingsfejl logges fejlen, og pakker til denne session vil blive afvist af det eksterne system.
Ligeledes, i det modsatte tilfælde, når det eksterne system returnerer en fejl, logges det, og pakketransmission stopper.
For at anmode om data på SAP HСM-siden blev der implementeret en integrationstjeneste. Tjenesten er implementeret på ICF-rammeværket (SAP Internet Communication Framework - ). Det giver dig mulighed for at forespørge data fra SAP HCM-systemet ved hjælp af specifikke tabeller. Når du opretter en dataanmodning, er det muligt at angive en liste over specifikke felter og filtreringsparametre for at få de nødvendige data. Samtidig indebærer implementeringen af tjenesten ingen forretningslogik. Algoritmer til beregning af delta, forespørgselsparametre, integritetsovervågning osv. er også implementeret på siden af det eksterne system.
Denne mekanisme giver dig mulighed for at indsamle og overføre alle de nødvendige data på få timer. Denne hastighed er på grænsen til acceptabel, så vi betragter denne løsning som en midlertidig løsning, hvilket gjorde det muligt at udfylde behovet for et udvindingsværktøj på projektet.
I målbilledet, for at løse problemet med dataudtræk, undersøges muligheder for at bruge CDC-systemer såsom Oracle Golden Gate eller ETL-værktøjer såsom SAP DS.
Kilde: www.habr.com