Jak wiadomo, firma SAP oferuje pełen zakres oprogramowania, zarówno do zarządzania danymi transakcyjnymi, jak i ich analizy i raportowania. W szczególności platforma SAP Business Warehouse (SAP BW) stanowi zestaw narzędzi do przechowywania i analizy danych, posiadający szerokie możliwości techniczne. Pomimo wszystkich swoich obiektywnych zalet, system SAP BW ma jedną istotną wadę: wysokie koszty przechowywania i przetwarzania danych, co jest szczególnie zauważalne w przypadku korzystania z chmurowego rozwiązania SAP BW on Hana.
A co jeśli jako magazyn zacząć używać jakiegoś produktu non-SAP, najlepiej OpenSource? W H5 Retail Group zdecydowaliśmy się na GreenPlum. To oczywiście rozwiązuje problem kosztów, ale natychmiast rodzi pytania, które w przypadku używania SAP BW były rozwiązywane praktycznie automatycznie.
W szczególności, w jaki sposób pobierać dane z systemów źródłowych, które w większości przypadków są rozwiązaniami SAP?
Projekt "HR-metryki" stał się pierwszym projektem, w którym należało rozwiązać ten problem. Naszym celem było stworzenie magazynu danych HR oraz budowa raportów analitycznych dotyczących pracy z pracownikami. Głównym źródłem danych jest system transakcyjny SAP HCM, w którym prowadzone są wszelkie działania związane z kadrami, organizacją i wynagrodzeniem.
Ekstrakcja danych
W SAP BW dla systemów SAP istnieją standardowe ekstraktory danych. Ekstraktory te mogą automatycznie zbierać potrzebne dane, monitorować ich integralność oraz określać zmiany. Oto na przykład standardowe źródło danych dotyczące atrybutów pracownika 0EMPLOYEE_ATTR:
Wynik ekstrakcji danych z niego dla jednego pracownika:
W razie potrzeby taki ekstraktor może być dostosowany do własnych wymagań lub można stworzyć własny ekstraktor.
Jako pierwsza pojawiła się idea ich ponownego wykorzystania. Niestety, okazało się to zadaniem niemożliwym do zrealizowania. Większość logiki została zrealizowana po stronie SAP BW i nie udało się bezboleśnie oddzielić ekstraktora na źródle od SAP BW.
Stało się oczywiste, że konieczne będzie opracowanie własnego mechanizmu ekstrakcji danych z systemów SAP.
Struktura przechowywania danych w SAP HCM
Aby zrozumieć wymagania dotyczące takiego mechanizmu, należy najpierw określić, jakie dokładnie dane będą potrzebne.
Większość danych w SAP HCM jest przechowywana w płaskich tabelach SQL. Na podstawie tych danych aplikacje SAP wizualizują użytkownikowi struktury organizacyjne, pracowników i inne informacje HR. Na przykład, tak wygląda struktura organizacyjna w SAP HCM:
Fizycznie takie drzewo jest przechowywane w dwóch tabelach — w hrp1000 obiekty oraz w hrp1001 powiązania między tymi obiektami.
Obiekty „Departament 1” i „Zarząd 1”:
Powiązanie między obiektami:
Może istnieć ogromna liczba zarówno typów obiektów, jak i typów powiązań między nimi. Istnieją zarówno standardowe powiązania między obiektami, jak i dostosowane do specyficznych potrzeb. Na przykład standardowe powiązanie B012 między jednostką organizacyjną a stanowiskiem określa kierownika jednostki.
Wyświetlanie kierownika w SAP:
Przechowywanie w tabeli bazy danych:
Dane pracowników są przechowywane w tabelach pa*. Na przykład dane dotyczące zdarzeń kadrowych pracownika są przechowywane w tabeli pa0000.
Zdecydowaliśmy, że GreenPlum będzie pobierał „surowe” dane, tzn. po prostu kopiował je z tabel SAP. A następnie w GreenPlum będą one przetwarzane i przekształcane w obiekty fizyczne (na przykład Departament lub Pracownik) oraz metryki (na przykład średnia liczba etatów).
Określono około 70 tabel, z których dane należy przekazać do GreenPlum. Następnie przystąpiliśmy do opracowania sposobu przekazywania tych danych.
SAP oferuje dość dużą liczbę mechanizmów integracji. Jednak najprostszym sposobem — bezpośredni dostęp do bazy danych jest zabroniony z powodu ograniczeń licencyjnych. W ten sposób wszystkie potoki integracyjne muszą być realizowane na poziomie serwera aplikacji.
Kolejnym problemem był brak danych o usuniętych rekordach w bazie danych SAP. Przy usunięciu wiersza w bazie danych, zostaje on fizycznie usunięty. To znaczy, że nie było możliwe utworzenie delta zmian w oparciu o czas zmiany.
Oczywiście, w SAP HCM istnieją mechanizmy rejestrowania zmian danych. Na przykład, w celu późniejszego przesyłania do systemów odbierających istnieją wskaźniki zmian (change pointer), które rejestrują wszelkie zmiany i na ich podstawie tworzone są Idoc (obiekt do przesyłania do systemów zewnętrznych).
Przykład zmiany infotypu 0302 u pracownika o numerze identyfikacyjnym 1251445:
Lub prowadzenie dzienników zmian danych w tabeli DBTABLOG.
Przykład dziennika usunięcia rekordu z kluczem QK53216375 z tabeli hrp1000:
Jednak te mechanizmy nie są dostępne dla wszystkich niezbędnych danych, a ich przetwarzanie na poziomie serwera aplikacji może zużywać dość dużo zasobów. Dlatego masowe włączenie logowania dla wszystkich niezbędnych tabel może prowadzić do zauważalnej degradacji wydajności systemu.
Kolejnym poważnym problemem były tabele klastrowe. Dane dotyczące oceny czasu i obliczeń płac w wersji RDBMS SAP HCM są przechowywane w postaci zestawu logicznych tabel dla każdego pracownika za każde obliczenie. Te logiczne tabeli w postaci danych binarnych przechowywane są w tabeli pcl2.
Klastr obliczeń płacowych:
Dane z tabel klastrowych nie mogą być odczytywane za pomocą polecenia SQL, wymagana jest użycie makrokomend SAP HCM lub specjalnych modułów funkcjonalnych. W związku z tym prędkość odczytu takich tabel będzie dość niska. Z drugiej strony, w takich klastrach przechowywane są dane, które są potrzebne tylko raz w miesiącu – podsumowanie obliczeń płacowych i ocena czasu. Zatem prędkość w tym przypadku nie jest tak krytyczna.
Oceniając opcje dotyczące generowania delty zmian danych, zdecydowano również rozważyć opcję z pełnym zrzutem. Opcja przesyłania gigabajtów niezmiennych danych każdego dnia między systemami nie wydaje się szczególnie atrakcyjna. Jednak ma ona również szereg zalet – nie ma potrzeby realizacji delty po stronie źródła, ani jej wklejania po stronie odbiorcy. W związku z tym zmniejsza się koszt i czas realizacji, a także zwiększa się niezawodność integracji. Ustalono również, że praktycznie wszystkie zmiany w SAP HR zachodzą w okresie trzech miesięcy przed aktualną datą. W związku z tym podjęto decyzję o codziennym pełnym zrzucie danych z SAP HR za N miesięcy przed aktualną datą oraz miesięcznym pełnym zrzucie. Parametr N zależy od konkretnej tabeli
i waha się od 1 do 15.
Dla ekstrakcji danych zaproponowano następujący schemat:
Zewnętrzny system generuje zapytanie i przesyła je do SAP HCM, gdzie zapytanie jest weryfikowane pod kątem kompletności danych i uprawnień dostępu do tabel. W przypadku pomyślnej weryfikacji w SAP HCM uruchamiany jest program, który zbiera potrzebne dane i przekazuje je do rozwiązania integracyjnego Fuse. Fuse określa odpowiedni temat w Kafka i przesyła dane tam. Następnie dane z Kafka są przesyłane do Strefy GP.
W tej sieci interesuje nas kwestia wydobywania danych z SAP HCM. Przyjrzyjmy mu się bliżej.
Schemat interakcji SAP HCM-FUSE.
Zewnętrzny system określa czas ostatniego pomyślnego zapytania w SAP.
Proces może być uruchamiany na podstawie timera lub innego zdarzenia, w tym może być ustawiony czas oczekiwania na odpowiedź z danymi z SAP i zainicjowanie ponownego zapytania. Następnie formułuje zapytanie różnicy i przesyła je do SAP.
Dane zapytania są przesyłane w treści w formacie json.
Metoda http: POST.
Przykład zapytania:
Serwis SAP wykonuje kontrolę zapytania pod kątem kompletności, zgodności z aktualną strukturą SAP oraz dostępności uprawnienia dostępu do żądanej tabeli.
W przypadku błędów serwis zwraca odpowiedź z odpowiednim kodem i opisem. W przypadku pomyślnej kontroli tworzy proces w tle do generowania danych, generuje i synchronizacyjnie zwraca unikalny identyfikator sesji.
W przypadku błędu zewnętrzny system rejestruje go w dzienniku. W przypadku pomyślnej odpowiedzi przesyła identyfikator sesji oraz nazwę tabeli, do której złożono zapytanie.
Zewnętrzny system rejestruje bieżącą sesję jako otwartą. Jeśli istnieją inne sesje związane z tą tabelą, są one zamykane z rejestracją ostrzeżenia w dzienniku.
Zadanie w tle SAP tworzy kursor dla zadanych parametrów i pakiet danych o określonym rozmiarze. Rozmiar pakietu to maksymalna liczba rekordów, które proces odczytuje z bazy danych. Domyślnie przyjmuje się, że wynosi 2000. Jeśli w próbie bazy danych znajduje się więcej rekordów niż przyjęty rozmiar pakietu, po przesłaniu pierwszego pakietu tworzy się następny blok z odpowiednim offsetem i inkrementowanym numerem pakietu. Numery są inkrementowane o 1 i wysyłane ściśle w kolejności.
Następnie SAP przekazuje pakiet do zewnętrznego systemu usługi sieciowej. System ten wykonuje kontrole przychodzącego pakietu. W systemie musi być zarejestrowana sesja z otrzymanym id i musi ona być w stanie otwartym. Jeśli numer pakietu > 1, w systemie musi być zarejestrowane pomyślne otrzymanie poprzedniego pakietu (package_id-1).
W przypadku pomyślnej kontroli zewnętrzny system analizuje i zapisuje dane tabeli.
Dodatkowo, jeśli w pakiecie znajduje się flaga final i serializacja przebiegła pomyślnie, moduł integracji jest informowany o pomyślnym zakończeniu przetwarzania sesji, a moduł aktualizuje status sesji.
W przypadku błędu kontroli/analizy, błąd jest rejestrowany, a pakiety w tej sesji będą odrzucane przez zewnętrzny system.
Podobnie w przeciwnym przypadku, gdy zewnętrzny system zwraca błąd, jest on rejestrowany, a przesyłanie pakietów zostaje zakończone.
Aby zażądać danych ze strony SAP HCM, wdrożono usługę integracyjną. Usługa ta została zrealizowana na frameworku ICF (SAP Internet Communication Framework — ). Umożliwia ona żądanie danych z systemu SAP HCM według określonych tabel. Przy tworzeniu żądania danych możliwe jest określenie konkretnej listy pól oraz parametrów filtrowania w celu uzyskania wymaganych danych. Przy tym realizacja usługi nie przewiduje żadnej logiki biznesowej. Algorytmy obliczania delty, parametrów żądania, kontroli integralności itp. są również realizowane po stronie zewnętrznego systemu.
Mechanizm ten pozwala na zbieranie i przesyłanie wszystkich niezbędnych danych w ciągu kilku godzin. Taka prędkość znajduje się na granicy akceptowalnej, dlatego to rozwiązanie rozważamy jako tymczasowe, które pomogło zaspokoić potrzebę narzędzia ekstrakcji w projekcie.
W docelowej wizji rozwiązania do zadania ekstrakcji danych opracowywane są opcje wykorzystania systemów CDC typu Oracle Golden Gate lub narzędzi ETL typu SAP DS.
Źródło: habr.com
