Som ni vet erbjuder SAP ett komplett utbud av mjukvara både för att underhålla transaktionsdata och för att bearbeta dessa data i analys- och rapporteringssystem. I synnerhet SAP Business Warehouse (SAP BW)-plattformen är en verktygslåda för att lagra och analysera data med omfattande tekniska möjligheter. Trots alla objektiva fördelar har SAP BW-systemet en betydande nackdel. Detta är en hög kostnad för att lagra och bearbeta data, särskilt märkbar när du använder molnbaserad SAP BW på Hana.
Vad händer om du börjar använda någon icke-SAP och helst en OpenSource-produkt som lagring? Vi på X5 Retail Group valde GreenPlum. Detta löser naturligtvis kostnadsfrågan, men samtidigt uppstår omedelbart problem som löstes nästan som standard vid användning av SAP BW.
I synnerhet, hur hämtar man data från källsystem, som mestadels är SAP-lösningar?
HR Metrics var det första projektet där det var nödvändigt att lösa detta problem. Vårt mål var att skapa ett förråd av HR-data och bygga analytisk rapportering inom området arbete med anställda. I det här fallet är den huvudsakliga datakällan SAP HCM transaktionssystemet, där all personal, organisation och löneaktiviteter utförs.
Dataextraktion
I SAP BW finns standarddataextraktorer för SAP-system. Dessa extraktorer kan automatiskt samla in nödvändig data, övervaka dess integritet och bestämma förändringsdelta. Här är till exempel standarddatakällan för anställdas attribut 0EMPLOYEE_ATTR:
Resultatet av att extrahera data från det för en anställd:
Vid behov kan en sådan utsug modifieras för att passa dina egna krav eller så kan din egen utsug skapas.
Den första idén som uppstod var möjligheten att återanvända dem. Tyvärr visade sig detta vara en omöjlig uppgift. Det mesta av logiken är implementerad på SAP BW-sidan, och det var inte möjligt att smärtfritt separera extraktorn vid källan från SAP BW.
Det blev uppenbart att vi skulle behöva utveckla vår egen mekanism för att extrahera data från SAP-system.
Datalagringsstruktur i SAP HCM
För att förstå kraven för en sådan mekanism måste vi först bestämma vilken data vi behöver.
De flesta data i SAP HCM lagras i platta SQL-tabeller. Baserat på dessa data visualiserar SAP-applikationer organisationsstrukturer, anställda och annan HR-information för användaren. Så här ser till exempel organisationsstrukturen ut i SAP HCM:
Fysiskt lagras ett sådant träd i två tabeller - i hrp1000-objekt och i hrp1001 kopplingarna mellan dessa objekt.
Objekt "Avdelning 1" och "Kontor 1":
Relation mellan objekt:
Det kan finnas ett stort antal av båda typerna av objekt och typer av kopplingar mellan dem. Det finns både standardkopplingar mellan objekt och skräddarsydda för dina egna specifika behov. Till exempel anger standard B012-relationen mellan en organisatorisk enhet och en heltidstjänst chef för en avdelning.
Chefsvisning i SAP:
Lagring i en databastabell:
Personaldata lagras i pa*-tabeller. Till exempel lagras data om personalhändelser för en anställd i tabell pa0000
Vi beslutade att GreenPlum ska ta "rå" data, d.v.s. kopiera dem bara från SAP-tabeller. Och direkt i GreenPlum kommer de att bearbetas och omvandlas till fysiska objekt (till exempel avdelning eller anställd) och mätvärden (till exempel genomsnittligt antal anställda).
Ett 70-tal tabeller definierades, från vilka data måste överföras till GreenPlum. Därefter började vi utarbeta en metod för att överföra dessa data.
SAP erbjuder ett ganska stort antal integrationsmekanismer. Men det enklaste sättet är att direktåtkomst till databasen är förbjuden på grund av licensbegränsningar. Alltså måste alla integrationsflöden implementeras på applikationsservernivå.
Nästa problem var bristen på data om raderade poster i SAP-databasen. När du tar bort en rad i databasen raderas den fysiskt. De där. bildandet av ett förändringsdelta baserat på tidpunkten för förändringen var inte möjligt.
Naturligtvis har SAP HCM mekanismer för att registrera dataändringar. Till exempel för efterföljande överföring till mottagarsystem finns ändringspekare som registrerar eventuella ändringar och på basis av vilka en Idoc bildas (ett objekt för överföring till externa system).
Exempel IDoc för att ändra infotyp 0302 för en anställd med personalnummer 1251445:
Eller föra loggar över dataändringar i DBTABLOG-tabellen.
Ett exempel på en logg för att radera en post med nyckeln QK53216375 från hrp1000-tabellen:
Men dessa mekanismer är inte tillgängliga för all nödvändig data, och deras bearbetning på applikationsservernivå kan förbruka ganska mycket resurser. Att massivt möjliggöra inloggning på alla nödvändiga tabeller kan därför leda till en märkbar försämring av systemets prestanda.
Nästa stora problem var klustrade tabeller. Tidsuppskattning och lönedata i RDBMS-versionen av SAP HCM lagras som en uppsättning logiska tabeller för varje anställd för varje beräkning. Dessa logiska tabeller lagras som binära data i tabell pcl2.
Lönekluster:
Data från klustrade tabeller kan inte betraktas som ett SQL-kommando, utan kräver användning av SAP HCM-makron eller speciella funktionsmoduler. Följaktligen kommer läshastigheten för sådana tabeller att vara ganska låg. Å andra sidan lagrar sådana kluster data som bara behövs en gång i månaden - slutlig lönelista och tidsuppskattning. Så hastigheten i det här fallet är inte så kritisk.
Genom att utvärdera alternativen för att bilda ett delta av dataförändringar bestämde vi oss för att också överväga alternativet för full avlastning. Alternativet att överföra gigabyte med oförändrad data mellan system varje dag kanske inte ser bra ut. Det har dock också ett antal fördelar - det finns inget behov av att både implementera deltat på källsidan och implementera inbäddningen av detta delta på mottagarsidan. Följaktligen reduceras kostnaden och implementeringstiden, och integrationens tillförlitlighet ökar. Samtidigt fastställdes att nästan alla förändringar i SAP HR sker inom en horisont på tre månader före det aktuella datumet. Därför beslutades det att välja en daglig fullständig nedladdning av data från SAP HR N månader före det aktuella datumet och en månatlig full nedladdning. N-parametern beror på den specifika tabellen
och sträcker sig från 1 till 15.
Följande schema föreslogs för dataextraktion:
Det externa systemet genererar en förfrågan och skickar den till SAP HCM, där denna förfrågan kontrolleras med avseende på fullständiga data och behörigheter att komma åt tabeller. Om kontrollen lyckas kör SAP HCM ett program som samlar in nödvändig data och överför den till Fuse-integrationslösningen. Fuse bestämmer det nödvändiga ämnet i Kafka och överför data dit. Därefter överförs data från Kafka till Stage Area GP.
I denna kedja är vi intresserade av frågan om att extrahera data från SAP HCM. Låt oss titta på det mer detaljerat.
SAP HCM-FUSE interaktionsdiagram.
Det externa systemet bestämmer tidpunkten för den senaste lyckade begäran till SAP.
Processen kan startas av en timer eller annan händelse, inklusive att ställa in en timeout för att vänta på ett svar med data från SAP och initiera en upprepad begäran. Sedan genererar den en delta-förfrågan och skickar den till SAP.
Begäran data skickas till kroppen i json-format.
Metod http: POST.
Exempelbegäran:
SAP-tjänsten övervakar begäran om fullständighet, överensstämmelse med den aktuella SAP-strukturen och tillgången på åtkomstbehörighet till den begärda tabellen.
Vid fel returnerar tjänsten ett svar med lämplig kod och beskrivning. Om kontrollen lyckas skapas en bakgrundsprocess för att generera ett prov, genererar och returnerar synkront ett unikt sessions-id.
Vid ett fel registrerar det externa systemet det i loggen. I händelse av ett framgångsrikt svar sänder den sessions-id och namnet på tabellen för vilken begäran gjordes.
Det externa systemet registrerar den aktuella sessionen som öppen. Om det finns andra sessioner för denna tabell stängs de med en varning som loggas.
SAP-bakgrundsjobbet genererar en markör baserat på de angivna parametrarna och ett datapaket av angiven storlek. Batchstorlek är det maximala antalet poster som en process läser från databasen. Som standard antas det vara lika med 2000. Om det finns fler poster i databasprovet än den använda paketstorleken, efter sändning av det första paketet, bildas nästa block med motsvarande förskjutning och inkrementerade paketnummer. Siffrorna ökas med 1 och skickas strikt sekventiellt.
Därefter skickar SAP paketet som indata till det externa systemets webbtjänst. Och systemet utför kontroller på det inkommande paketet. En session med det mottagna ID:t måste registreras i systemet och den måste vara i öppen status. Om paketnumret > 1 bör systemet registrera det framgångsrika mottagandet av det föregående paketet (paket_id-1).
Om kontrollen lyckas analyserar och sparar det externa systemet tabelldata.
Dessutom, om den slutliga flaggan finns i paketet och serialiseringen lyckades, meddelas integrationsmodulen om framgångsrikt slutförande av sessionsbearbetning och modulen uppdaterar sessionsstatusen.
I händelse av ett kontroll-/parsningsfel loggas felet och paket för denna session kommer att avvisas av det externa systemet.
På samma sätt, i det motsatta fallet, när det externa systemet returnerar ett fel, loggas det och paketöverföringen stoppas.
För att begära data på SAP HСM-sidan implementerades en integrationstjänst. Tjänsten är implementerad på ICF-ramverket (SAP Internet Communication Framework - ). Det låter dig fråga data från SAP HCM-systemet med hjälp av specifika tabeller. När du skapar en databegäran är det möjligt att specificera en lista med specifika fält och filtreringsparametrar för att erhålla nödvändig data. Samtidigt innebär implementeringen av tjänsten ingen affärslogik. Algoritmer för beräkning av delta, frågeparametrar, integritetsövervakning etc. implementeras också på sidan av det externa systemet.
Denna mekanism låter dig samla in och överföra all nödvändig data på några timmar. Denna hastighet är på gränsen till acceptabel, så vi betraktar denna lösning som en tillfällig lösning, vilket gjorde det möjligt att fylla behovet av ett utvinningsverktyg på projektet.
I målbilden, för att lösa problemet med dataextraktion, undersöks alternativ för att använda CDC-system som Oracle Golden Gate eller ETL-verktyg som SAP DS.
Källa: will.com