Som du vet tilbyr SAP et komplett utvalg av programvare både for å vedlikeholde transaksjonsdata og for å behandle disse dataene i analyse- og rapporteringssystemer. Spesielt SAP Business Warehouse (SAP BW)-plattformen er et verktøysett for lagring og analyse av data med omfattende tekniske muligheter. For alle sine objektive fordeler har SAP BW-systemet en betydelig ulempe. Dette er en høy kostnad for lagring og behandling av data, spesielt merkbar når du bruker skybasert SAP BW på Hana.
Hva om du begynner å bruke noe ikke-SAP og helst et OpenSource-produkt som lagring? Vi i X5 Retail Group valgte GreenPlum. Dette løser selvfølgelig kostnadsproblemet, men samtidig oppstår det umiddelbart problemer som ble løst nesten som standard ved bruk av SAP BW.
Spesielt hvordan henter man data fra kildesystemer, som for det meste er SAP-løsninger?
HR Metrics var det første prosjektet der det var nødvendig å løse dette problemet. Målet vårt var å skape et depot av HR-data og bygge analytisk rapportering innen arbeidet med ansatte. I dette tilfellet er hovedkilden til dataene SAP HCM-transaksjonssystemet, der alle personell-, organisasjons- og lønnsaktiviteter utføres.
Datautvinning
I SAP BW er det standard datauttrekkere for SAP-systemer. Disse ekstraktorene kan automatisk samle inn nødvendige data, overvåke dens integritet og bestemme endringsdeltaer. Her er for eksempel standarddatakilden for ansattes attributter 0EMPLOYEE_ATTR:
Resultatet av å trekke ut data fra den for én ansatt:
Om nødvendig kan en slik avtrekker modifiseres for å passe dine egne krav eller din egen avtrekker kan opprettes.
Den første ideen som dukket opp var muligheten for å gjenbruke dem. Dessverre viste dette seg å være en umulig oppgave. Det meste av logikken er implementert på SAP BW-siden, og det var ikke mulig å smertefritt skille uttrekkeren ved kilden fra SAP BW.
Det ble åpenbart at vi måtte utvikle vår egen mekanisme for å trekke ut data fra SAP-systemer.
Datalagringsstruktur i SAP HCM
For å forstå kravene til en slik mekanisme, må vi først finne ut hvilke data vi trenger.
De fleste data i SAP HCM er lagret i flate SQL-tabeller. Basert på disse dataene visualiserer SAP-applikasjoner organisasjonsstrukturer, ansatte og annen HR-informasjon til brukeren. Slik ser for eksempel organisasjonsstrukturen ut i SAP HCM:
Fysisk er et slikt tre lagret i to tabeller - i hrp1000 objekter og i hrp1001 forbindelsene mellom disse objektene.
Objekter «Avdeling 1» og «Kontor 1»:
Forholdet mellom objekter:
Det kan være et stort antall av begge typer objekter og typer forbindelser mellom dem. Det er både standardkoblinger mellom objekter og tilpassede for dine egne spesifikke behov. For eksempel indikerer standard B012-forhold mellom en organisasjonsenhet og en heltidsstilling leder for en avdeling.
Ledervisning i SAP:
Lagring i en databasetabell:
Ansattdata lagres i pa*-tabeller. For eksempel lagres data om personalhendelser for en ansatt i tabell pa0000
Vi bestemte at GreenPlum skal ta «rå» data, dvs. bare kopier dem fra SAP-tabeller. Og direkte i GreenPlum vil de bli behandlet og konvertert til fysiske objekter (for eksempel avdeling eller ansatt) og beregninger (for eksempel gjennomsnittlig antall ansatte).
Det ble definert rundt 70 tabeller, hvorfra data må overføres til GreenPlum. Deretter begynte vi å utarbeide en metode for å overføre disse dataene.
SAP tilbyr et ganske stort antall integrasjonsmekanismer. Men den enkleste måten er at direkte tilgang til databasen er forbudt på grunn av lisensieringsbegrensninger. Dermed må alle integrasjonsflyter implementeres på applikasjonsservernivå.
Det neste problemet var mangelen på data om slettede poster i SAP-databasen. Når du sletter en rad i databasen, slettes den fysisk. De. dannelsen av et endringsdelta basert på endringstidspunktet var ikke mulig.
Selvfølgelig har SAP HCM mekanismer for å registrere dataendringer. For eksempel, for etterfølgende overføring til mottakersystemer, er det endringspekere som registrerer eventuelle endringer og på grunnlag av hvilke en Idoc dannes (et objekt for overføring til eksterne systemer).
Eksempel IDoc for endring av infotype 0302 for en ansatt med personalnummer 1251445:
Eller holde logger over dataendringer i DBTABLOG-tabellen.
Et eksempel på en logg for sletting av en post med nøkkelen QK53216375 fra hrp1000-tabellen:
Men disse mekanismene er ikke tilgjengelige for alle nødvendige data, og deres behandling på applikasjonsservernivå kan forbruke ganske mye ressurser. Derfor kan massiv aktivering av logging på alle nødvendige tabeller føre til en merkbar forringelse av systemytelsen.
Det neste store problemet var grupperte tabeller. Tidsestimat og lønnsdata i RDBMS-versjonen av SAP HCM lagres som et sett med logiske tabeller for hver ansatt for hver beregning. Disse logiske tabellene lagres som binære data i tabell pcl2.
Lønnsklynge:
Data fra grupperte tabeller kan ikke betraktes som en SQL-kommando, men krever bruk av SAP HCM-makroer eller spesielle funksjonsmoduler. Følgelig vil lesehastigheten til slike tabeller være ganske lav. På den annen side lagrer slike klynger data som er nødvendig kun én gang i måneden - endelig lønn og tidsberegning. Så hastighet i dette tilfellet er ikke så kritisk.
Ved å evaluere alternativene for å danne et delta av dataendringer, bestemte vi oss for å også vurdere muligheten for full lossing. Muligheten for å overføre gigabyte med uendret data mellom systemer hver dag ser kanskje ikke bra ut. Det har imidlertid også en rekke fordeler - det er ikke nødvendig å både implementere deltaet på kildesiden og implementere innbyggingen av dette deltaet på mottakersiden. Følgelig reduseres kostnadene og implementeringstiden, og integreringens pålitelighet øker. Samtidig ble det fastslått at nesten alle endringer i SAP HR skjer innenfor en horisont på tre måneder før dagens dato. Dermed ble det besluttet å velge en daglig full nedlasting av data fra SAP HR N måneder før gjeldende dato og en månedlig full nedlasting. N-parameteren avhenger av den spesifikke tabellen
og varierer fra 1 til 15.
Følgende ordning ble foreslått for datautvinning:
Det eksterne systemet genererer en forespørsel og sender den til SAP HCM, hvor denne forespørselen kontrolleres for fullstendighet av data og tillatelser til å få tilgang til tabeller. Hvis sjekken er vellykket, kjører SAP HCM et program som samler inn nødvendige data og overfører dem til Fuse-integrasjonsløsningen. Fuse bestemmer det nødvendige emnet i Kafka og overfører dataene dit. Deretter overføres dataene fra Kafka til Stage Area GP.
I denne kjeden er vi interessert i spørsmålet om å trekke ut data fra SAP HCM. La oss se på det mer detaljert.
SAP HCM-FUSE interaksjonsdiagram.
Det eksterne systemet bestemmer tidspunktet for den siste vellykkede forespørselen til SAP.
Prosessen kan startes av en tidtaker eller annen hendelse, inkludert å sette en timeout for å vente på svar med data fra SAP og starte en gjentatt forespørsel. Deretter genererer den en deltaforespørsel og sender den til SAP.
Forespørselsdataene sendes til kroppen i json-format.
Metode http: POST.
Eksempel på forespørsel:
SAP-tjenesten overvåker forespørselen om fullstendighet, samsvar med gjeldende SAP-struktur og tilgjengelighet av tilgangstillatelse til den forespurte tabellen.
Ved feil returnerer tjenesten et svar med riktig kode og beskrivelse. Hvis kontrollen er vellykket, oppretter den en bakgrunnsprosess for å generere en prøve, genererer og returnerer synkront en unik sesjons-ID.
Ved feil registrerer det eksterne systemet det i loggen. I tilfelle et vellykket svar, overfører den sesjons-IDen og navnet på tabellen som forespørselen ble gjort for.
Det eksterne systemet registrerer gjeldende økt som åpen. Hvis det er andre økter for denne tabellen, lukkes de med en advarsel logget.
SAP-bakgrunnsjobben genererer en markør basert på de spesifiserte parameterne og en datapakke med den angitte størrelsen. Batchstørrelse er det maksimale antallet poster som en prosess leser fra databasen. Som standard antas det å være lik 2000. Hvis det er flere poster i databaseeksemplet enn den brukte pakkestørrelsen, etter sending av den første pakken, dannes neste blokk med tilsvarende forskyvning og inkrementert pakkenummer. Tallene økes med 1 og sendes strengt sekvensielt.
Deretter sender SAP pakken som input til webtjenesten til det eksterne systemet. Og systemet utfører kontroller på den innkommende pakken. En økt med mottatt id må være registrert i systemet og den må være i åpen status. Hvis pakkenummeret > 1, bør systemet registrere den vellykkede mottakelsen av den forrige pakken (pakke_id-1).
Hvis kontrollen er vellykket, analyserer og lagrer det eksterne systemet tabelldataene.
I tillegg, hvis det endelige flagget er til stede i pakken og serialiseringen var vellykket, blir integrasjonsmodulen varslet om vellykket fullføring av sesjonsbehandlingen og modulen oppdaterer øktstatusen.
Ved en kontroll/parsefeil logges feilen og pakker for denne økten vil bli avvist av det eksterne systemet.
På samme måte, i motsatt tilfelle, når det eksterne systemet returnerer en feil, logges den og pakkeoverføring stopper.
For å be om data på SAP HСM-siden ble en integrasjonstjeneste implementert. Tjenesten er implementert på ICF-rammeverket (SAP Internet Communication Framework - ). Den lar deg spørre etter data fra SAP HCM-systemet ved å bruke spesifikke tabeller. Når du oppretter en dataforespørsel, er det mulig å spesifisere en liste over spesifikke felt og filtreringsparametere for å få de nødvendige dataene. Samtidig innebærer ikke implementeringen av tjenesten noen forretningslogikk. Algoritmer for beregning av delta, spørringsparametere, integritetsovervåking osv. er også implementert på siden av det eksterne systemet.
Denne mekanismen lar deg samle inn og overføre alle nødvendige data på noen få timer. Denne hastigheten er på grensen til akseptabel, så vi anser denne løsningen som en midlertidig, noe som gjorde det mulig å dekke behovet for et utvinningsverktøy på prosjektet.
I målbildet, for å løse problemet med datautvinning, utforskes alternativer for bruk av CDC-systemer som Oracle Golden Gate eller ETL-verktøy som SAP DS.
Kilde: www.habr.com