Blog

FIS-SST

Refactoring aplikacji SAP Fiori

W ostatnim czasie zajmowaliśmy się ciekawą aplikacją do zarządzania alokacjami oraz promocjami.

Dzięki aplikacji każdy sklep może za pomocą przeglądarki internetowej zalogować się do aplikacji i ma możliwość przeglądu nadchodzących alokacji lub zaktualizować ilości produktów do zamówienia lub ilości produktów w alokacji.

Aplikacja została zaimplementowana w technologii SAP Fiori. SAP Fiori to najnowsza wersja interfejsu użytkownika od SAP zapewniająca jednolite doświadczenia użytkownika podczas korzystania z rozwiązań lokalnych i chmurowych.

Po wielu latach od premiery pierwszej graficznej wersji SAP GUI, SAP dostosował się do współczesnych standardów i w całości przeprojektował nie tylko interfejs użytkownika, ale również zmienił sposób, w jaki użytkownik z niego korzysta.

Filozofia, która przyświecała tworzeniu nowego wrażenia dla użytkownika to Design Thinking – projektowanie aplikacji mając na celu przede wszystkim jakość i komfort użytkowania aplikacji, patrząc z perspektywy użytkownika biznesowego. Ta zmiana w podejściu do procesu tworzenia rozwiązań powoduje, że użytkownik otrzymuje spójne, responsywne i intuicyjne środowisko do wykonywania codziennych zadań. Poprzez przejście na interfejs wyświetlany w przeglądarce i zastosowanie adaptacyjnego interfejsu użytkownika otrzymujemy swobodny dostęp do danych bez względu na zastosowane urządzenie.

Dzięki wykorzystaniu SAP Fiori użytkownicy mogą częściej sięgać po potrzebne im informacje, co skraca czas i poprawia efektywność pracy. Pracownicy uzyskują możliwość wprowadzania informacji niezbędnych do podjęcia decyzji niezależnie od miejsca, w którym się znajdują, oraz urządzenia, z którego korzystają.

Jednak SAP Fiori to tylko część frontonowa. Logika biznesowa która zasilała aplikację danymi również musiała zostać zaimplementowana. Komunikacja między aplikacją w przeglądarce internetowej oraz systemem SAP odbywa się za pomocą protokołu OData. W skrócie Open Data Protocol (OData) – protokół sieciowy służący do pobierania oraz aktualizowania danych stworzony przez firmę Microsoft. Serwis OData jest wystawiany przez system SAP do skonsumowania przez aplikację Fiori.

Jak to działa?

Na systemie backendowym tworzymy serwis Odata który jest wystawiany na zewnątrz systemu SAP do skonsumowania przez aplikację. Do tworzenia serwisu służy transakcja SEGW. Dla każdego serwisu tworzymy zestaw encji czyli reprezentację wyobrażonych lub rzeczywistych obiektów.

Przykłady encji (i atrybuty w encji):

·        Osoby (imię, nazwisko, PESEL)

·        Pojazdy (wysokość, szerokość, długość, sposób poruszania się)

Po zdefiniowaniu encji oraz wygenerowaniu serwisu zostaną utworzone 4 klasy w słowniku ABAP.

Programista powinien modyfikować jedynie klasy kończące się sufixem _EXT. Są to klasy dziedziczące. (Patrz diagram UML poniżej). Podczas pracy należy redefiniować metodę klasy dziedziczącej i zaimplementować tam swój kod. Jest to zrobione w taki sposób ponieważ podczas następnego przegenerowania serwisu Odata cały kod klas MPC oraz DPC jest nadpisywany (generowany od zera). Gdybyśmy zaimplementowali nasze zmiany bezpośrednio w klasach MPC i DPC stracilibyśmy nasz kod.

·        Klasa MPC – Model Provider Class – posiada główną metodę DEFINE w której zdefiniowane są wszystkie encje oraz ich atrybuty za pomocą kodu.

·        Klasa DPC – Data Provider Class – Klasa jest odpowiedzialna za dostarczenie danych z systemu lub dokonywanie zmian na systemie. Dla każdej encji zostaną wtgenerowane poniższe metody:

  Create – uruchamiana jest podczas tworzenia nowego obiektu

  Delete – uruchamiana jest podczas usuwania obiektu

  GetEntity – uruchamiana jest gdy checemy dostać informacje o konkretnym rekordzie – w parametrach metody powinien znaleść się pełen klucz encji

  GetEntitySet – uruchaiana jest gdy aplikacja pyta nie o pojedyńczy rekrd a o cały zbiór (tabele) rekordów, na podstawie jakiś kryterów selekcji

  Update – uruchamiana jest gdy obiekt już isnieje ale należy w nim coś zmienić

Logika biznesowa tworząca zamówienia, aktualizująca dane, sortowanie kolumn, filtrowanie zawartości, aby znaleźć odpowiednie rekordy i wiele innych musi zostać zaimplementowane po stronie serwera SAP.

Wyzwaniem w tego typu zadaniach jest ciągła komunikacja między osobami zajmującymi się frontendem oraz backendem. Czasami podczas implementacji pewnych rozwiązań nie jest oczywiste czy lepiej zaimplementować je po stronie serwera czy klienta. W takich wypadkach zalecane jest szybkie spotkanie zaangażowanych osób i omówienie przyczyn i możliwych rozwiązań. Szczególnie gdy nad aplikacją ciąży presja czasu i rozwiązanie mus być dostarczone w ciągu kilku dni. Jednak nasz zespół pokazał, że umie pracować również bardzo intensywnie i efektywnie.

Autor: Jakub Lewandowski

Formularz kontaktowy

Patrycja Pałus

Office Administrative Assistant

Zapraszam do kontaktu telefonicznego lub mailowego