BW/4HANA – ciąg dalszy (r)ewolucji

Poprzednią część artykułu zakończyłem listą pierwszoplanowych cech systemu BW/4HANA:

1. Prostota (Simplicity)
2. Otwartość (Openness)
3. Nowoczesny interfejs
4. Wysoka wydajność

W tej części przyjrzę się bliżej (głównie) dwóm pierwszym pozycjom z powyższej listy, ponieważ najbardziej wpływają na pracę dewelopera BW. Widoczne jest to w kontekście podejścia do modelowania przepływu danych – mając na uwadze również różne systemy współistniejące w obrębie jednej, szerokiej perspektywy.

Prostota (Simplicity) (1): Modelowanie w BW

BW/4HANA oferuje 4 obiekty służące modelowaniu przepływu danych. Dwa z nich fizycznie przechowują dane (Advanced DataStore Object (aDSO) oraz InfoObject), a dwa służą wirtualizacji (CompositeProvider i Open ODS View). Wybór obiektu jest teraz prostszy (było ich 10), chociaż gdy przyjrzeć się tej kwestii nieco bliżej (na przykład aDSO), widać, że choć obiekt jest jeden, to ma więcej opcji. Opcji, które umożliwiają odtworzenie funkcji i możliwości zapewnianych przez „historyczne” obiekty. Można odnieść wrażenie, że jest „to samo tylko inaczej”, jednak chociażby z perspektywy łatwości utrzymania, jest to krok naprzód.

Przyglądając się kolejnym obiektom widzimy:

1. Advanced DataStore Object (aDSO)

aDSO jest najbardziej zaawansowanym obiektem z listy, ponieważ musi odtworzyć cechy tak różnych obiektów, jak DSO czy InfoCube, na dodatek z różnymi wariantami. Możliwe opcje konfiguracji (klasyfikując według „starych” obiektów), to:

DSO:

• Standard DSO
• Write-optimized DSO

InfoCube:

• Kostka klasyczna
• Kostka planistyczna (pozwalająca na wprowadzanie danych z poziomu raportu)
• Kostka inventory (miarki niekumulatywne)

Nie zagłębiając się w szczegółowe opisy poszczególnych obiektów, warto zaznaczyć różnorodność każdego z nich – od płaskiej tabeli, aż po rozszerzony schemat gwiazdy (Extended Star Schema), który notabene został w nowym systemie uproszczony o jeden poziom (Star Schema; pominięto tabele wymiarów). To wszystko obsługuje teraz jeden obiekt – aDSO.

Warto wspomnieć, że w BW/4HANA w większości przypadków nie ma potrzeby wykorzystania dodatkowych (customowych) indeksów. Według dokumentacji, zysk z ich użycia jest minimalny lub żaden. Nie ma również agregatów (nierozerwalnie związanych z InfoCube) i potrzeby ich wykorzystania. Dzięki dostępnej mocy przetwarzania in-memory, dane agregowane są w locie.

Jak widać, znika problem istniejący w poprzednich wersjach hurtowni, mianowicie utrzymanie indeksów i agregatów w stanie aktualnym. Zysk? Krótszy czas przetwarzania danych, mniejsza ilość danych, prostota.

2. CompositeProvider

CompositeProvider jest głównym obiektem służącym wirtualizacji, spinającym możliwości dawnych obiektów: InfoSet oraz MultiProvider. Służy tworzeniu kombinacji danych pochodzących z różnych źródeł, z wykorzystaniem operacji left outer join, inner join oraz union. Obiektami bazowymi tych operacji mogą być wszyscy dostawcy informacji (InfoProvider), włączając w to również obiekt CompositeProvider. Możliwe są zatem modele zagnieżdżone. Znamienne jest, że można tworzyć rozwiązania będące kombinacją obiektów ze świata BW (czyli obiektami z tej listy), z obiektami ze świata HANA (HANA Views), co daje szerokie spektrum możliwości. Co więcej, mamy również szansę wykorzystania tzw. field based modeling (o czym nieco niżej), co znacznie usprawnia pracę.

3. Open ODS View

Obiekt służący wirtualizacji, istniejący już w poprzednich wersjach systemu, również warty jest uwagi. O ile CompositeProvider jest rozwiązaniem złożonym z różnych obiektów, o tyle Open ODS View służy raczej jako bezpośrednie odzwierciedlenie danych z bazy, również tych wirtualnych (w przypadku, gdy HANA fizycznie nie przechowuje danych, a jedynie zapewnia dostęp do źródła zewnętrznego). Jest to konsumpcja tzw. external views. W związku z tym, iż Open ODS View jest dostawcą informacji (InfoProvider), można go wykorzystać w przepływie tworzonym i obsługiwanym w ramach systemu BW/4HANA. Uwidacznia się tutaj siła integracji BW i HANA.

Cechą flagową Open ODS View jest możliwość szybkiego prototypowania, dzięki modelowaniu opartemu na „polach” (field-based). Jako pole należy rozumieć prosty zestaw informacji, czyli typ i długość. Zysk wynikający z tego podejścia najlepiej zobrazować na przykładzie: mając w systemie HANA dostęp do danych z tabeli z systemu zewnętrznego (np. dzięki HANA Smart Data Access), która ma 200 kolumn, uwidocznienie jej w systemie BW potrwa kilka minut. Przy starym podejściu, które wymagałoby stworzenia/wykorzystania 200 InfoObiektów – byłby to czas nieporównywalnie dłuższy. Oczywiście nie chodzi tutaj o deprecjonowanie InfoObiektów, których idea jest istotna dla warstwy raportowej, ale o wskazanie nowych możliwości, których nie miały starsze wersje systemu.

4. InfoObject

Obiekt najmniej dotknięty przez wiatr zmian omiatający system BW. Bazowa funkcjonalność tego elementu nie zmienia się – dzięki niemu możliwe jest wzbogacanie raportów szeroką gamą informacji semantycznie powiązanych z wybraną cechą (atrybuty, hierarchie). Jak widać z perspektywy hurtowni danych i raportowania – jest to obiekt dojrzały.

Prostota (Simplicity) (2): Systemy źródłowe w BW

Analogicznie do obiektów służących modelowaniu w BW, liczba systemów źródłowych również uległa zmniejszeniu. Z perspektywy BW jest to uproszczenie, jednak biorąc pod uwagę cały system – nastąpiło przesunięcie ciężaru integracji z innymi środowiskami o poziom niżej – do platformy HANA. Pojawiło się również kilka nowych interfejsów, np. dostęp do danych z portali społecznościowych. Jak widać, w świecie mnożących się usług (sieciowych), protokołów i platform ciężko o „czyste” uproszczenie. O ile nie polega na porzuceniu wsparcia niektórych z nich. Nie jest możliwa obsługa wszystkich istniejących rozwiązań, dlatego konieczny jest całościowy przegląd rynku i wybór tych ważnych i perspektywicznych. W tym obszarze SAP ma ugruntowaną pozycję rynkową, szczególnie iż są obszary, w których wytycza nowe ścieżki.

Warto z zatem jeszcze raz podkreślić nowy obszar integracji, jakim jest BigData, która może służyć jako źródło danych, ale również jako miejsce ich przechowywania np. przy archiwizacji.

Systemy źródłowe w SAP BW i BW/4HANA

Otwartość (Openness) (1):

Elastyczne podejście – BW w HANA i HANA w BW

Pod hasłem Openness w materiałach dotyczących BW/4HANA widnieje informacja o możliwości „konsumpcji” danych przetrzymywanych w bazie HANA zarówno z poziomu BW (modelowanie à la InfoProvider) lub z poziomu bazy danych (SQL, HANA Views).

Oznacza to symetrię podejść (Exposing BW objects to HANA/Exposing HANA objects to BW) – w zależności od potrzeb możliwe jest spojrzenie na dane i ich przetwarzanie z różnych perspektyw (mixed scenarios). Można zatem wykorzystać natywne widoki z HANA, które semantycznie nie mają nic wspólnego z systemem BW (który bazuje na własnym schema na bazie), na przykład jako elementy obiektu CompositeProvider lub zmapowane do Open ODS View. Możliwe jest również inne podejście, czyli korzystanie z InfoProviderów jako obiektów bazowych w celu utworzenia HANA Views.

Mając na uwadze powyższe właściwości oraz fakt, że możliwy jest dostęp do widoków HANA ze świata zewnętrznego (JDBC/ODBC/OData; SQL/MDX), klaruje się całościowy obraz otwartości systemu BW/4HANA. Dzięki temu możliwe jest udostępnienie danych nie tylko dla licznych narzędzi raportowych SAP (np. SAP Lumira oraz inne z rodziny Business Objects), ale również dla spektrum narzędzi (BI i nie tylko) od innych dostawców (Tableau, Qlik, Tibco, MicroStrategy etc.).  BW w połączeniu z HANA oferują zatem obsługę pełnego zakresu przetwarzania danych – od ekstrakcji do raportowania.

Otwartość (Openness) (2):

Dostęp do danych dla świata zewnętrznego

Także tutaj SAP zrobił krok w stronę otwartości, umożliwiając dostęp do danych w HANA (oraz BW) za pomocą standardowych protokołów. Poniżej widoczne są opcje wyjścia na świat z BW/4HANA. Warty wskazania jest punkt trzeci, który zdecydowanie odświeża podejście do dostępności danych zarządzanych w ramach systemu SAP.

• Open Hub Destination (OHD) – standardowy interfejs wystawiania danych do pliku lub transferowania ich bezpośrednio do wybranej tabeli bazodanowej.
• Dostęp do źródeł ODP poprzez OData – dostęp do danych z ODP InfoProvider za pośrednictwem SAP Gateway, który stanowi interfejs dla dostępu OData/HTTP. Interfejs BW-Gateway realizowany jest za pośrednictwem RFC lub lokalnie, a interfejs Gateway – „świat zewnętrzny” za pośrednictwem OData, który jest standardowym protokołem bazującym na REST/HTTP.
• Bezpośredni dostęp do danych w HANA (za pomocą widoków zarówno natywnych, jak i wygenerowanych z obiektów BW) z narzędzi zewnętrznych za pomocą SQL/MDX, JDBC/ODBC/OData.

Nowoczesny interfejs

Nie będę zagłębiał się w temat UI5 i ujednoliconego look-and-feel, który osiągnięto dzięki koncepcji stojącej za Fiori. Na co chciałbym zwrócić uwagę, to Eclipse jako środowisko deweloperskie. Miałem możliwość pracy na systemach SAP BW 7.4-7.5 oraz BW/4HANA. Im „późniejszy” system, tym więcej funkcji deweloperskich przesuniętych zostało do Eclipse’a. To na plus, bo uważam, że jest to narzędzie przejrzyste, szybkie i przyjemne w obsłudze. We wcześniejszych wersjach BW, przy pracy konieczne było korzystanie z dwóch interfejsów (Eclipse i SAP GUI). Dzięki pełniejszej integracji GUI z Eclipse, pracując na BW/4HANA wielokroć sam Eclipse jest wystarczający.

Co można zyskać dzięki nowym rozwiązaniom SAP?

Podsumowanie

BW/4HANA jest systemem perspektywicznym. Oferuje możliwość wykorzystania najnowszych technologii nie tylko istniejących obecnie, ale – dzięki elastyczności i rozszerzalności – integrację z nowymi rozwiązaniami. SAP kładzie duży nacisk na rozwój produktu, zapewniając częste aktualizacje systemu. Tak, jak w przypadku systemu S/4HANA, uproszczenie oraz optymalizacja do integracji z platformą HANA, dają możliwość łatwiejszego i znacznie wydajniejszego zarządzania danymi. Oczywistym zyskiem jest zwiększona szybkość w wielu aspektach: ekstrakcji danych do systemu, ich przetwarzania oraz raportowania. Efektem końcowym jest znakomicie skrócony czas dotarcia informacji do odbiorcy i – być może – podjęcia na jej podstawie kluczowych dla firmy decyzji, korzystając z uzyskanej dzięki temu przewadze rynkowej.

Dla konsultanta-dewelopera możliwości również znacznie się poszerzyły. Konieczne jest umiejętne spojrzenia na BW/4HANA z kilku perspektyw – uwzględniając inne systemy w landscape-ie, łączność między nimi oraz charakter danych.  Należy mieć na uwadze możliwości modelowania – w świecie BW i w świecie HANA, oraz opcje mieszania tych podejść. Kwestia balansu pomiędzy elastycznością, wydajnością i efektywnością zarządzania tworzonych rozwiązań wydaje się być więc kluczowa.

Źródła i dokumenty (na dzień 11.07.2018):