Як відомо, компанія SAP пропонує повний спектр програмного забезпечення як для ведення транзакційних даних, так і для обробки цих даних у системах аналізу та звітності. Зокрема платформа SAP Business Warehouse (SAP BW) є інструментарієм для зберігання та аналізу даних, що володіє широкими технічними можливостями. За всіх своїх об'єктивних переваг система SAP BW має один значний недолік. Це висока вартість зберігання та обробки даних, особливо помітна під час використання хмарної SAP BW on Hana.
А якщо в якості сховища почати використовувати який-небудь non-SAP і бажано OpenSource продукт? Ми у Х5 Retail Group зупинили свій вибір на GreenPlum. Це вирішує питання вартості, але при цьому відразу з'являються питання, які при використанні SAP BW вирішувалися практично за умовчанням.
Зокрема, яким чином забирати дані із систем джерел, які здебільшого є рішеннями SAP?
"HR-метрики" став першим проектом, в якому необхідно було вирішити цю проблему. Нашою метою було створення сховища 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 є механізми фіксації змін даних. Наприклад, для подальшої передачі в системи одержувачі існують покажчики змін (change pointer), які фіксують будь-які зміни і на підставі яких формуються 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.
Дані запиту передаються body в форматі json.
Метод http:POST.
Приклад запиту:
Сервіс SAP контролює запит на повноту, відповідність поточній структурі SAP, наявність дозволу доступу до запитаної таблиці.
У разі помилок сервіс повертає відповідь з відповідним кодом та описом. У разі успішного контролю він створює фоновий процес для формування вибірки, генерує та синхронно повертає унікальний id сесії.
Зовнішня система у разі помилки реєструє її у журналі. У разі успішної відповіді передає id сесії та ім'я таблиці за якою було зроблено запит.
Зовнішня система реєструє поточну сесію як відкриту. Якщо є інші сесії з даної таблиці, вони закриваються з реєстрацією попередження у журналі.
Фонове завдання SAP формує курсор за заданими параметрами та пакет даних заданого розміру. Розмір пакета – максимальна кількість записів, які читає процес з БД. За замовчуванням приймається рівним 2000. Якщо у вибірці БД більше записів, ніж розмір пакета після передачі першого пакета формується наступний блок з відповідним offset і інкрементованим номером пакета. Номери інкрементують на 1 і відправляються суворо послідовно.
Далі SAP передає пакет на вхід до веб-сервісу зовнішньої системи. А вона система виконує контроль вхідного пакета. У системі має бути зареєстрована сесія з отриманим ID і вона повинна знаходитися у відкритому статусі. Якщо номер пакета > 1 у системі має бути зареєстроване успішне отримання попереднього пакета (package_id-1).
У разі успішного контролю зовнішня система парсить та зберігає дані таблиці.
Додатково, якщо в пакеті є прапор final і серіалізація пройшла успішно, відбувається повідомлення модуля інтеграції про успішне завершення обробки сесії і модуль оновлює статус сесії.
У разі помилки контролю/розбору помилка логується і пакети цієї сесії будуть відхилятися зовнішньою системою.
Так само і в іншому випадку, коли зовнішня система повертає помилку, вона логується і припиняється передача пакетів.
Для запиту даних на стороні SAP HСM було реалізовано інтеграційний сервіс. Сервіс реалізований на фреймворку ICF (SAP Internet Communication Framework ). Він дозволяє здійснювати запит даних із системи SAP HCM за певними таблицями. При формуванні запиту даних можна задавати перелік конкретних полів і параметри фільтрації з метою отримання необхідних даних. При цьому реалізація сервісу не передбачає будь-якої бізнес-логіки. Алгоритми розрахунку дельти, параметрів запиту, контролю цілісності та ін. також реалізуються на стороні зовнішньої системи.
Даний механізм дозволяє збирати та передавати всі необхідні дані за кілька годин. Така швидкість знаходиться на межі прийнятною, тому це рішення розглядається нами як тимчасове, що дозволило закрити потребу в інструменті екстракції на проекті.
У цільовій картині для вирішення задачі екстракції даних опрацьовуються варіанти використання CDC систем типу Oracle Golden Gate або ETL інструментів SAP DS.
Джерело: habr.com