SAP

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

Październik 19, 2018 0
Podziel się:

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.

BW4HANA InfoProviders - BW/4HANA - ciąg dalszy (r)ewolucji

Obiekty w BW/4HANA, źródło (na 11.07.2018) : „BW/4HANA Overview and Roadmap”, link


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.

Lp. Kategoria BW (anyDB/powered by HANA) BW/4HANA
1 Dane z systemów innych niż SAP DB Connect HANA Source System
UD Connect
SAP Data Services
BAPI/Partner
HANA Source System
2 Dane z systemów SAP ODP ODP
Service API (SAPI – ekstraktory)
BW
Web Services
3 Pliki File File
4 Big Data BigData

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

 

BW4HANA Source Systems - BW/4HANA - ciąg dalszy (r)ewolucjiSystemy źródłowe w BW/4HANA, źródło (na 11.07.2018) : „BW/4HANA Overview and Roadmap”, link

 


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.

BW4HANA Mixed modeling approach - BW/4HANA - ciąg dalszy (r)ewolucji

The Three-Approach Strategy, źródło (na 11.07.2018) : „BW/4HANA Overview and Roadmap”, link

 


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?

Aspekt Opis
Ekstrakcja danych Dzięki interfejsowi ODP, zapewniony jest duży stopień kompresji (>90%) pobieranych danych. Zarządzanie listą odbiorców i dostawców informacji jest realizowane w jednym narzędziu i jest bardziej przejrzyste. Ekstrakcja jest szybsza dzięki uproszczonemu interfejsowi i rezygnacji z technologii ALE/IDOC.

Możliwe są interfejsy (near) real-time i direct access, które przyspieszają dostęp do informacji.

Modelowanie / Utrzymanie systemu Mniejsza liczba obiektów do modelowania, mniejsza liczba systemów źródłowych oraz prostsze tworzenie łańcuchów procesów zmniejszają wysiłek związany z tworzeniem nowych rozwiązań i utrzymaniem systemu.
Transfer danych Dzięki możliwości transferu i przetwarzania danych bezpośrednio w obrębie bazy (bez tzw. Roundtrips, czyli db->serwer aplikacyjny->db), proces ten jest znacznie szybszy.
Aktywacja danych Aktywacja danych (obliczanie zmian i delty) odbywa się na HANA-ie, więc jest znacznie szybsza, niż z w przypadku wykonania tego procesu na serwerze aplikacyjnym.
Raportowanie 10x-100x szybsze niż na systemach BW nie korzystających z bazy HANA, dzięki realizacji funkcji OLAP w dużej mierze na HANA-ie.
Data staging / wirtualizacja Dzięki wykorzystaniu koncepcji LSA++ zmniejsza się całościowa ilość danych w systemie oraz liczba warstw systemu, przyśpieszając proces “dotarcia” danych do odbiorcy/raportowania.

 


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):

Dokument Link
SAP BW/4HANA – Technical Overview Link do dokumentacji
SAP BW/4HANA – Overview and Roadmap Link do dokumentacji
SAP BW/4HANA FAQ Link do dokumentacji
SAP BW/4HANA 1.0 SPS04 – Documentation Link do dokumentacji
Open ODS View Link do dokumentacji
SAP BW/4HANA in a Nutshell Kurs dostępny na https://open.sap.com
SAP Business Warehouse powered by SAP HANA (Update Q2/2016) Kurs dostępny na https://open.sap.com
5 / 5
Tagi: , ,
Kategorie: SAP
Bartosz Kurowski
Autor: Bartosz Kurowski
Konsultant i deweloper SAP BW/HANA z nutą ABAPa.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz