Ako viete, SAP ponúka celý rad softvéru na udržiavanie transakčných údajov a na spracovanie týchto údajov v analytických a reportovacích systémoch. Najmä platforma SAP Business Warehouse (SAP BW) je súprava nástrojov na ukladanie a analýzu údajov s rozsiahlymi technickými možnosťami. Napriek všetkým objektívnym výhodám má systém SAP BW jednu významnú nevýhodu. Ide o vysoké náklady na ukladanie a spracovanie údajov, ktoré sú obzvlášť viditeľné pri používaní cloudového SAP BW na Hana.
Čo ak začnete ako úložisko používať nejaký non-SAP a najlepšie produkt OpenSource? My v X5 Retail Group sme si vybrali GreenPlum. Tým sa samozrejme rieši otázka nákladov, no zároveň sa okamžite vynárajú problémy, ktoré sa pri používaní SAP BW riešili takmer štandardne.
Konkrétne, ako získať dáta zo zdrojových systémov, ktorými sú väčšinou riešenia SAP?
HR Metrics bol prvý projekt, v ktorom bolo potrebné tento problém vyriešiť. Naším cieľom bolo vytvoriť úložisko HR dát a vybudovať analytický reporting v oblasti práce so zamestnancami. Hlavným zdrojom dát je v tomto prípade transakčný systém SAP HCM, v ktorom sa realizujú všetky personálne, organizačné a mzdové činnosti.
Extrakcia dát
V SAP BW existujú štandardné extraktory dát pre systémy SAP. Tieto extraktory môžu automaticky zhromažďovať potrebné údaje, monitorovať ich integritu a určovať rozdiely zmien. Tu je napríklad štandardný zdroj údajov pre atribúty zamestnancov 0EMPLOYEE_ATTR:
Výsledok extrahovania údajov z neho pre jedného zamestnanca:
V prípade potreby je možné takýto odsávač upraviť podľa vlastných požiadaviek alebo si vytvoriť vlastný odsávač.
Prvý nápad, ktorý vznikol, bola možnosť ich opätovného použitia. Bohužiaľ sa to ukázalo ako nesplniteľná úloha. Väčšina logiky je implementovaná na strane SAP BW a nebolo možné bezbolestne oddeliť extraktor pri zdroji od SAP BW.
Bolo zrejmé, že budeme musieť vyvinúť vlastný mechanizmus na extrahovanie údajov zo systémov SAP.
Štruktúra dátového úložiska v SAP HCM
Aby sme pochopili požiadavky na takýto mechanizmus, musíme najprv určiť, aké údaje potrebujeme.
Väčšina údajov v SAP HCM je uložená v plochých SQL tabuľkách. Na základe týchto údajov aplikácie SAP používateľovi vizualizujú organizačné štruktúry, zamestnancov a ďalšie informácie o ľudských zdrojoch. Takto napríklad vyzerá organizačná štruktúra v SAP HCM:
Fyzicky je takýto strom uložený v dvoch tabuľkách - v objektoch hrp1000 a v hrp1001 spojenia medzi týmito objektmi.
Objekty „Oddelenie 1“ a „Kancelária 1“:
Vzťah medzi objektmi:
Môže existovať obrovské množstvo oboch typov objektov a typov spojení medzi nimi. Existujú štandardné spojenia medzi objektmi a prispôsobené pre vaše vlastné špecifické potreby. Napríklad štandardný vzťah B012 medzi organizačnou jednotkou a pozíciou na plný úväzok označuje vedúceho oddelenia.
Zobrazenie manažéra v systéme SAP:
Uloženie v databázovej tabuľke:
Údaje o zamestnancoch sú uložené v tabuľkách pa*. Napríklad údaje o personálnych udalostiach zamestnanca sú uložené v tabuľke pa0000
Rozhodli sme sa, že GreenPlum bude brať “raw” dáta, t.j. stačí ich skopírovať z tabuliek SAP. A priamo v GreenPlum budú spracované a prevedené na fyzické objekty (napríklad oddelenie alebo zamestnanec) a metriky (napríklad priemerný počet zamestnancov).
Bolo definovaných asi 70 tabuliek, z ktorých je potrebné preniesť dáta do GreenPlum. Potom sme začali vymýšľať spôsob prenosu týchto údajov.
SAP ponúka pomerne veľké množstvo integračných mechanizmov. Ale najjednoduchší spôsob je, že priamy prístup do databázy je zakázaný kvôli licenčným obmedzeniam. Všetky integračné toky teda musia byť implementované na úrovni aplikačného servera.
Ďalším problémom bol nedostatok údajov o vymazaných záznamoch v databáze SAP. Keď vymažete riadok v databáze, fyzicky sa odstráni. Tie. vytvorenie delty zmeny na základe času zmeny nebolo možné.
SAP HCM má samozrejme mechanizmy na zaznamenávanie zmien údajov. Napríklad pre následný prenos do prijímacích systémov existujú ukazovatele zmien, ktoré zaznamenávajú akékoľvek zmeny a na základe ktorých sa vytvára Idoc (objekt na prenos do externých systémov).
Príklad IDoc pre zmenu infotypu 0302 pre zamestnanca s osobným číslom 1251445:
Alebo uchovávanie záznamov o zmenách údajov v tabuľke DBTABLOG.
Príklad protokolu na vymazanie záznamu s kľúčom QK53216375 z tabuľky hrp1000:
Tieto mechanizmy však nie sú dostupné pre všetky potrebné údaje a ich spracovanie na úrovni aplikačného servera môže spotrebovať pomerne veľa zdrojov. Preto masívne povoľovanie logovania na všetkých potrebných tabuľkách môže viesť k výraznému zníženiu výkonu systému.
Ďalším veľkým problémom boli zoskupené tabuľky. Odhad času a údaje o mzdách vo verzii RDBMS SAP HCM sú uložené ako sada logických tabuliek pre každého zamestnanca pre každý výpočet. Tieto logické tabuľky sú uložené ako binárne údaje v tabuľke pcl2.
Mzdový klaster:
Údaje z klastrovaných tabuliek nemožno považovať za príkaz SQL, ale vyžadujú použitie makier SAP HCM alebo špeciálnych funkčných modulov. Preto bude rýchlosť čítania takýchto tabuliek dosť nízka. Na druhej strane takéto klastre uchovávajú dáta, ktoré sú potrebné len raz za mesiac – konečné mzdy a odhad času. Takže rýchlosť v tomto prípade nie je taká kritická.
Pri hodnotení možností vytvorenia delty zmien dát sme sa rozhodli zvážiť aj možnosť úplného uvoľnenia. Možnosť každodenného prenosu gigabajtov nezmenených dát medzi systémami nemusí vyzerať dobre. Má to však aj množstvo výhod – nie je potrebné implementovať deltu na strane zdroja a zároveň implementovať vloženie tejto delty na strane prijímača. V súlade s tým sa znižujú náklady a čas implementácie a zvyšuje sa spoľahlivosť integrácie. Zároveň sa zistilo, že takmer všetky zmeny v SAP HR nastávajú v horizonte troch mesiacov pred aktuálnym dátumom. Preto bolo rozhodnuté zvoliť denné úplné sťahovanie dát zo SAP HR N mesiacov pred aktuálnym dátumom a mesačné úplné sťahovanie. Parameter N závisí od konkrétnej tabuľky
a pohybuje sa od 1 do 15.
Na extrakciu údajov bola navrhnutá nasledujúca schéma:
Externý systém vygeneruje požiadavku a odošle ju do SAP HCM, kde sa skontroluje úplnosť údajov a povolenia na prístup k tabuľkám. Ak je kontrola úspešná, SAP HCM spustí program, ktorý zhromažďuje potrebné údaje a prenesie ich do integračného riešenia Fuse. Fuse určí požadovanú tému v Kafke a prenesie tam údaje. Ďalej sa údaje z Kafku prenesú do Stage Area GP.
V tomto reťazci nás zaujíma problematika extrakcie dát zo SAP HCM. Pozrime sa na to podrobnejšie.
Interakčný diagram SAP HCM-FUSE.
Externý systém určí čas poslednej úspešnej požiadavky do SAP.
Proces môže byť spustený časovačom alebo inou udalosťou vrátane časového limitu na čakanie na odpoveď s údajmi zo SAP a iniciovanie opakovanej požiadavky. Potom vygeneruje požiadavku delta a odošle ju do SAP.
Údaje požiadavky sa odosielajú do tela vo formáte json.
Metóda http: POST.
Príklad žiadosti:
Služba SAP monitoruje úplnosť požiadavky, súlad s aktuálnou štruktúrou SAP a dostupnosť povolenia na prístup k požadovanej tabuľke.
V prípade chýb služba vráti odpoveď s príslušným kódom a popisom. Ak je kontrola úspešná, vytvorí proces na pozadí na vygenerovanie vzorky, vygeneruje a synchrónne vráti jedinečné ID relácie.
V prípade chyby ju externý systém zaznamená do protokolu. V prípade úspešnej odpovede odošle ID relácie a názov tabuľky, pre ktorú bola žiadosť podaná.
Externý systém zaregistruje aktuálnu reláciu ako otvorenú. Ak existujú ďalšie relácie pre túto tabuľku, zatvoria sa s zaznamenaným varovaním.
Úloha SAP na pozadí generuje kurzor na základe špecifikovaných parametrov a dátového paketu špecifikovanej veľkosti. Veľkosť dávky je maximálny počet záznamov, ktoré proces číta z databázy. Štandardne sa predpokladá, že sa rovná 2000. Ak je vo vzorke databázy viac záznamov, než je použitá veľkosť paketu, po odoslaní prvého paketu sa vytvorí ďalší blok s príslušným posunom a zvýšeným číslom paketu. Čísla sa zvyšujú o 1 a odosielajú sa striktne postupne.
Potom SAP odovzdá paket ako vstup webovej službe externého systému. A systém vykonáva kontrolu nad prichádzajúcim paketom. Relácia s prijatým ID musí byť zaregistrovaná v systéme a musí byť v stave otvorenia. Ak je číslo balíka > 1, systém by mal zaznamenať úspešné prijatie predchádzajúceho balíka (package_id-1).
Ak je kontrola úspešná, externý systém analyzuje a uloží údaje tabuľky.
Okrem toho, ak je v balíku prítomný konečný príznak a serializácia bola úspešná, integračný modul je informovaný o úspešnom dokončení spracovania relácie a modul aktualizuje stav relácie.
V prípade chyby kontroly/analýzy sa chyba zaprotokoluje a pakety pre túto reláciu budú odmietnuté externým systémom.
Rovnako aj v opačnom prípade, keď externý systém vráti chybu, je zaprotokolovaný a prenos paketov sa zastaví.
Na vyžiadanie údajov na strane SAP HСM bola implementovaná integračná služba. Služba je implementovaná na ICF framework (SAP Internet Communication Framework - ). Umožňuje vám dopytovať údaje zo systému SAP HCM pomocou špecifických tabuliek. Pri vytváraní požiadavky na údaje je možné špecifikovať zoznam konkrétnych polí a parametrov filtrovania za účelom získania potrebných údajov. Implementácia služby zároveň neznamená žiadnu obchodnú logiku. Na strane externého systému sú implementované aj algoritmy na výpočet delta, parametre dotazu, monitorovanie integrity atď.
Tento mechanizmus vám umožňuje zhromaždiť a preniesť všetky potrebné údaje v priebehu niekoľkých hodín. Táto rýchlosť je na hranici akceptovateľnosti, preto toto riešenie považujeme za dočasné, čo umožnilo naplniť potrebu extrakčného nástroja na projekte.
V cieľovom obrázku sa na vyriešenie problému extrakcie údajov skúmajú možnosti využitia systémov CDC, ako je Oracle Golden Gate alebo ETL nástrojov, ako je SAP DS.
Zdroj: hab.com