Jak wiadomo, SAP oferuje pełną gamę oprogramowania zarówno do utrzymywania danych transakcyjnych, jak i do przetwarzania tych danych w systemach analitycznych i raportowych. W szczególności platforma SAP Business Warehouse (SAP BW) to zestaw narzędzi do przechowywania i analizy danych o rozbudowanych możliwościach technicznych. Przy wszystkich swoich obiektywnych zaletach system SAP BW ma jedną istotną wadę. Jest to wysoki koszt przechowywania i przetwarzania danych, szczególnie odczuwalny przy korzystaniu z opartego na chmurze SAP BW na platformie Hana.
Co się stanie, jeśli zaczniesz używać produktu innego niż SAP, a najlepiej produktu OpenSource jako pamięci masowej? W X5 Retail Group wybraliśmy GreenPlum. To oczywiście rozwiązuje kwestię kosztów, ale jednocześnie od razu pojawiają się problemy, które przy korzystaniu z SAP BW zostały rozwiązane niemal domyślnie.
W szczególności, jak odzyskać dane z systemów źródłowych, którymi w większości są rozwiązania SAP?
HR Metrics był pierwszym projektem, w którym konieczne było rozwiązanie tego problemu. Naszym celem było stworzenie repozytorium danych HR oraz zbudowanie raportowania analitycznego w obszarze pracy z pracownikami. Głównym źródłem danych jest w tym przypadku system transakcyjny SAP HCM, w którym realizowane są wszelkie czynności kadrowe, organizacyjne i płacowe.
Ekstrakcja danych
W SAP BW dostępne są standardowe ekstraktory danych dla systemów SAP. Ekstraktory te mogą automatycznie zbierać niezbędne dane, monitorować ich integralność i określać delty zmian. Oto przykładowe standardowe źródło danych dla atrybutów pracowników 0EMPLOYEE_ATTR:
Wynik wydobycia z niego danych dla jednego pracownika:
W razie potrzeby taki ekstraktor można zmodyfikować pod własne wymagania lub stworzyć własny ekstraktor.
Pierwszym pomysłem, który się pojawił, była możliwość ich ponownego wykorzystania. Niestety okazało się to zadaniem niemożliwym. Większość logiki jest zaimplementowana po stronie SAP BW i nie było możliwości bezbolesnego oddzielenia ekstraktora u źródła od SAP BW.
Stało się oczywiste, że będziemy musieli opracować własny mechanizm wydobywania danych z systemów SAP.
Struktura przechowywania danych w SAP HCM
Aby zrozumieć wymagania stawiane takiemu mechanizmowi, musimy najpierw określić, jakich danych potrzebujemy.
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 kadrowe. Przykładowo tak wygląda struktura organizacyjna w SAP HCM:
Fizycznie takie drzewo przechowywane jest w dwóch tabelach - w obiektach hrp1000 i w hrp1001 połączenia pomiędzy tymi obiektami.
Obiekty „Dział 1” i „Biuro 1”:
Związek między obiektami:
Liczba zarówno typów obiektów, jak i typów połączeń między nimi może być ogromna. Istnieją zarówno standardowe połączenia pomiędzy obiektami, jak i połączenia dostosowane do własnych, specyficznych potrzeb. Przykładowo standardowa relacja B012 pomiędzy jednostką organizacyjną a etatem wskazuje kierownika działu.
Wyświetlacz menadżerski w SAP:
Przechowywanie w tabeli bazy danych:
Dane pracowników przechowywane są w tabelach pa*. Na przykład dane dotyczące zdarzeń personalnych pracownika są przechowywane w tabeli pa0000
Zdecydowaliśmy, że GreenPlum będzie pobierał dane „surowe”, tj. po prostu skopiuj je z tabel SAP. A bezpośrednio w GreenPlum zostaną one przetworzone i zamienione na obiekty fizyczne (np. Dział lub Pracownik) oraz metryki (np. średnie zatrudnienie).
Zdefiniowano około 70 tabel, z których dane należy przenieść do GreenPlum. Następnie zaczęliśmy opracowywać metodę przesyłania tych danych.
SAP oferuje dość dużą liczbę mechanizmów integracyjnych. Ale najprostszym sposobem jest zakaz bezpośredniego dostępu do bazy danych ze względu na ograniczenia licencyjne. Dlatego wszystkie procesy integracyjne muszą być zaimplementowane na poziomie serwera aplikacji.
Kolejnym problemem był brak danych o usuniętych rekordach w bazie SAP. Kiedy usuwasz wiersz z bazy danych, jest on fizycznie usuwany. Te. utworzenie delty zmiany na podstawie czasu zmiany nie było możliwe.
Oczywiście SAP HCM posiada mechanizmy rejestrowania zmian danych. Przykładowo dla późniejszego przekazania do systemów odbiorców dostępne są wskaźniki zmian, które rejestrują wszelkie zmiany i na podstawie których tworzony jest Idoc (obiekt do przekazania do systemów zewnętrznych).
Przykład obiektu IDoc zmieniającego typ informacji 0302 dla pracownika o numerze personelu 1251445:
Lub prowadzenie dzienników zmian danych w tabeli DBTABLOG.
Przykład logu do usunięcia rekordu o kluczu QK53216375 z tabeli hrp1000:
Jednak mechanizmy te nie są dostępne dla wszystkich niezbędnych danych, a ich przetwarzanie na poziomie serwera aplikacji może pochłaniać całkiem sporo zasobów. Dlatego masowe włączenie logowania we wszystkich niezbędnych tabelach może prowadzić do zauważalnego spadku wydajności systemu.
Kolejnym poważnym problemem były tabele klastrowe. Dane szacunkowe i płacowe w wersji RDBMS SAP HCM są przechowywane w postaci zestawu tabel logicznych dla każdego pracownika dla każdego obliczenia. Te tabele logiczne są przechowywane jako dane binarne w tabeli pcl2.
Klaster płacowy:
Dane z tabel klastrowych nie mogą być traktowane jako polecenie SQL, ale wymagają użycia makr SAP HCM lub specjalnych modułów funkcjonalnych. W związku z tym prędkość odczytu takich tabel będzie dość niska. Z drugiej strony takie klastry przechowują dane potrzebne tylko raz w miesiącu - ostateczną kalkulację płacową i czasową. Zatem prędkość w tym przypadku nie jest tak krytyczna.
Oceniając opcje utworzenia delty zmian danych, postanowiliśmy rozważyć również opcję pełnego rozładowania. Opcja przenoszenia gigabajtów niezmienionych danych pomiędzy systemami każdego dnia może nie wyglądać dobrze. Ma to jednak również szereg zalet – nie ma potrzeby jednoczesnej implementacji delty po stronie źródła i implementowania osadzania tej delty po stronie odbiornika. W związku z tym zmniejszają się koszty i czas wdrożenia, a niezawodność integracji wzrasta. Jednocześnie ustalono, że niemal wszystkie zmiany w SAP HR zachodzą w horyzoncie trzech miesięcy przed datą bieżącą. Tym samym zdecydowano się na codzienne pobieranie pełnych danych z SAP HR N miesięcy przed bieżącą datą oraz pełne pobieranie miesięczne. Parametr N zależy od konkretnej tabeli
i waha się od 1 do 15.
Zaproponowano następujący schemat ekstrakcji danych:
System zewnętrzny generuje żądanie i przesyła je do SAP HCM, gdzie następuje sprawdzenie tego żądania pod kątem kompletności danych i uprawnień dostępu do tabel. Jeżeli weryfikacja wypadnie pomyślnie, SAP HCM uruchamia program, który zbiera niezbędne dane i przekazuje je do rozwiązania integracyjnego Fuse. Fuse określa wymagany temat w Kafce i tam przesyła dane. Następnie dane z Kafki przesyłane są do Stage Area GP.
W tym łańcuchu interesuje nas problematyka wydobywania danych z SAP HCM. Przyjrzyjmy się temu bardziej szczegółowo.
Schemat interakcji SAP HCM-FUSE.
System zewnętrzny określa czas ostatniego udanego żądania do SAP.
Proces może zostać uruchomiony przez timer lub inne zdarzenie, obejmujące ustawienie limitu czasu oczekiwania na odpowiedź z danymi z SAP i zainicjowanie ponownego żądania. Następnie generuje żądanie delta i wysyła je do SAP.
Dane żądania są wysyłane do treści w formacie json.
Metoda http: POST.
Przykład żądania:
Usługa SAP monitoruje żądanie pod kątem kompletności, zgodności z aktualną strukturą SAP oraz dostępności uprawnień dostępu do żądanej tabeli.
W przypadku błędów usługa zwraca odpowiedź zawierającą odpowiedni kod i opis. Jeśli kontrola się powiedzie, tworzy proces w tle w celu wygenerowania próbki, generuje i synchronicznie zwraca unikalny identyfikator sesji.
W przypadku wystąpienia błędu system zewnętrzny odnotowuje go w logu. W przypadku pozytywnej odpowiedzi przesyła identyfikator sesji i nazwę tabeli, dla której złożono żądanie.
System zewnętrzny rejestruje bieżącą sesję jako otwartą. Jeśli dla tej tabeli istnieją inne sesje, zostaną one zamknięte i zarejestrowane zostanie ostrzeżenie.
Zadanie w tle SAP generuje kursor na podstawie określonych parametrów i pakietu danych o określonym rozmiarze. Rozmiar wsadu to maksymalna liczba rekordów, które proces odczytuje z bazy danych. Domyślnie przyjmuje się, że jest ona równa 2000. Jeżeli w próbce bazy danych znajduje się więcej rekordów niż wykorzystany rozmiar pakietu, po przesłaniu pierwszego pakietu tworzony jest kolejny blok z odpowiednim przesunięciem i zwiększonym numerem pakietu. Liczby są zwiększane o 1 i wysyłane ściśle sekwencyjnie.
Następnie SAP przekazuje pakiet jako dane wejściowe do usługi internetowej systemu zewnętrznego. System przeprowadza kontrolę nad przychodzącym pakietem. Sesja o otrzymanym identyfikatorze musi być zarejestrowana w systemie i musi mieć status Otwarta. Jeżeli numer paczki > 1, system powinien odnotować pomyślne przyjęcie poprzedniej paczki (id_pakietu-1).
Jeżeli kontrola przebiegła pomyślnie, system zewnętrzny analizuje i zapisuje dane tabeli.
Dodatkowo, jeśli w pakiecie znajduje się flaga finalna i serializacja przebiegła pomyślnie, moduł integracji zostaje powiadomiony o pomyślnym zakończeniu przetwarzania sesji i moduł aktualizuje status sesji.
W przypadku błędu kontroli/analizy błąd jest rejestrowany, a pakiety dla tej sesji zostaną odrzucone przez system zewnętrzny.
Podobnie w odwrotnym przypadku, gdy system zewnętrzny zwróci błąd, jest on rejestrowany i transmisja pakietów zostaje zatrzymana.
Aby zażądać danych po stronie SAP HСM, wdrożono usługę integracji. Usługa jest realizowana w oparciu o framework ICF (SAP Internet Communication Framework - ). Umożliwia odpytywanie danych z systemu SAP HCM przy wykorzystaniu określonych tabel. Tworząc zapytanie o dane, istnieje możliwość określenia listy konkretnych pól oraz parametrów filtrowania w celu uzyskania niezbędnych danych. Jednocześnie wdrożenie usługi nie implikuje żadnej logiki biznesowej. Algorytmy obliczania delty, parametrów zapytań, monitorowania integralności itp. są również zaimplementowane po stronie systemu zewnętrznego.
Mechanizm ten pozwala zebrać i przesłać wszystkie niezbędne dane w ciągu kilku godzin. Szybkość ta jest na granicy akceptowalności, dlatego traktujemy to rozwiązanie jako tymczasowe, które umożliwiło zaspokojenie zapotrzebowania na narzędzie do ekstrakcji w projekcie.
W docelowym obrazie, aby rozwiązać problem ekstrakcji danych, badane są możliwości wykorzystania systemów CDC takich jak Oracle Golden Gate czy narzędzi ETL takich jak SAP DS.
Źródło: www.habr.com