Zoals u weet biedt SAP een volledig pakket aan software, zowel voor het bijhouden van transactiegegevens als voor het verwerken van deze gegevens in analyse- en rapportagesystemen. Met name het SAP Business Warehouse (SAP BW)-platform is een toolkit voor het opslaan en analyseren van gegevens met uitgebreide technische mogelijkheden. Ondanks al zijn objectieve voordelen heeft het SAP BW-systeem één belangrijk nadeel. Dit brengt hoge kosten met zich mee voor het opslaan en verwerken van gegevens, vooral merkbaar bij het gebruik van cloudgebaseerde SAP BW op Hana.
Wat als u een niet-SAP en bij voorkeur een OpenSource-product als opslag gaat gebruiken? Wij van X5 Retail Group hebben gekozen voor GreenPlum. Dit lost natuurlijk het kostenprobleem op, maar tegelijkertijd ontstaan er onmiddellijk problemen die vrijwel standaard werden opgelost bij het gebruik van SAP BW.
Hoe kun je met name gegevens ophalen uit bronsystemen, die veelal SAP-oplossingen zijn?
HR Metrics was het eerste project waarin het nodig was dit probleem op te lossen. Ons doel was om een opslagplaats van HR-gegevens te creëren en analytische rapportages op te bouwen op het gebied van het werken met medewerkers. In dit geval is de belangrijkste gegevensbron het transactiesysteem SAP HCM, waarin alle personele, organisatorische en salarisactiviteiten worden uitgevoerd.
Data-extractie
In SAP BW zijn er standaard data-extractors voor SAP-systemen. Deze extractors kunnen automatisch de benodigde data verzamelen, de integriteit ervan bewaken en change delta’s bepalen. Hier is bijvoorbeeld de standaardgegevensbron voor werknemerskenmerken 0EMPLOYEE_ATTR:
Het resultaat van het extraheren van gegevens daaruit voor één medewerker:
Indien nodig kan een dergelijke afzuiging aangepast worden aan uw eigen wensen of kan er een eigen afzuiging gecreëerd worden.
Het eerste idee dat ontstond was de mogelijkheid om ze te hergebruiken. Helaas bleek dit een onmogelijke opgave. Het grootste deel van de logica is geïmplementeerd aan de SAP BW-kant en het was niet mogelijk om de extractor aan de bron pijnloos te scheiden van SAP BW.
Het werd duidelijk dat we ons eigen mechanisme moesten ontwikkelen voor het extraheren van gegevens uit SAP-systemen.
Gegevensopslagstructuur in SAP HCM
Om de vereisten voor een dergelijk mechanisme te begrijpen, moeten we eerst bepalen welke gegevens we nodig hebben.
De meeste gegevens in SAP HCM worden opgeslagen in platte SQL-tabellen. Op basis van deze gegevens visualiseren SAP-applicaties organisatiestructuren, medewerkers en andere HR-informatie voor de gebruiker. Zo ziet de organisatiestructuur er bijvoorbeeld uit in SAP HCM:
Fysiek wordt zo'n boom in twee tabellen opgeslagen: in hrp1000-objecten en in hrp1001 de verbindingen tussen deze objecten.
Objecten “Afdeling 1” en “Kantoor 1”:
Relatie tussen objecten:
Er kunnen een groot aantal van beide soorten objecten en soorten verbindingen daartussen zijn. Er zijn zowel standaardverbindingen tussen objecten als maatwerk voor uw eigen specifieke behoeften. De standaard B012-relatie tussen een organisatie-eenheid en een fulltime functie geeft bijvoorbeeld het hoofd van een afdeling aan.
Managerweergave in SAP:
Opslag in een databasetabel:
Medewerkersgegevens worden opgeslagen in pa*-tabellen. Gegevens over personeelsgebeurtenissen voor een werknemer worden bijvoorbeeld opgeslagen in tabel pa0000
We hebben besloten dat GreenPlum ‘ruwe’ gegevens zal gebruiken, d.w.z. kopieer ze gewoon uit SAP-tabellen. En rechtstreeks in GreenPlum worden ze verwerkt en omgezet in fysieke objecten (bijvoorbeeld afdeling of medewerker) en statistieken (bijvoorbeeld gemiddeld personeelsbestand).
Er zijn ongeveer 70 tabellen gedefinieerd, waarvan de gegevens naar GreenPlum moeten worden overgedragen. Daarna begonnen we een methode uit te werken om deze gegevens te verzenden.
SAP biedt een vrij groot aantal integratiemechanismen. Maar de eenvoudigste manier is om directe toegang tot de database te verbieden vanwege licentiebeperkingen. Alle integratiestromen moeten dus worden geïmplementeerd op het niveau van de applicatieserver.
Het volgende probleem was het gebrek aan gegevens over verwijderde records in de SAP-database. Wanneer u een rij in de database verwijdert, wordt deze fysiek verwijderd. Die. het vormen van een veranderingsdelta op basis van het tijdstip van verandering was niet mogelijk.
Natuurlijk beschikt SAP HCM over mechanismen voor het vastleggen van gegevenswijzigingen. Voor de latere overdracht naar ontvangende systemen zijn er bijvoorbeeld change pointers die eventuele wijzigingen registreren en op basis waarvan een Idoc (een object voor overdracht naar externe systemen) wordt gevormd.
Voorbeeld IDoc voor het wijzigen van infotype 0302 voor een medewerker met personeelsnummer 1251445:
Of het bijhouden van logboeken van gegevenswijzigingen in de DBTABLOG-tabel.
Een voorbeeld van een log voor het verwijderen van een record met de sleutel QK53216375 uit de hrp1000-tabel:
Maar deze mechanismen zijn niet beschikbaar voor alle noodzakelijke gegevens, en de verwerking ervan op het niveau van de applicatieserver kan behoorlijk wat bronnen vergen. Daarom kan het massaal inschakelen van loggen op alle benodigde tabellen leiden tot een merkbare verslechtering van de systeemprestaties.
Het volgende grote probleem waren geclusterde tabellen. Tijdschatting en loongegevens in de RDBMS-versie van SAP HCM worden voor elke werknemer voor elke berekening opgeslagen als een set logische tabellen. Deze logische tabellen worden als binaire gegevens opgeslagen in tabel pcl2.
Payrollcluster:
Gegevens uit geclusterde tabellen kunnen niet worden beschouwd als een SQL-opdracht, maar vereisen het gebruik van SAP HCM-macro's of speciale functionele modules. Dienovereenkomstig zal de leessnelheid van dergelijke tabellen vrij laag zijn. Aan de andere kant slaan dergelijke clusters gegevens op die slechts één keer per maand nodig zijn: de definitieve salarisadministratie en tijdschatting. Snelheid is in dit geval dus niet zo cruciaal.
Bij het evalueren van de opties voor het vormen van een delta van gegevenswijzigingen hebben we besloten ook de optie van volledig lossen te overwegen. De mogelijkheid om elke dag gigabytes aan onveranderde gegevens tussen systemen over te dragen, ziet er misschien niet goed uit. Het heeft echter ook een aantal voordelen: het is niet nodig om zowel de delta aan de bronzijde als de inbedding van deze delta aan de ontvangerzijde te implementeren. Dienovereenkomstig worden de kosten en de implementatietijd verlaagd en neemt de betrouwbaarheid van de integratie toe. Tegelijkertijd werd vastgesteld dat vrijwel alle veranderingen in SAP HR plaatsvinden binnen een horizon van drie maanden vóór de huidige datum. Daarom werd besloten om te kiezen voor een dagelijkse volledige download van data uit SAP HR N maanden vóór de huidige datum en een maandelijkse volledige download. De N-parameter is afhankelijk van de specifieke tabel
en varieert van 1 tot 15.
Het volgende schema werd voorgesteld voor gegevensextractie:
Het externe systeem genereert een verzoek en stuurt dit naar SAP HCM, waar dit verzoek wordt gecontroleerd op volledigheid van gegevens en machtigingen voor toegang tot tabellen. Als de controle succesvol is, draait SAP HCM een programma dat de benodigde gegevens verzamelt en overzet naar de Fuse-integratieoplossing. Fuse bepaalt het benodigde onderwerp in Kafka en draagt de gegevens daar over. Vervolgens worden de gegevens van Kafka overgebracht naar Stage Area GP.
In deze keten zijn wij geïnteresseerd in het vraagstuk van het extraheren van data uit SAP HCM. Laten we het in meer detail bekijken.
SAP HCM-FUSE-interactiediagram.
Het externe systeem bepaalt het tijdstip van de laatste succesvolle aanvraag bij SAP.
Het proces kan worden gestart door een timer of een andere gebeurtenis, inclusief het instellen van een time-out om te wachten op een antwoord met gegevens van SAP en een herhaalverzoek te initiëren. Vervolgens genereert het een deltaverzoek en stuurt het naar SAP.
De aanvraaggegevens worden in json-indeling naar de hoofdtekst verzonden.
Methode http: POST.
Voorbeeld verzoek:
De SAP-service bewaakt het verzoek op volledigheid, naleving van de huidige SAP-structuur en beschikbaarheid van toegangsrechten tot de gevraagde tabel.
In geval van fouten retourneert de service een reactie met de juiste code en beschrijving. Als de controle succesvol is, creëert het een achtergrondproces om een monster te genereren, genereert het een unieke sessie-ID en retourneert deze synchroon.
In geval van een fout registreert het externe systeem dit in het logboek. Bij een succesvol antwoord verzendt het de sessie-ID en de naam van de tabel waarvoor het verzoek is gedaan.
Het externe systeem registreert de huidige sessie als open. Als er andere sessies voor deze tabel zijn, worden deze afgesloten met een geregistreerde waarschuwing.
De SAP-achtergrondtaak genereert een cursor op basis van de opgegeven parameters en een datapakket van de opgegeven grootte. Batchgrootte is het maximale aantal records dat een proces uit de database leest. Standaard wordt aangenomen dat dit gelijk is aan 2000. Als er meer records in de databasesteekproef zijn dan de gebruikte pakketgrootte, wordt na verzending van het eerste pakket het volgende blok gevormd met het overeenkomstige offset- en opgehoogde pakketnummer. De cijfers worden met 1 verhoogd en strikt opeenvolgend verzonden.
Vervolgens geeft SAP het pakket door als invoer aan de webservice van het externe systeem. En het systeem voert controles uit op het binnenkomende pakket. Een sessie met het ontvangen ID moet in het systeem zijn geregistreerd en de status open hebben. Als het pakketnummer > 1 is, moet het systeem de succesvolle ontvangst van het vorige pakket registreren (pakket_id-1).
Als de controle succesvol is, parseert het externe systeem de tabelgegevens en slaat deze op.
Als de laatste vlag aanwezig is in het pakket en de serialisatie succesvol was, wordt de integratiemodule bovendien op de hoogte gesteld van de succesvolle voltooiing van de sessieverwerking en werkt de module de sessiestatus bij.
In het geval van een controle-/parseerfout wordt de fout geregistreerd en worden pakketten voor deze sessie afgewezen door het externe systeem.
Op dezelfde manier wordt in het tegenovergestelde geval, wanneer het externe systeem een fout retourneert, deze geregistreerd en stopt de pakketoverdracht.
Om gegevens aan de SAP HСM-kant op te vragen, werd een integratieservice geïmplementeerd. De service is geïmplementeerd op het ICF-framework (SAP Internet Communication Framework - ). Hiermee kunt u gegevens uit het SAP HCM-systeem opvragen met behulp van specifieke tabellen. Bij het aanmaken van een gegevensverzoek is het mogelijk om een lijst met specifieke velden en filterparameters op te geven om de benodigde gegevens te verkrijgen. Tegelijkertijd impliceert de implementatie van de dienst geen enkele bedrijfslogica. Algoritmen voor het berekenen van delta, queryparameters, integriteitsmonitoring, etc. worden ook geïmplementeerd aan de kant van het externe systeem.
Met dit mechanisme kunt u binnen een paar uur alle benodigde gegevens verzamelen en verzenden. Deze snelheid staat op de rand van acceptabel, dus beschouwen we deze oplossing als een tijdelijke oplossing, waardoor het mogelijk werd om in de behoefte aan een extractietool voor het project te voorzien.
Om het probleem van data-extractie op te lossen, worden in het doelbeeld mogelijkheden onderzocht voor het gebruik van CDC-systemen zoals Oracle Golden Gate of ETL-tools zoals SAP DS.
Bron: www.habr.com