Dedykowane raporty w systemach SAP

Użytkownicy pracujący od lat na systemach SAP doskonale znają klasyczne raporty uruchamiane poprzez kody transakcji, które na pierwszym ekranie wyświetlają kryteria selekcji, a po naciśnięciu przycisku „zegarka” na ekranie selekcji lub klawisza F8 na klawiaturze pokazują wynik w postaci tabeli tzw. ALV (sAp List Viewer). Niestandardowe raporty tego typu przygotowują programiści, którzy są biegli w zakresie języka ABAP oraz SQL. Niektórzy użytkownicy (tzw. power users) mają również możliwość samodzielnego generowania prostych raportów za pomocą narzędzi, takich jak SAP Query (np. za pomocą transakcji SQVI). Powyższe techniki są dostępne od wielu lat i wciąż są wykorzystywane zarówno w systemach SAP ECC, jak i SAP S/4HANA (On-Premise, Private Cloud).

Trzeba jednak przyznać, że systemy SAP ERP (R/3 oraz ECC) od zawsze słabo radziły sobie z raportami masowymi czy analitycznymi, takimi które agregują duże liczby rekordów. W przeszłości, aby uzyskać wynik działania takiego raportu, konieczne było harmonogramowanie zadań w tle, które po jakimś czasie (np. po kilkunastu minutach, a czasami po kilku godzinach) wyprodukowały wynik. Miało to oczywiście związek z faktem wykorzystania tradycyjnych baz danych jako podstawy działania systemów SAP (dostępy do fizycznych talerzy bazy wymagały wolnych operacji wykonywanych głowicami). Bardzo zaawansowane raporty analityczne trzeba było implementować w dedykowanych systemach BI/BW, które wymagały ustanowienia złożonych mechanizmów ETL (Extract Transform Load).

Sytuację zmieniła baza danych SAP HANA, która całość danych utrzymuje w sposób ciągły w pamięci RAM. Sam hardware oczywiście znacznie poprawił wydajność działania systemów SAP, ale aby uzyskać naprawdę korzystne efekty w postaci szybkości działania, należało opracować również nowy sposób tworzenia raportów i całkowicie zmienić paradygmat. Nowy paradygmat oczywiście nie usuwa potrzeby posiadania nowoczesnych systemów analitycznych, ale niejako zwiększa spektrum możliwości budowy raportów działających bezpośrednio na systemie ERP, gdzie są realizowane wszystkie kluczowe operacje biznesowe.

Opisane powyżej tradycyjne raporty SAP działają wg paradygmatu Data-2-Code, tzn. dane są pobierane poprzez SQL wbudowany w język ABAP na poziom serwera aplikacji i tam procesowane, aby wyprodukować wynik. Razem z bazą danych SAP HANA, SAP zaproponował nowy paradygmat Code-2-Data i przygotował odpowiednie narzędzie software’owe, aby go realizować. Tak powstały widoki CDS (Core Data Services). Schemat jest tutaj odwrotny, na serwer aplikacji pobierany jest ostateczny wynik, a procesowaniem zajmuje się baza danych SAP HANA. Ma to kolosalny wpływ na wydajność ekstrakcji danych.

Wraz z widokami CDS został wprowadzony również nowy koncept uprawnień posadowiony na tzw. rolach DCL (Data Control Language). Nowe role DCL czynią użytek z tradycyjnych obiektów zawartych w rolach PFCG, ale dodają także swoją specyfiką i działają de facto jak filtr, np. jeśli widok CDS zależy od jednostki gospodarczej i posiada rolę DCL walidującą obiekt uprawnień zależny od jednostki gospodarczej, to zapytanie skierowane do tego widoku – z poziomu dowolnego klienta – spowoduje automatyczne odfiltrowanie danych, do których użytkownik nie ma dostępu według jednostki gospodarczej.

Widoki CDS są dostępne od wersji serwera aplikacji ABAP 7.40 i firmy posiadające systemy SAP ECC z bazą danych SAP HANA (produkt Suite on HANA, SoH) mogą z nich również korzystać. Już kilka lat temu w naszym magazynie ukazał się artykuł pt. „Raporty ALV IDA – nawet 30 razy szybsze” (zobacz: www.all-for-one.pl/pl/lepszy-biznes/poradniki), w którym zostało opisane, jak tworzyć tradycyjnie wyglądające raporty ALV (dobrze znany ekran selekcji plus wynik na siatce ALV), ale z całkowicie odmiennym „spodem”, opartym na widokach CDS, a nie tradycyjny ABAP z SQL-em. Takie raporty mają ten walor, że wyglądają zwyczajnie, co dla użytkowników od wielu lat pracujących z systemami SAP nie stwarza żadnej bariery, ale działają wielokrotnie szybciej.

Obserwujemy jednak wciąż umiarkowany popyt na refaktoryzację czy reimplementację (poprawienie kodu lub napisanie od nowa po nowemu) bardzo starych raportów na rzecz nowszej technologii. A przecież „czas to pieniądz”, wolno działające raporty mają realny i negatywny wpływ na każdy biznes. Feedback od klientów, którzy zakupili tak napisane raporty, jest jednak bardzo pozytywny. Użytkownicy zauważają znaczne zwiększenie komfortu pracy z takimi raportami, ponieważ są po prostu bardziej wydajne.

W dalszej części opisane zostały dwa typy nowoczesnych raportów Fiori Elements: raport operacyjny oraz raport analityczny.

Zanim jednak przejdziemy dalej wyjaśnijmy jeszcze, czym jest Fiori Elements w ramach SAP Fiori. Jest to framework zawierający najczęściej używane szablony planów interfejsu użytkownika, przeznaczony do szybkiego rozwoju aplikacji SAP Fiori poprzez zmniejszenie kodu front-endowego pisanego ręcznie, zapewniający spójność i zgodność UX z najnowszymi wytycznymi projektowymi. Innymi słowy, Fiori Elements upraszcza implementację, co ma korzystny wpływ na czasochłonność przygotowania raportów. Zwykłe programowanie SAP Fiori (tzw. freestyle) jest znacznie bardziej czasochłonne i niesie ze sobą więcej ryzyka. Za szablony Fiori Elements odpowiada centralny zespół w firmie SAP, dzięki czemu możemy być pewni ich wysokiej jakości i stabilności działania.

Raport operacyjny jest de facto odpowiednikiem tradycyjnego raportu ALV znanego z SAP GUI. Jest dostępny w SAP Fiori poprzez przeglądarkę internetową i uruchamiany poprzez kafelek SAP Fiori. Odnajdziemy w nim jednak wszystko to, co jest od lat dobrze znane użytkownikom systemów SAP, np.:

• Kryteria selekcji;
• Możliwość zapisania wariantów – zarówno kryteriów selekcji, jak i układu kolumn;
• Przycisk „odpalenia” selekcji (w SAP GUI „zegarek”/F8, a tutaj przycisk Start);
• Siatka z danymi (wiersze/kolumny);
• Wbudowany eksport do Excela;
• Możliwość zmieniania kolejności kolumn, ukrywania kolumn, sortowania, filtrowania na ekranie czy grupowania.

Znajdziemy tu jednak również szereg nowych funkcjonalności, niedostępnych w klasycznych raportach:

• Możliwość wyszukiwania tekstowego na wskroś kolumn tekstowych*;
• Wyszukiwanie według kryteriów selekcji wynikających z asocjacji**;
• Eksport do PDF;
• Możliwość automatycznego uruchamiania selekcji w momencie wejścia do aplikacji;
• Bogaty zestaw kontrolek i meta-informacji, np. generowanie linków, ikon, diagramów – bogatsze UI;
• Możliwość zamodelowania bardzo szczegółowego wglądu w pojedynczą pozycję, łącznie z danymi podrzędnymi będącymi w relacji jeden do wielu do wiersza raportu (w przykładzie zaprezentowanym na zrzutach ekranu jeden wiersz to jedno zamówienie, a w szczegółach widać pozycje zamówienia w osadzonej głębiej tabeli);
• Możliwość zapisania konkretnego układu jako nowy kafelek SAP Fiori.

Raport operacyjny wykorzystuje dwa standardowe plany interfejsu użytkownika SAP Fiori Elements: List Report oraz Object Page.

Raport analityczny nie ma odpowiednika w klasycznym interfejsie SAP GUI. Jest to zupełnie nowa jakość dostępna w S/4HANA. Tego typu raport stał się możliwy dzięki bazie danych SAP HANA oraz technologii widoków CDS (paradygmat Code-2-Data). Raport analityczny łączy w sobie aspekty raportu analitycznego z operacyjnym w tym sensie, że z jednej strony prezentowane są informacje analityczne za pomocą graficznych wykresów różnego typu, a z drugiej mamy pod ręką konkretne szczegółowe wpisy, z których wynika zagregowana informacja prezentowana na wykresach.

Użytkownikowi łatwo jest eksplorować dane na różnych poziomach szczegółowości. Z jednej strony może identyfikować trendy, wartości maksymalne, wartości minimalne, średnie różnych miar, np. sprzedaż, średni czas dostawy itp. w przekroju na różne wymiary (np. dział sprzedaży, dział zakupów, grupa odbiorców czy dostawców, kraje), a z drugiej może zejść do poziomu pojedynczych linii.

Raport analityczny zasadniczo składa się z trzech części:

• Kryteriów selekcji/graficznych filtrów oraz kluczowych wskaźników wydajności (KPI);
• Wykresów analitycznych;
• Siatki danych (wiersze/kolumny) z pojedynczymi rekordami.

Na uwagę zasługuje bogactwo elementów/wykresów graficznych możliwych do zastosowania, dla przykładu:

• Wykres słupkowy;
• Wykres liniowy;
• Wykres bąbelkowy;
• Wykres punktowy;
• Wykres kolumnowy;
• Połączony wykres kolumnowy i liniowy;
• Połączony skumulowany wykres kolumnowy i liniowy;
• Wykres pączka.

Graficzne filtry z kolei mogą przyjąć postać interaktywnego wykresu pączka, liniowego i słupkowego (zobacz przykład na zrzucie ekranu poniżej).

Raport typu ALP obsługuje również warianty, możliwa jest selekcja za pomocą zwykłych kryteriów selekcji lub filtrów graficznych. Widok może być dostosowany tak, aby wyświetlać tylko wykres albo tylko siatkę danych, albo (jak w przykładzie) obydwa elementy jednocześnie.

Raport analityczny wykorzystuje standardowy plan interfejsu użytkownika SAP Fiori Elements: Analytic List Page (ALP).

W systemach S/4HANA możliwe jest również tworzenie raportów typu przegląd (plan Fiori Elements: Overview Page) oraz raportów z różnymi kluczowymi wskaźnikami wydajności (KPI). Są to inne zaawansowane opcje, na które brakuje już miejsca w tym artykule. Niemniej są one tworzone według podobnych zasad, tzn. podstawą są widoki CDS wraz z określonymi meta-informacjami.

Dodatkowo w S/4HANA dostępnych jest szereg funkcjonalności nazywanych Embedded Analytics. Dostępne są aplikacje do przeglądania widoków, do przeglądania zapytań, można nawet „wyklikać” widoki CDS, co jest w pewnym sensie odpowiednikiem klasycznych narzędzi, takich jak SAP Query. We wszystkich tych zagadnieniach All for One Poland służy pomocą.

W systemach S/4HANA mamy wiele możliwości w zakresie raportowania. W systemach On-Premise i Cloud Private Edition można używać wszystkich dostępnych od lat technik programowania ABAP. W systemach Public Edition SAP udostępnia wyłącznie nową technologię.

Warto jednak wykorzystać nowinki techniczne, bo mogą przynieść realne korzyści. Kluczowymi technologiami są widoki CDS, które pozwalają wykorzystać potencjał bazy danych SAP HANA, oraz nowy interfejs użytkownika SAP Fiori. Połączenie obu technologii daje możliwość tworzenia atrakcyjnych wizualnie raportów SAP Fiori Elements uruchamianych w przeglądarce internetowej. Z możliwości SAP HANA – mających wpływ na szybkość działania – mogą również skorzystać firmy działające wciąż na systemach ECC (Suite on HANA). W S/4 warto też wykorzystać możliwości tkwiące w standardowych funkcjonalnościach tzw. Embedded Analytics.

*opcja dostępna również w podejściu hybrydowym w raportach ALV opartych na widokach CDS

**ta opcja wymaga wyjaśnienia na przykładzie: jeśli w raporcie mamy kolumnę z numerem dostawcy, bo jest on zawarty w nagłówku zamówienia, a zatem jest w wierszu naszego raportu, to jeśli widok CDS z rekordem dostawcy zawiera pole np. z domyślnymi warunkami płatności tego dostawcy i ten widok jest podpięty poprzez tzw. asocjację do głównego widoku CDS raportu, to automatycznie oznacza to, że możemy wyciągnąć pole z domyślnym warunkiem płatności jako kryterium selekcji. To stwarza ogromne możliwości selekcji danych, znacznie większe niż w tradycyjnych raportach znanych z SAP GUI, gdzie programista musiał z góry przewidzieć kryteria selekcji (niektóre raporty standardowe oferowały tzw. dynamiczne selekcje, ale programowanie ich w niestandardowych raportach raczej nie należało do regularnej praktyki ze względu na znaczną złożoność kodu takiego raportu).