Jak víte, SAP nabízí celou řadu softwaru jak pro správu transakčních dat, tak pro zpracování těchto dat v analytických a reportovacích systémech. Zejména platforma SAP Business Warehouse (SAP BW) je sada nástrojů pro ukládání a analýzu dat s rozsáhlými technickými možnostmi. Přes všechny své objektivní výhody má systém SAP BW jednu významnou nevýhodu. Jedná se o vysoké náklady na ukládání a zpracování dat, zvláště patrné při používání cloudového SAP BW na Haně.
Co když začnete jako úložiště používat nějaký non-SAP a nejlépe OpenSource produkt? My v X5 Retail Group jsme zvolili GreenPlum. Tím je samozřejmě vyřešena otázka nákladů, ale zároveň se okamžitě objevují problémy, které byly při použití SAP BW vyřešeny téměř standardně.
Konkrétně, jak získat data ze zdrojových systémů, což jsou většinou řešení SAP?
HR Metrics byl prvním projektem, ve kterém bylo nutné tento problém vyřešit. Naším cílem bylo vytvořit úložiště HR dat a vybudovat analytický reporting v oblasti práce se zaměstnanci. Hlavním zdrojem dat je v tomto případě transakční systém SAP HCM, ve kterém jsou realizovány veškeré personální, organizační a mzdové činnosti.
Extrakce dat
V SAP BW existují standardní extraktory dat pro systémy SAP. Tyto extraktory mohou automaticky shromažďovat potřebná data, monitorovat jejich integritu a určovat rozdíly změn. Zde je například standardní zdroj dat pro atributy zaměstnanců 0EMPLOYEE_ATTR:
Výsledek extrahování dat z něj pro jednoho zaměstnance:
V případě potřeby lze takový odsavač upravit podle vlastních požadavků nebo si vytvořit vlastní odsavač.
První nápad, který vznikl, byla možnost jejich opětovného použití. Bohužel se to ukázalo jako nesplnitelný úkol. Většina logiky je implementována na straně SAP BW a nebylo možné bezbolestně oddělit extraktor u zdroje od SAP BW.
Bylo zřejmé, že budeme muset vyvinout vlastní mechanismus pro extrakci dat ze systémů SAP.
Struktura úložiště dat v SAP HCM
Abychom pochopili požadavky na takový mechanismus, musíme nejprve určit, jaká data potřebujeme.
Většina dat v SAP HCM je uložena v plochých tabulkách SQL. Na základě těchto dat aplikace SAP uživateli vizualizují organizační struktury, zaměstnance a další HR informace. Takto například vypadá organizační struktura v SAP HCM:
Fyzicky je takový strom uložen ve dvou tabulkách - v objektech hrp1000 a v hrp1001 spojení mezi těmito objekty.
Objekty „Oddělení 1“ a „Kancelář 1“:
Vztah mezi objekty:
Jak typů objektů, tak typů vazeb mezi nimi může být obrovské množství. Existují jak standardní spojení mezi objekty, tak i přizpůsobená pro vaše vlastní specifické potřeby. Například standardní vztah B012 mezi organizační jednotkou a pozicí na plný úvazek označuje vedoucího oddělení.
Zobrazení manažera v SAP:
Úložiště v databázové tabulce:
Údaje o zaměstnancích jsou uloženy v tabulkách pa*. Například data o personálních událostech pro zaměstnance jsou uložena v tabulce pa0000
Rozhodli jsme se, že GreenPlum bude brát „surová“ data, tzn. stačí je zkopírovat z tabulek SAP. A přímo v GreenPlum budou zpracovány a převedeny na fyzické objekty (například oddělení nebo zaměstnanec) a metriky (například průměrný počet zaměstnanců).
Bylo definováno asi 70 tabulek, ze kterých je nutné přenést data do GreenPlum. Poté jsme začali vymýšlet způsob přenosu těchto dat.
SAP nabízí poměrně velké množství integračních mechanismů. Nejjednodušší ale je, že přímý přístup do databáze je zakázán kvůli licenčním omezením. Všechny integrační toky tedy musí být implementovány na úrovni aplikačního serveru.
Dalším problémem byl nedostatek dat o smazaných záznamech v databázi SAP. Když odstraníte řádek v databázi, bude fyzicky odstraněn. Tito. vytvoření změny delty na základě času změny nebylo možné.
SAP HCM má samozřejmě mechanismy pro záznam změn dat. Například pro následný přenos do přijímajících systémů existují ukazatele změn, které zaznamenávají případné změny a na jejichž základě se tvoří Idoc (objekt pro přenos do externích systémů).
Příklad IDoc pro změnu infotypu 0302 pro zaměstnance s osobním číslem 1251445:
Nebo vedení záznamů o změnách dat v tabulce DBTABLOG.
Příklad protokolu pro smazání záznamu s klíčem QK53216375 z tabulky hrp1000:
Tyto mechanismy však nejsou dostupné pro všechna potřebná data a jejich zpracování na úrovni aplikačního serveru může spotřebovat poměrně hodně zdrojů. Masivní povolení logování na všech potřebných tabulkách tedy může vést k znatelnému snížení výkonu systému.
Dalším velkým problémem byly seskupené tabulky. Odhad času a mzdové údaje ve verzi RDBMS SAP HCM jsou uloženy jako sada logických tabulek pro každého zaměstnance pro každý výpočet. Tyto logické tabulky jsou uloženy jako binární data v tabulce pcl2.
Mzdová skupina:
Data z klastrovaných tabulek nelze považovat za příkaz SQL, ale vyžadují použití maker SAP HCM nebo speciálních funkčních modulů. V souladu s tím bude rychlost čtení takových tabulek poměrně nízká. Na druhou stranu takové clustery ukládají data, která jsou potřeba pouze jednou měsíčně – konečné mzdy a odhad času. Takže rychlost v tomto případě není tak kritická.
Při vyhodnocování možností pro vytvoření delty změn dat jsme se rozhodli zvážit i možnost úplného vyložení. Možnost každodenního přenosu gigabajtů nezměněných dat mezi systémy nemusí vypadat dobře. Má to však i řadu výhod – není potřeba jak implementovat deltu na straně zdroje, tak implementovat vestavění této delty na straně přijímače. V souladu s tím se snižují náklady a doba implementace a zvyšuje se spolehlivost integrace. Zároveň bylo zjištěno, že téměř ke všem změnám v SAP HR dochází v horizontu tří měsíců před aktuálním datem. Proto bylo rozhodnuto zvolit denní plné stahování dat ze SAP HR N měsíců před aktuálním datem a měsíční plné stahování dat. Parametr N závisí na konkrétní tabulce
a pohybuje se od 1 do 15.
Pro extrakci dat bylo navrženo následující schéma:
Externí systém vygeneruje požadavek a odešle jej do SAP HCM, kde je tento požadavek zkontrolován na úplnost dat a oprávnění k přístupu k tabulkám. Pokud je kontrola úspěšná, SAP HCM spustí program, který shromáždí potřebná data a přenese je do řešení integrace Fuse. Fuse určí požadované téma v Kafce a přenese tam data. Dále jsou data z Kafky přenesena do Stage Area GP.
V tomto řetězci nás zajímá problematika extrakce dat ze SAP HCM. Pojďme se na to podívat podrobněji.
Interakční diagram SAP HCM-FUSE.
Externí systém určí čas posledního úspěšného požadavku na SAP.
Proces může být spuštěn časovačem nebo jinou událostí, včetně nastavení časového limitu pro čekání na odpověď s daty ze SAP a zahájení opakovaného požadavku. Poté vygeneruje delta požadavek a odešle jej do SAP.
Data požadavku jsou odeslána do těla ve formátu json.
Metoda http: POST.
Příklad požadavku:
Služba SAP monitoruje úplnost požadavku, shodu s aktuální strukturou SAP a dostupnost přístupového oprávnění k požadované tabulce.
V případě chyb služba vrátí odpověď s příslušným kódem a popisem. Pokud je kontrola úspěšná, vytvoří proces na pozadí pro generování vzorku, vygeneruje a synchronně vrátí jedinečné ID relace.
V případě chyby ji externí systém zaznamená do protokolu. V případě úspěšné odpovědi odešle ID relace a název tabulky, pro kterou byl požadavek vznesen.
Externí systém zaregistruje aktuální relaci jako otevřenou. Pokud pro tuto tabulku existují další relace, budou uzavřeny s protokolovaným varováním.
Úloha SAP na pozadí generuje kurzor na základě zadaných parametrů a datového paketu zadané velikosti. Velikost dávky je maximální počet záznamů, které proces čte z databáze. Ve výchozím nastavení se předpokládá, že je roven 2000. Pokud je ve vzorku databáze více záznamů, než je použitá velikost paketu, po odeslání prvního paketu se vytvoří další blok s odpovídajícím posunem a zvýšeným číslem paketu. Čísla se zvyšují o 1 a odesílají se přísně sekvenčně.
Dále SAP předá paket jako vstup webové službě externího systému. A systém provádí kontroly příchozího paketu. Relace s přijatým ID musí být zaregistrována v systému a musí být v otevřeném stavu. Pokud je číslo balíku > 1, systém by měl zaznamenat úspěšné přijetí předchozího balíku (package_id-1).
Pokud je kontrola úspěšná, externí systém analyzuje a uloží data tabulky.
Pokud je navíc v balíčku přítomen konečný příznak a serializace byla úspěšná, integrační modul je informován o úspěšném dokončení zpracování relace a modul aktualizuje stav relace.
V případě chyby kontroly/analýzy se chyba zaprotokoluje a pakety pro tuto relaci budou externím systémem odmítnuty.
Stejně tak v opačném případě, kdy externí systém vrátí chybu, je zaprotokolována a přenos paketů se zastaví.
Pro vyžádání dat na straně SAP HСM byla implementována integrační služba. Služba je implementována na ICF framework (SAP Internet Communication Framework - ). Umožňuje vám dotazovat se na data ze systému SAP HCM pomocí specifických tabulek. Při vytváření požadavku na data je možné zadat seznam konkrétních polí a parametrů filtrování pro získání potřebných dat. Implementace služby zároveň neznamená žádnou obchodní logiku. Na straně externího systému jsou implementovány také algoritmy pro výpočet delta, parametry dotazů, monitorování integrity atd.
Tento mechanismus umožňuje shromáždit a přenést všechna potřebná data během několika hodin. Tato rychlost je na hranici únosnosti, proto toto řešení považujeme za dočasné, které umožnilo naplnit potřebu extrakčního nástroje na projektu.
Na cílovém obrázku se pro řešení problému extrakce dat zkoumají možnosti využití systémů CDC, jako je Oracle Golden Gate nebo nástroje ETL, jako je SAP DS.
Zdroj: www.habr.com