Извличане на данни от SAP HCM към хранилища за данни, различни от SAP

Както знаете, SAP предлага пълна гама от софтуер както за поддържане на транзакционни данни, така и за обработка на тези данни в системи за анализ и отчети. По-специално, платформата SAP Business Warehouse (SAP BW) е инструментариум за съхранение и анализ на данни с широки технически възможности. При всички обективни предимства системата SAP BW има един съществен недостатък. Това е висока цена за съхранение и обработка на данни, особено забележима при използване на базиран в облак SAP BW на Hana.

Какво ще стане, ако започнете да използвате някакъв продукт, който не е SAP и за предпочитане OpenSource продукт като хранилище? Ние от X5 Retail Group избрахме GreenPlum. Това, разбира се, решава проблема с разходите, но в същото време веднага възникват проблеми, които са решени почти по подразбиране при използване на SAP BW.

По-специално, как да извлечете данни от системи източници, които са предимно решения на SAP?

HR Metrics беше първият проект, в който беше необходимо да се реши този проблем. Целта ни беше да създадем хранилище на HR данни и да изградим аналитична отчетност в областта на работата със служителите. В този случай основният източник на данни е транзакционната система SAP HCM, в която се извършват всички дейности по персонала, организацията и заплатите.

Извличане на данни

В SAP BW има стандартни екстрактори на данни за SAP системи. Тези екстрактори могат автоматично да събират необходимите данни, да наблюдават тяхната цялост и да определят делтата на промяната. Ето, например, стандартният източник на данни за атрибутите на служителите 0EMPLOYEE_ATTR:

Резултатът от извличането на данни от него за един служител:

Ако е необходимо, такъв екстрактор може да бъде модифициран, за да отговаря на вашите собствени изисквания или може да бъде създаден ваш собствен екстрактор.

Първата идея, която възникна, беше възможността за повторното им използване. За съжаление това се оказа непосилна задача. По-голямата част от логиката е внедрена от страна на SAP BW и не беше възможно безболезнено да се отдели екстракторът при източника от SAP BW.

Стана очевидно, че ще трябва да разработим собствен механизъм за извличане на данни от SAP системите.

Структура за съхранение на данни в SAP HCM

За да разберем изискванията за такъв механизъм, първо трябва да определим какви данни са ни необходими.

Повечето данни в SAP HCM се съхраняват в плоски SQL таблици. Въз основа на тези данни приложенията на SAP визуализират на потребителя организационни структури, служители и друга HR информация. Например, ето как изглежда организационната структура в SAP HCM:

Физически такова дърво се съхранява в две таблици - в hrp1000 обекти и в hrp1001 връзките между тези обекти.

Обекти “Отдел 1” и “Офис 1”:

Връзка между обекти:

Може да има огромен брой както видове обекти, така и видове връзки между тях. Има както стандартни връзки между обекти, така и персонализирани за вашите собствени специфични нужди. Например стандартната връзка B012 между организационна единица и длъжност на пълен работен ден показва ръководителя на отдел.

Дисплей на мениджъра в SAP:

Съхранение в таблица на база данни:

Данните за служителите се съхраняват в pa* таблици. Например данните за събития на персонала за служител се съхраняват в таблица pa0000

Решихме, че GreenPlum ще вземе „сурови“ данни, т.е. просто ги копирайте от SAP таблици. И директно в GreenPlum те ще бъдат обработени и преобразувани във физически обекти (например отдел или служител) и показатели (например среден брой служители).

Бяха дефинирани около 70 таблици, данните от които трябва да бъдат прехвърлени в GreenPlum. След което започнахме да разработваме метод за предаване на тези данни.

SAP предлага доста голям брой механизми за интеграция. Но най-лесният начин е, че директният достъп до базата данни е забранен поради лицензионни ограничения. Следователно всички интеграционни потоци трябва да бъдат реализирани на ниво сървър на приложения.
Следващият проблем беше липсата на данни за изтрити записи в базата данни на SAP. Когато изтриете ред в базата данни, той се изтрива физически. Тези. формирането на делта на промяна въз основа на времето на промяната не беше възможно.

Разбира се, SAP HCM има механизми за записване на промените в данните. Например, за последващо прехвърляне към приемни системи има указатели за промяна, които записват всички промени и на базата на които се формира Idoc (обект за прехвърляне към външни системи).

Примерен IDoc за промяна на инфотип 0302 за служител с персонален номер 1251445:

Или поддържане на регистрационни файлове на промените в данните в таблицата DBTABLOG.

Пример за лог за изтриване на запис с ключ QK53216375 от таблицата hrp1000:

Но тези механизми не са налични за всички необходими данни и тяхната обработка на ниво сървър на приложения може да изразходва доста ресурси. Следователно масовото разрешаване на регистриране на всички необходими таблици може да доведе до забележимо влошаване на производителността на системата.

Следващият голям проблем бяха групираните таблици. Оценката на времето и данните за заплатите във версията RDBMS на SAP HCM се съхраняват като набор от логически таблици за всеки служител за всяко изчисление. Тези логически таблици се съхраняват като двоични данни в таблица pcl2.

Клъстер за заплати:

Данните от клъстерирани таблици не могат да се считат за SQL команда, но изискват използването на SAP HCM макроси или специални функционални модули. Съответно скоростта на четене на такива таблици ще бъде доста ниска. От друга страна, такива клъстери съхраняват данни, които са необходими само веднъж месечно - окончателна заплата и оценка на времето. Така че скоростта в този случай не е толкова критична.

Оценявайки опциите за формиране на делта от промени в данните, решихме да разгледаме и опцията за пълно разтоварване. Възможността за прехвърляне на гигабайти непроменени данни между системите всеки ден може да не изглежда добре. Той обаче има и редица предимства - няма нужда едновременно да се прилага делта от страната на източника и да се прилага вграждането на тази делта от страната на приемника. Съответно разходите и времето за внедряване се намаляват, а надеждността на интеграцията се увеличава. В същото време беше установено, че почти всички промени в SAP HR се случват в рамките на хоризонт от три месеца преди текущата дата. Затова беше решено да се избере ежедневно пълно изтегляне на данни от SAP HR N месеца преди текущата дата и месечно пълно изтегляне. Параметърът N зависи от конкретната таблица
и варира от 1 до 15.

Предложена е следната схема за извличане на данни:

Външната система генерира заявка и я изпраща на SAP HCM, където тази заявка се проверява за пълнота на данните и разрешения за достъп до таблици. Ако проверката е успешна, SAP HCM изпълнява програма, която събира необходимите данни и ги прехвърля към решението за интегриране на Fuse. Fuse определя необходимата тема в Kafka и прехвърля данните там. След това данните от Kafka се прехвърлят към Stage Area GP.

В тази верига се интересуваме от въпроса за извличане на данни от SAP HCM. Нека го разгледаме по-подробно.

Диаграма на взаимодействие SAP HCM-FUSE.

Външната система определя часа на последната успешна заявка към SAP.
Процесът може да бъде стартиран от таймер или друго събитие, включително изчакване за изчакване на отговор с данни от SAP и иницииране на повторна заявка. След това генерира делта заявка и я изпраща на SAP.

Данните за заявката се изпращат до тялото във формат json.
Метод http: POST.
Примерна заявка:

SAP услугата следи заявката за пълнота, съответствие с текущата SAP структура и наличие на разрешение за достъп до заявената таблица.

В случай на грешки услугата връща отговор със съответния код и описание. Ако контролът е успешен, той създава фонов процес за генериране на проба, генерира и синхронно връща уникален идентификатор на сесия.

В случай на грешка, външната система я записва в дневника. В случай на успешен отговор, той предава идентификатора на сесията и името на таблицата, за която е направена заявката.

Външната система регистрира текущата сесия като отворена. Ако има други сесии за тази таблица, те се затварят с регистрирано предупреждение.

Фоновото задание на SAP генерира курсор въз основа на посочените параметри и пакет от данни с определен размер. Размерът на пакета е максималният брой записи, които процесът чете от базата данни. По подразбиране се приема, че е равен на 2000. Ако в извадката от базата данни има повече записи от използвания размер на пакета, след предаване на първия пакет се формира следващият блок със съответното отместване и увеличен номер на пакета. Числата се увеличават с 1 и се изпращат строго последователно.

След това SAP предава пакета като вход към уеб услугата на външната система. И системата извършва контрол върху входящия пакет. Сесия с полученото id трябва да е регистрирана в системата и да е в отворен статус. Ако номерът на пакета е > 1, системата трябва да запише успешното получаване на предишния пакет (package_id-1).

Ако контролът е успешен, външната система анализира и записва данните от таблицата.

Освен това, ако последният флаг присъства в пакета и сериализацията е успешна, интеграционният модул се уведомява за успешното завършване на обработката на сесията и модулът актуализира състоянието на сесията.

В случай на грешка при контрол/синтактичен анализ, грешката се регистрира и пакетите за тази сесия ще бъдат отхвърлени от външната система.

По същия начин, в обратния случай, когато външната система върне грешка, тя се регистрира и предаването на пакети спира.

За изискване на данни от страна на SAP HСM беше внедрена услуга за интеграция. Услугата е внедрена на ICF framework (SAP Internet Communication Framework - help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html). Тя ви позволява да правите заявки за данни от системата SAP HCM, като използвате конкретни таблици. При създаване на заявка за данни е възможно да се посочи списък от конкретни полета и параметри за филтриране, за да се получат необходимите данни. В същото време внедряването на услугата не предполага никаква бизнес логика. Алгоритми за изчисляване на делта, параметри на заявки, мониторинг на целостта и т.н. също са внедрени от страна на външната система.

Този механизъм ви позволява да събирате и предавате всички необходими данни за няколко часа. Тази скорост е на ръба на приемливото, така че ние считаме това решение за временно, което направи възможно запълването на нуждата от инструмент за извличане на проекта.
В целевата картина, за решаване на проблема с извличането на данни, се проучват опции за използване на CDC системи като Oracle Golden Gate или ETL инструменти като SAP DS.

Източник: www.habr.com