Aplikacje standardowe SAP Fiori to portfolio dostępnych aplikacji, w których na starcie otrzymujemy określoną funkcjonalność. Bardzo często są w nich przygotowane fragmenty kodu lub opcje do aktywowania, umożliwiające dostosowanie ich jeszcze bardziej pod potrzeby biznesowe. Te specjalne fragmenty to tzw. rozszerzenia (ang. enhancements), o których będzie mowa w tym artykule.
Kiedy otrzymujemy zadanie rozszerzenia funkcjonalności standardowej aplikacji SAP Fiori, istnieje kilka aspektów, które warto sprawdzić przed przystąpieniem do pracy. Jeśli planujemy dodać nowe pole, istnieje możliwość, że jest ono już dostępne do dodania na poziomie serwisu, a informacja o tym może być zawarta w dokumentacji. Spróbujmy odrobinę usystematyzować miejsca, które warto sprawdzić, aby mieć pewność, że nasz wybór jest optymalny.
Dla przykładu użyjemy standardowej aplikacji „Revise Payment Proposals” i spróbujemy dodać nowe pole, takie jak Item text w oparciu o analizę Rogera Sainsbury’ego.
Rodzaje rozszerzeń
Personalizacja
Czasami zdarza się, że pole, które chcemy dodać, jest już dostępne w opcjach personalizacyjnych (ustawieniach widoku). Wystarczy wówczas pamiętać o sprawdzeniu tego w ustawieniach aplikacji.
Dostosowanie (ang. customizing)
W niektórych aplikacjach Fiori dostosowanie może być łatwe poprzez użycie transakcji SPRO – pole włącz/wyłącz. Istnieje też możliwość przejścia do opcji SPRO w uproszczony sposób. Aby odblokować możliwość korzystania z funkcji ok_code w aplikacji, należy uruchomić „GUI Actions and Settings”:
Następnie zaznaczamy opcję „Show OK Code Field”:
W ten sposób otrzymujemy dostęp do SPRO bez konieczności instalacji natywnego front-endu SAPGUI front-end oraz unikając ograniczeń związanych z pobieraniem nowych plików i autoryzacją na komputerach korporacyjnych.
Adaptacja typu run-time (RTA)
RTA to funkcjonalność, która umożliwia przypisanie super użytkownika, zdolnego do dokonywania podstawowych zmian w aplikacji Fiori. Te zmiany zostaną zastosowane dla wszystkich użytkowników, w przeciwieństwie do personalizacji, która pozwala na dostosowanie zmiany tylko dla danego użytkownika.
Aby skorzystać z adaptacji typu run-time, użytkownik musi być przypisany do roli SAP_UI_FLEX_KEY_USER w Gateway’u na front-endzie. Wówczas opcja Adapt UI zostanie udostępniona w Launchpadzie Fiori. Niestety, na dzień dzisiejszy ta opcja jest dostępna tylko w aplikacjach wykorzystujących kontrolki SmartForms oraz ObjectPage, na przykład w aplikacji „Purchase Requisition Item Factsheet”.
Na przedstawionym wyżej przykładzie, można użyć Trybu Adaptacji UI do wprowadzenia zmian bez użycia kodu.
Jeśli żadne z powyższych rozwiązań nie pozwala nam na dokonanie potrzebnych zmian w standardowej aplikacji Fiori, pozostają nam dwie bardziej rozbudowane metody – na front-endzie (SAP WEB IDE) lub na back-endzie (serwis ODATA).
Rozszerzenia Fiori za pomocą SAP WEB IDE
W pierwszej kolejności warto sprawdzić dokumentację standardowej aplikacji Fiori w poszukiwaniu tzw. „extension poits” lub „hooks”.
Jeśli zdecydujemy się na taką zmianę, możemy ją wykonać na poziomie SAP WEB IDE, np. poprzez zamianę widoku.
Gdy zdecydujemy się zastąpić widok (na przykład „S3”), powstanie wówczas nowy projekt z końcówką „Extension”, który zawiera kopię standardowego widoku.
W nowym projekcie, w pliku manifest.json znajdzie się dodatkowy kod łączący oryginalną aplikację z naszą nową, rozszerzoną.
Jeśli w przyszłości postanowimy usunąć tę poprawkę, wystarczy usunąć dodatkowy kod, a aplikacja powróci do oryginalnego widoku.
Za pomocą WEB IDE możemy również zmienić tłumaczenia tekstów, na przykład dla nowo wprowadzonego pola. Podczas tworzenia projektu typu „extension” w Web IDE jest opcja „i18n Resource Text Customization”.
Gdy wybierzemy tę opcję, plik i18n oraz pliki ze standardowej wersji aplikacji zostaną skopiowane do aplikacji z rozszerzeniem:
Wówczas możemy dodać dodatkowe pole dla wprowadzonej przez nas kolumny.
Po dokonaniu zmian, pamiętajmy o wykonaniu deploy’a („deploy as a new app”). W ten sposób rozszerzona aplikacja pojawi się jako nowa aplikacja BSP:
Aby uruchomić rozszerzoną aplikację, konieczne jest również odpowiednie skonfigurowanie mapowania kafelka oraz elementu docelowego (Tile and Target Mapping) w katalogu Fiori.
Mając na uwadze, że w obiekcie semantycznym konieczne jest użycie odmiennej nazwy niż w przypadku aplikacji standardowej:
Podczas tworzenia mapowania docelowego (Target Mapping), adres URL powinien zawierać nazwę nowej aplikacji BSP (można ją odnaleźć również za pomocą transakcji SICF). Natomiast nazwa komponentu może być odnaleziona w pliku Component.js projektu rozszerzonego:
Aby przeprowadzić test, pamiętajmy o uruchomieniu kafelka z nową rozszerzoną aplikacją.
Rozszerzenia standardowych usług ODATA
Zgodnie z metodologią Sebastiana Gaera, dodawanie nowego pola w serwisie ODATA składa się z trzech kroków:
- Najpierw rozszerzamy odpowiednią strukturę ABAP DDIC poprzez komendę APPEND STRUCTURE.
- Następnie rozszerzamy ODATA Entity w Gateway Model Providerze.
- Na końcu wypełniamy dane rozszerzonego pola w Gateway Data Providerze.
W aplikacji „Revise Payment Proposals” istnieje możliwość dodawania „custom fields”:
Najpierw tworzymy i aktywujemy własne pole w słowniku – ZZSGTXT.
Pole to dodajemy do struktury ze standardowej aplikacji:
W drugim kroku, pakiet „ODATA_REVISE_PAYMENT_PROPOSAL” zawiera zarówno klasę Model Provider, jak i Data Provider dla danego serwisu ODATA.
Dodajemy nowe pole dla enitity „PaytProposalInvoice”.
Przegenerowujemy obiekty typu run-time poprzez kliknięcie przycisku:
W rezultacie klasa MPC o nazwie CL_FAP_REVISE_PAYMENT_MPC dostaje kilka dodatkowych linii kodu:
Następnie, aby w kroku trzecim wprowadzić dane do nowego pola, musimy zlokalizować metodę: CL_FAP_REVISE_PAYMENT_DPC_EXT->PAYTPROPOSALINVO_GET_ENTITYSET.
Ta metoda jest już zredefiniowana i na samym końcu posiada rozszerzenie (enhancement), do którego możemy dodać kod pobierający tekst z pola BSEG-SGTXT i przekazujący go do tabeli et_entityset (zawiera ona dane dla całego zbioru entity).
Na sam koniec, pamiętajmy także o dodaniu nowej kolumny w widoku na front-endzie, aby dane z nowego pola prawidłowo się wyświetlały:
Podsumowanie
Serwis ODATA może być modyfikowany również przy użyciu BAdI (Business add-ins), jednak te dodatki nie są dostępne dla wszystkich standardowych aplikacji SAP Fiori. Widoki Fiori mogą być również stworzone na poziomie back-endu za pomocą ‘CDS Views’, a wtedy do rozszerzeń aplikacji można używać adnotacji (annotations) po stronie back-endu i front-endu. O tym jednak opowiemy w oddzielnym artykule.
Podsumowując, rozszerzanie standardowych aplikacji Fiori jest możliwe na wiele różnych sposobów i zależą one dość mocno od opcji jakie zostały nam udostępnione przez firmę SAP. W skrajnych przypadkach możemy po prostu wykonać rozszerzenie całej aplikacji.
***
Jeśli interesuje Cię tematyka SAP, zajrzyj koniecznie do innych artykułów naszych ekspertów.
Zostaw komentarz