Rozwiązywanie problemów z autoryzacją SAP FIORI

Środowisko SAP FIORI jest dostępne na rynku od wielu lat. Mimo to nadal bardzo często, niemal w każdym projekcie, w którym uczestniczyłem, wielu użytkowników preferuje korzystanie ze standardowego interfejsu użytkownika SAP GUI – interfejsu, którego obecna forma sięga początku lat 90. ubiegłego wieku!

Gdy pytam użytkowników i konsultantów biznesowych, z czego to wynika, bardzo często otrzymuję odpowiedzi w stylu: „A bo tak się przyzwyczaiłem, bo z tym FIORI to same problemy – mam dostępy, a nie widzę aplikacji”, „Ciągle coś nie działa, kafelki się nie otwierają, otrzymuję błędy przeglądarki – więc wolę szybko sprawdzić w GUI”, „W GUI to mam wszystko widoczne, a tu w FIORI to nie widzę danych, coś mi nie wyszukuje”.

Wielu użytkowników od razu kojarzy tego typu problemy z czymś skomplikowanym, sytuacją, gdzie analiza przyczyny potrwa długo, a może nawet będzie wymagała developmentu. Wybierają więc drogę „na skróty”, wracając do interfejsu SAP GUI, który lata świetności ma już za sobą i od strony wizualnej, przedstawiania/analizy danych, a ogólnymi możliwościami w rzeczywistości ustępuje aplikacjom FIORI niemal na każdym kroku.

By odczarować trochę obraz SAP FIORI jako środowiska, w którym namierzenie przyczyn problemów z widocznością czy działaniem kafelków FIORI wydaje się skomplikowane i czasochłonne, w poniższym artykule opiszę przyczyny najczęściej występujących problemów, których rozwiązanie, jak się okazuje, w większości przypadków jest bardzo proste i nie wymaga dużej ilości czasu. Przedstawię również przydatne narzędzia, które służą do analizy przyczyn problemów, zbierania oraz śledzenia logów aplikacji, a także miejsca, gdzie finalnie możemy naprawić nasz problem z aplikacją.

SAP FIORI – architektura dostępu do aplikacji

SAP FIORI, najprościej rzecz ujmując, jest nakładką na system SAP ERP – obecnie najczęściej S/4 HANA, gdzie jest bazowym rozwiązaniem. FIORI jest zbudowane na bazie frameworka SAPUI5, który oparty jest na technologiach HTML5, CSS i JavaScript. Dzięki temu, aplikacje FIORI mogą być rozwijane i dostosowywane z wykorzystaniem nowoczesnych technologii webowych.

Jednak finalnie i tak dane oraz aplikacje pobierane są z systemu SAP S/4 HANA opartego na języku ABAP, z którym FIORI jest bezpośrednio zintegrowane. W obecnym podejściu używa się konfiguracji SAP FIORI Embedded. Oznacza to, że zarówno frontend jak i backend działają w jednym systemie SAP. Poniżej znajduje się schemat obsługi dostępu do aplikacji SAP FIORI:

Warstwy integracji

Jak widać na powyższej grafice, są tutaj trzy główne warstwy takiej integracji, a więc:

• Backend Server (BES) – warstwa logiki biznesowej. W uproszczeniu możemy przyjąć, że jest to nasz system S/4 HANA. W tej warstwie znajdują się role biznesowe przypisane do użytkowników. Zawierają one takie informacje o aplikacjach FIORI jak: katalogi, w których się znajdują, serwisy oData (IWSV), transakcje ABAP, z których korzystają, aplikacje Web Dynpro itp.
• SAP Frontend Server (FES) – w dużym uproszczeniu to, co się dzieje w tle samego środowiska FIORI. To w tej warstwie jest wysyłane żądanie o dany dostęp do systemu Backend poprzez SAP Gateway. Warstwa ta również zawiera role dostępowe z informacjami takimi jak: katalogi, grupy, serwisy oData (IWSG).
• SAP FIORI Launchpad (FLP) – końcowa warstwa – wizualna, już bezpośrednio dostępna i widoczna dla użytkownika. To tutaj użytkownik uruchamia i przegląda aplikacje FIORI.

Już na pierwszy rzut oka można się domyśleć, że problemy mogą pojawić się na poziomie każdej z tych warstw.

Najczęściej występujące problemy

Przyjrzyjmy się więc najczęściej występującym problemom oraz ich przyczynom.

Uwaga! Zanim przejdziemy dalej 😊 Artykuł opisuje sytuacje, w których użytkownik teoretycznie powinien posiadać już dostęp do danych aplikacji SAP FIORI, a mimo to nadal ma pewne problemy z ich widocznością lub działaniem. Przyjmuję również, że czytelnik posługuje się transakcjami takimi jak SUIM, SU01 oraz PFCG, by móc odnaleźć rolę z brakującym obiektem autoryzacyjnym (wynikającym np. z logów SU53) i przypisać ją użytkownikowi, zmodyfikować wybraną istniejącą rolę lub utworzyć nową rolę w systemie SAP.

Dla przypomnienia, weryfikacji, czy użytkownik posiada już odpowiednią role, która teoretycznie powinna mu dawać dostęp do danej aplikacji FIORI, możemy dokonać na dwa sposoby:

• W przypadku standardowych aplikacji SAP FIORI otwieramy ogólnodostępną Bibliotekę aplikacji SAP FIORI, wybieramy kategorię All apps, następnie odpowiednią wersję systemu SAP i w zakładce Configuration w tabeli Business Role(s) mamy listę ról, które umożliwiają dostęp do wybranej aplikacji. Potem w transakcji SU01 lub PFCG weryfikujemy, czy użytkownik ma już tę rolę przypisaną.

• W przypadku standardowych oraz niestandardowych (custom) aplikacji SAP FIORI otwieramy w SAP GUI transakcję /n/UI2/FLPCM_CUST, przechodzimy do zakładki Tiles/Target Mappings i wpisujemy dokładną nazwę naszego kafelka FIORI (wielkość liter i spacje mają znaczenie!), zaznaczamy go i wybieramy opcję Show usage in Roles. Potem w transakcji SU01 lub PFCG weryfikujemy, czy użytkownik ma już tę rolę przypisaną.

Warto również zwrócić uwagę, czy wyszukana przez nas aplikacja FIORI znajduje się w katalogu FIORI w formie (Tile+TM) i czy ten katalog jest przypisany do roli FIORI, którą użytkownik posiada lub którą chcemy mu przypisać.

By to zweryfikować, należy dokonać tych samych kroków, co w poprzednich punktach, i na końcu wybrać opcję Show usage in Roles, sprawdzić kolumnę Reference Details i w transakcji PFCG upewnić się, czy katalog jest przypisany do roli, którą użytkownik ma lub którą chcemy mu przypisać.

Jeżeli dana aplikacja nie jest dostępna w żadnym katalogu z informacją, że składa się ona z (Tile + TM), wtedy brakujący element Tile lub TM należy dodać do odpowiedniego katalogu FIORI. Jest to jednak kwestia na zupełnie osobny artykuł.

Na ten moment pozostawiam link do dokumentacji SAP, która opisuje podobne przypadki: SAP Fiori Launchpad Content Manager – Adding and Removing Catalog Content.

Błędy podczas otwierania kafelka FIORI

Scenariusz 1.

W SAP Launchpad znaleźliśmy interesującą nas aplikację FIORI. Chcemy ją otworzyć, jednak trwa to bardzo długo i finalnie zamiast okna aplikacji otrzymujemy błąd przeglądarki 403/404 – przykład takiego błędu poniżej:

Oznacza to, że jakiś serwis oData (usługa, która komunikuje się pomiędzy frontendem i backendem) nie działa poprawnie, nie jest aktywny lub w ogóle nie został zaimplementowany w systemie.

By to przeanalizować i naprawić należy:

Krok 1. Uruchomić transakcję /n/UI2/FLPCM_CUST

Krok 2. Wyszukać w zakładce Tiles/Target Mappings interesującą nas aplikację, zaznaczyć ją i wybrać opcję Services -> Check and Show Services. Sprawdzić zakładki oData V2 Services oraz oData V4 Services. Poniżej zrzuty ekranów z transakcji:

Jeżeli w tych zakładkach którykolwiek z serwisów oData posiada czerwony status (jest nieaktywny) – należy:

• przejść do transakcji /n/IWFND/MAINT_SERVICE. W kolumnie External Service Name poszukać naszego nieaktywnego serwisu oData, zaznaczyć go i w lewym dolnym rogu w oknie ICF Services, aktywować go za pomocą opcji ICF Node -> Activate:

Jeżeli status serwisu się nie zmienił i otrzymamy komunikat systemowy z informacją, że nie możemy aktywować serwisu, należy wtedy wybrać opcję ICF Node –> Configure SICF. Zostaniemy przekierowani do transakcji SICF – bezpośrednio do drzewka obiektów z naszym serwisem. Jeżeli jest on dezaktywowany (wyszarzony), należy kliknąć na niego prawym przyciskiem myszy i wybrać opcję Activate Service i w następnym oknie zatwierdzić to, wybierając drugą opcję Yes, jak na poniższych zrzutach ekranu:

Gdy wrócimy do naszego serwisu w transakcji /n/IWFND/MAINT_SERVICE, będzie on już aktywny. Jego status na „zielony” zmieni się również w zakładkach oData w transakcji /n/UI2/FLPCM_CUST, o której wspomniałem na początku Kroku 2.

• przejść do transakcji /n/IWFND/MAINT_SERVICE, w kolumnie External Service Name poszukać naszego nieaktywnego serwisu oData. Jeżeli jednak nie możemy go wyszukać, oznacza to, że nie został on zaimplementowany w naszym systemie.Jak tego dokonać? Tutaj odsyłam do poniższych artykułów:
  • dla oData V2: SAP Note 2525224 – Missing OData Service when Attempting to Add Service in /IWFND/MAINT_SERVICES i Activate OData Services for Sana SAP Fiori Apps
  • dla oData V4: Publish/Activate an oData V4 Service Group in SAP i OData V4 Service Catalog

Gdy serwisy zostaną zaimplementowane, aktywowane i wrócimy do naszego serwisu w transakcji /n/IWFND/MAINT_SERVICE, będzie on już aktywny. Jego status na „zielony” zmieni się również w zakładkach oData w transakacji /n/UI2/FLPCM_CUST, o której wspomniałem na początku Kroku 2.

Krok 3. Przetestowanie działania aplikacji w SAP FIORI Launchpad, najlepiej po odświeżeniu strony z ewentualnym wyczyszczeniu ciasteczek/cache przeglądarki lub ponownym zalogowaniu się do SAP FIORI.

Scenariusz 2.

W SAP Launchpad znaleźliśmy interesująca nas aplikację FIORI, chcemy ją otworzyć, jednak trwa to bardzo długo i finalnie zamiast okna aplikacji otrzymujemy błąd przeglądarki 403/500 – Request Failed, przykład:

Należy postępować analogicznie jak w Scenariuszu 1, z tą różnicą, że w Kroku 2, sprawdzamy zakładkę ICF Services. Jeżeli jakikolwiek serwis ICF jest nieaktywny, należy go zaznaczyć i wybrać opcję Define Services, a potem aktywować serwis ICF analogicznie, jak w Scenariuszu 1 – Krok 2 w momencie, gdy system przekierował nas do transakcji SICF:

Błąd 403/500 – Request Failed lub Component failed może mieć również podłoże bezpośrednio autoryzacyjne w systemie SAP S/4 HANA. Użytkownik może nie posiadać odpowiednich dostępów do obiektu autoryzacyjnego S_RFCACL, co diagnozujemy za pomocą transakcji SU53, STAUTHTRACE lub App Support (w FIORI). O tych narzędziach wspomnę jeszcze w dalszej części artykułu.

Scenariusz 3.

Kroki wykonane w Scenariuszach 1. oraz 2. nie pomogły, a dodatkowo otrzymujemy poniższy komunikat:

Oznacza to, że aplikacja nadal nie może odnaleźć jakiegoś serwisu oData, a co za tym idzie – również serwisu ICF. By to zweryfikować, należy wykonać Krok 1 oraz Krok 2 ze Scenariusza 1 i sprawdzić, czy ilość serwisów oData V2 i V4 zgadza się z dokumentacją dla tej aplikacji w Bibliotece FIORI. Jeżeli jakiegoś serwisu brakuje, należy go dodać analogicznie jak w Scenariuszu 1, Krok 2(b).

Błędy autoryzacyjne w widokach CDS

Widoki CDS (Core Data Services) w SAP pozwalają na tworzenie zaawansowanych, wydajnych i złożonych modeli danych oraz logiki aplikacyjnej na poziomie bazy danych. Widoki tego typu możemy otwierać poprzez SAP FIORI. Jednak dostęp do wspomnianych modeli danych (Virtual Data Model) w widokach CDS jest zawsze kontrolowany poprzez kombinację poniższych autoryzacji:

• klasycznego sprawdzania obiektów autoryzacyjnych – przez authorization check w kodzie ABAP. W tym przypadku są to obiekty (S_TCODE, S_START, S_SERVICE, SDDLVIEW itp.), które dzieją się podczas uruchamiania aplikacji;
• weryfikacji autoryzacji użytkownika na poziomie źródła danych widoku CDS, odbywającej się dynamicznie w czasie korzystania z widoku, gdy pobiera on kolejne dane. Uprawnienia w kodzie widoku CDS są na bieżąco porównywane z autoryzacjami użytkownika, które posiada w PFCG.

Poniżej schemat z porównujący standardowe podejście do weryfikowania autoryzacji dla aplikacji opartych na ABAP, oraz podejście DCL dla widoków CDS:

Podejście DCL (Data Control Language) definiuje, jakie dane użytkownik może zobaczyć, zależnie od jego uprawnień. Stosuje się głównie do ograniczania dostępu do danych na poziomie rekordów (row-level security), a także do kolumn (column-level security) w modelach danych CDS.

Raz zdefiniowane reguły autoryzacji są automatycznie stosowane do wszystkich zapytań, które korzystają z danego widoku CDS, zapewniając spójność i redukując ryzyko błędów. Umożliwia to dynamiczne i kontekstowe dostosowanie dostępu do danych na podstawie atrybutów użytkownika, co jest trudniejsze do osiągnięcia w klasycznym podejściu.

Z racji na bardziej elastyczne oraz bardziej wydajne działanie, widoki CDS oraz podejście DCL jest stosowane coraz częściej również w standardowych transakcjach SAP. Jako przykładem posłużę się tutaj aplikacją Display Material (MM03).

Śledzenie użytkownika i symulacja dostępów do danych w CDS

W transakcji STAUTHTRACE uruchomiłem śledzenie swojego użytkownika w celu weryfikacji, z jakich autoryzacji próbuje skorzystać. Po uruchomieniu aplikacji Display Material (MM03) otrzymałem następujące logi:

Jak widać w kolumnie CDS Entity pojawiła się informacja o tym, że część danych, które zostały mi wyświetlone w aplikacji Display Material (MM03) pochodzi z widoku CDS i dostęp do nich jest autoryzowany właśnie na poziomie widoku CDS.

I tutaj istotna uwaga – tego typu informacji nie otrzymamy w SU53! Dlatego w celu dokładniejszej weryfikacji logów/błędów autoryzacyjnych, warto korzystać również z transakcji STAUTHTRACE. Ponadto, z poziomu logów jestem w stanie bezpośrednio przejść do aplikacji CDS Access Control, która umożliwi mi sprawdzenie, co dokładnie jest weryfikowane w tym widoku CDS w celu wyświetlania mi odpowiednich danych. Poniżej przykład dla wcześniej wywołanego widoku:

Jak widać, mamy fragment kodu, który na poziomie widoku CDS porównuje wprowadzone tutaj wartości obiektów autoryzacyjnych z obiektami autoryzacyjnymi posiadanymi przez użytkownika aktualnie przeglądającego ten widok CDS i na tej podstawie decyduje, czy ten konkretny zestaw danych może zostać wyświetlony bądź nie.

W powyższym przykładzie zestaw danych dotyczy dostępu do grup produktowych (obiekt M_MATE_MAT, pole: BEGRU) i widok CDS sprawdza, jakie dostępy do obiektu posiada użytkownik i wyświetli dane tylko dla tych grup produktowych (BEGRU), w których użytkownik posiada w polu aktywności wartości 03 (Display) i F4 (Display in Value Help).

W przeciwieństwie do klasycznego podejścia system nie sprawdza w skrypcie ABAP każdej wartości pola aktywności (ACTVT) użytkownika dla danych grup produktowych z pola BEGRU, tylko „pobiera” jego dostępy (aktywności) do wartości z pola BEGRU i na poziome skryptu bazy danych sprawdza, czy wśród tych wartości są te wskazane w zapytaniu widoku CDS. Jeżeli są – wyświetla te dane. Bardzo pomocnym narzędziem umożliwiających weryfikację do jakich danych w widoku ma dostęp konkretny użytkownik, jest CDS Access Control Runtime Simulator (SACM):

Na Ryc. 20 widać, że mój użytkownik ma w tym widoku dostęp do wszystkich danych. Jednak na Ryc. 21 użytkownik z innymi rolami posiada już tylko dostęp do jednej grupy produktowej oznaczonej jako XYZ. I tylko dane dla tej grupy produktowej zostaną mu wyświetlone w aplikacji korzystającej z tego widoku CDS.

Jest to bardzo przydatne w przypadku, gdy użytkownik nie widzi części danych, a nie otrzymuje żadnego błędu autoryzacyjnego, nie widzi go również w SU53 – wtedy kombinacja narzędzi STAUTHTRACE + SACM znacznie ułatwia nam analizę problemu.

Narzędzia do analizy błędów + najczęściej wykrywane błędy

SU53

SU53 to narzędzie, którego chyba nikomu nie trzeba przedstawiać. Jest to absolutna klasyka analizy problemów z autoryzacjami zarówno dla systemów ABAP jak i FIORI 😊

W kontekście działania aplikacji FIORI najczęściej spotykanym problemem jest brak uprawnień użytkownika do odpowiednich serwisów (np. ODATA) zdefiniowanych w obiekcie autoryzacyjnym S_SERVICE. Będzie to powodowało problemy z otwieraniem się aplikacji lub nawet brak dostępu do części danych czy dostępnych opcji.

Poniżej przykład takich logów w transakcji SU53:

By go naprawić, należy poszukać roli zawierającej już obiekt z tą wartością np. poprzez transakcję SUIM lub dodać tę wartość do obiektu S_SERVICE w istniejącej już roli, korzystając z transakcji PFCG:

Wadą SU53 jest brak logów do wszystkich rodzajów błędów autoryzacyjnych, np. nie otrzymamy w niej logów do błędów związanych z autoryzacjami widoków CDS, które zostały zdefiniowane na poziomie kodu widoku CDS.

Tip! Gdy tylko dowiemy się, że wystąpił jakiś problem z aplikacją FIORI i sprawdzimy logi w SU53, warto jest od razu je zapisać, ponieważ są one widoczne tylko przez jakiś czas. Unikniemy w ten sposób sytuacji, w której będziemy musieli prosić użytkownika o ponowne „wygenerowanie” błędu 😊 Ewentualnie możemy poprosić użytkownika o pobranie i przesłanie nam logów.

App Support

W uproszczeniu odpowiednik SU53 lecz dostępny bezpośrednio z poziomu SAP FIORI Launchpad. Aplikacja ta nie jest jednak domyślnie dostępna – trzeba ją aktywować oraz katalog FIORI dodać do wybranych przez nas ról w SAP. Aplikacja prezentuje się jak poniżej:

Dokumentacja SAP w jaki sposób aktywować aplikację dla użytkowników: Setting Up App Support.

STAUTHTRACE

Stauthtrace umożliwia śledzenie, które obiekty autoryzacyjne są sprawdzane podczas wykonywania określonych operacji przez użytkownika. Dzięki temu można zidentyfikować, jakie autoryzacje są wymagane, a które są przyczyną problemów. Możemy wybrać zakres użytkowników, dla których chcemy włączyć trace oraz specyficzne operacje, jakie chcemy śledzić:

Narzędzie wskaże nam również błędy związane z uprawnieniami do widoków CDS.

/n/IWFND/ERROR_LOG

Narzędzie diagnostyczne, które pozwala weryfikować logi błędów podczas przetwarzania requestów serwisów oData – błędy na poziomie komunikacji między SAP Gateway a systemem backendowym, również związane z przetwarzaniem danych:

/n/IWBEP/ERROR_LOG

Podobnie, jak poprzednia aplikacja, /n/IWBEP/ERROR_LOG umożliwia weryfikację logów błędów podczas przetwarzania żądań oData. Jednak w tym przypadku już po stronie Backendu. Pozwala również na analizę błędów związanych z obiektem autoryzacyjnym RFC – S_RFCACL, o którym wspominałem wcześniej:

ST22

Transakcja służącą do analizy błędów ABAP. Umieszczam ją tutaj, ponieważ często coś, co na pierwszy rzut oka wygląda na błąd autoryzacyjny, wcale nie musi nim być 😊 Przykładowo – użytkownik otrzymuje komunikat o jakimś błędzie, jednak jego treść nie jest jednoznaczna, ale sugeruje brak jakiegoś dostępu. Okazuje się jednak, że nie mamy żadnych logów błędów, np. w transakcji SU53, wtedy warto zweryfikować logi w transakcji ST22, by upewnić się, czy nie jest to błąd ABAB/Developerski:

Narzędzia/Tryb Developera w przeglądarce internetowej (Chrome, Firefox, Edge, Opera itp.)

Wiele rzeczy w SAP FIORI dzieje się na poziomie przeglądarki, więc za pomocą wbudowanych narzędzi developerskich i ich konsol jesteśmy w stanie namierzyć miejsce potencjalnego problemu – zweryfikować, jakie żądanie było wywoływane, przez jaki serwis/usługę, jaki błąd to powoduje. Poniżej zrzut ekranu z przykładowego błędu oraz informacje, jakie jesteśmy w stanie odczytać z narzędzia developerskiego:

Dodatkowe przydatne narzędzia

• /UI5/APP_INDEX_CALCULATE – transakcja służy do generowania lub odtwarzania indeksu aplikacji SAPUI5, co jest kluczowe po wdrożeniu nowych aplikacji Fiori, aktualizacjach systemu, czy zmianach w konfiguracji aplikacji. Użycie tej transakcji jest często zalecane w przypadku problemów z wyświetlaniem aplikacji Fiori, takich jak brakujące aplikacje lub problemy z dostępnością – szczególnie, gdy dokonaliśmy w nich jakichś zmian.
• /n/IWFND/CACHE_CLEANUP – w przypadku problemów z usługami oData lub aplikacjami Fiori, takich jak nieprawidłowe działanie aplikacji, brakujące lub nieaktualne dane, użycie tej transakcji może pomóc w przywróceniu poprawnego działania przez wyczyszczenie cache, co zmusi system do ponownego załadowania aktualnych danych z backendu.
• SM20 (Security Audit Log) – służy do przeglądania logów użytkownika np. użytych przez niego transakcji.
• SLG1 – służy do przeglądania logów systemowych wywołanych przez użytkownika np. w konkretnej transakcji lub programie.
• Http Trace tools – różne narzędzia służące do monitorowania żądań Http czy oData w kontekście aplikacji SAP FIORI – można przejrzeć szczegółowe informacje o każdym żądaniu, takie jak metoda (GET, POST, PUT, DELETE), nagłówki, body, status odpowiedzi, czas odpowiedzi i inne.

Inne błędy

• Niepoprawnie nadany alias systemu lub jego brak na poziomie tworzenia/konfiguracji nowej aplikacji FIORI, a dokładniej serwisów, które ją obsługują. Skutkuje to brakiem widoczności aplikacji w środowisku FIORI, po więcej informacji i przykładów odsyłam tutaj: SAP Community – No System Alias found for Service ” and user ” oraz SAP Note 3245402 – OData Service throws error: System alias ’ ’ does not exist
• Użytkownik sam ukrywa aplikacje – jeżeli włączono dla użytkowników możliwość personalizacji grup w systemie FIORI, użytkownicy często sami, eksperymentując z system lub przypadkiem, wyłączają widoczność kafelków z aplikacjami FIORI. Jest to możliwe za pomocą opcji Edit Home Page, klikając na swój awatar w SAP FIORI:

Podsumowanie

Mimo iż z pozoru wydaje się, że zapanowanie nad dostępem i widocznością aplikacji oraz danymi w środowisku SAP FIOR jest trudne, to znając odpowiednie narzędzia oraz najczęstsze problemy, możemy sobie to znacznie ułatwić.

Warto przygotować sobie tzw. tasklistę z ewentualnymi problemami, sposobami/instrukcjami na ich rozwiązanie i punkt po punkcie stosować w sytuacjach, w których na pierwszy rzut okna nie jesteśmy w stanie rozpoznać przyczyny. Po pewnym czasie wchodzi to „w krew” i jesteśmy w stanie namierzyć i rozwiązać przyczynę w ciągle dosłownie kilku minut. Oczywiście w obecnych czasach warto również korzystać z narzędzi zasilanych sztuczną inteligencją, które są w stanie nam wiele podpowiedzieć, a nawet przygotować gotowe rozwiązanie krok po kroku.

Mam nadzieję że, artykuł okaże się pomocny i wesprze w szybkim rozwiązywaniu najpowszechniejszych problemów, a co za tym idzie – do zachęcenia użytkowników końcowych, aby korzystać z aplikacji FIORI zamiast GUI 😊

***

Jeśli interesuje Cię tematyka SAP, zajrzyj również do innych artykułów naszych specjalistów.