Implementacje SAP S/4HANA opierają się w dużej mierze na stronie startowej Fiori jako centralnym interfejsie użytkownika, zastępując tradycyjne transakcje SAP GUI aplikacjami SAPUI5. Aplikacje te pobierają dane za pośrednictwem usług OData, które często owijają funkcje funkcjonalne RFC (Remote Function Call). Architektura wdrożeniowa obejmuje wiele warstw: aplikację frontendową BSP (Business Server Pages), warstwę SAP Gateway (ekspozycję OData), backend stack ABAP oraz profile autoryzacji PFCG (Profile Generator).
Podczas promowania krajobrazu (Development → Quality Assurance → Production) niezgodności często wynikają nie z wad kodu, ale z dryfu konfiguracji. Usługi OData agresywnie buforują metadane w komponencie IWBEP, podczas gdy role PFCG wymagają ręcznej regeneracji (Profile → Generate), aby propagować nowe Obiekty Autoryzacji takie jak S_START lub niestandardowe obiekty Z*. To pytanie sprawdza umiejętność testera nawigacji w n-warstwowej architekturze oraz systematycznego izolowania, czy brak kafelka wynika z pamięci podręcznej frontendowej, metadanych bramy, sekwencjonowania transportu czy opóźnienia w buforze autoryzacji.
Głównym wyzwaniem jest ambiwalencja objawów: użytkownik loguje się do strony startowej Fiori i widzi albo szary kafelek, albo kafelek jest całkowicie nieobecny, albo kliknięcie w niego zwraca komunikat: "Nie można otworzyć aplikacji. Proszę spróbować ponownie później." Te objawy mogą wynikać z:
Zestarzałe metadane OData: Aplikacja SAPUI5 pobiera $metadata, aby zrozumieć struktury encji. Jeśli pamięć podręczna Gateway (/IWFND/CACHE) przechowuje starą wersję po transporcie, aplikacja może nie mieć możliwości powiązania z polami RFC, które zmieniły się w backendzie.
Opóźnienie propagacji roli PFCG: Nawet jeśli Transport Request pomyślnie przeniósł Rolę do QAS, tabele User Master (USR04) mogą nie odzwierciedlać nowych wersji Profile aż do momentu, gdy porównanie jest realizowane (PFUD) lub użytkownik loguje się ponownie. Rola może wymieniać Katalog, ale brakować jej może konkretnych uprawnień S_IWSG (Internet Communication Framework) dla usługi OData.
Orphaned Target Mapping: Wpis LPD_CUST (Launchpad Customizing) lub przypisanie CATALOG może odnosić się do Obiektu Semantycznego (np. ZPurchaseOrder) i Akcji (create), ale jeśli transport pominął przypisanie Grupy lub identyfikator komponentu SAPUI5 w manifest.json nie pasuje do nazwy aplikacji BSP, kafelek renderuje, ale nie prowadzi donikąd.
Bez systematycznego podejścia, testerzy marnują godziny na sprawdzanie kodu SE80, podczas gdy problemem jest brakujący System Alias w SM59 lub niezaplanowany bufor autoryzacji SU56.
Wymagana jest protokół eliminacji warstw, działający od statycznej konfiguracji do dynamicznego czasu działania:
Krok 1: Audyt spójności transportu
Przed jakimkolwiek testowaniem funkcjonalnym, zweryfikuj zawartość Transport of Copies (TOC) lub Workbench Request za pomocą SE01 i SE09. Potwierdź współzależność: aplikacja BSP, węzeł ICF (transakcja SICF), usługa OData (/IWFND/MAINT_SERVICE), przypisania Katalogu/Grupy Fiori (/UI2/FLPD_CUST) oraz rola PFCG muszą być albo w tym samym transporcie, albo mieć udokumentowaną sekwencję. Użyj SCMP (View/Table Comparison), aby różnić tabele LPD_T (Launchpad Data) między systemami.
Krok 2: Unieważnienie pamięci podręcznej metadanych
Wykonaj /IWFND/CACHE_CLEANUP w systemie Gateway, aby wyczyścić pamięci podręczne Modelu i Metadanych. W przeglądarce wymuś twarde przeładowanie (Ctrl+F5) i dodaj ?sap-ui-xx-noCache=true do URL bootstrapa SAPUI5. Sprawdź zakładkę Sieć dla żądania $metadata; upewnij się, że odpowiedź XML zawiera poprawne EntitySets odpowiadające bieżącemu podpisowi RFC.
Krok 3: Opróżnianie bufora autoryzacji
Użyj transakcji SU56, aby usunąć bieżący bufor autoryzacji użytkownika. Wykonaj PFUD (User Master Data Adjustment) z opcją „Porównaj”, aby upewnić się, że Profile roli PFCG jest aktualne. Uruchom SU53 natychmiast po nieudanym dostępie do kafelka, aby wyświetlić ostatni nieudany test autoryzacji. Skoncentruj się na obiektach S_START (ogólna autoryzacja startowa), S_IWSG oraz S_SERVICE.
Krok 4: Weryfikacja rozwiązania mapowania docelowego
Użyj transakcji /UI2/FLIA (Fiori Launchpad Intent Analysis), aby wprowadzić Obiekt Semantyczny i Akcję. To ujawnia, która aplikacja SAPUI5 (poprzez Component ID) jest rozwiązywana, ścieżka ICF i czy wpis LPD_CST jest ważny. Jeśli FLIA wyświetla mapowanie, ale użytkownik go nie widzi, problem leży w PFCG (brak przypisania katalogu). Jeśli FLIA nie pokazuje mapowania, problem leży w LPD_CUST lub transporcie.
Krok 5: Śledzenie łączności RFC
Aktywuj dzienniki błędów Gateway poprzez /IWFND/ERROR_LOG. Śledź docelowe połączenie RFC za pomocą SM59 → Test połączenia, następnie SM50 (Przegląd procesów), aby obserwować błędy RFC, gdy usługa OData próbuje dotrzeć do backendu. Sprawdź, czy występują błędy autoryzacji S_RFC lub S_RFCACL w SM21 (Dziennik systemowy).
Opis problemu
Podczas projektu aktualizacji S/4HANA 2022 aplikacja SAP Fiori „Zarządzaj zamówieniami zakupu” działała doskonale w Development, ale nie udało się jej uruchomić w Quality Assurance z błędem: „Aplikacja nie mogła zostać otwarta, ponieważ komponent SAPUI5 ui.sscim.prereq nie mógł zostać załadowany.” Zespół Basis potwierdził, że wszystkie transporty zostały pomyślnie zaimportowane z kodem zwrotu RC=0 (kod zwrotu zero). **Repozytorium SAPUI5 ABAP (SE80) pokazało, że aplikacja ui.sscim.prereq w wersji BSP była obecna w QAS. Usługa OData C_PURCHASEREQ_SRV była aktywna w /IWFND/MAINT_SERVICE. Jednak kafelek pojawiał się dla administratorów, ale nie dla pracowników działu zaopatrzenia, sugerując problem z autoryzacją, ale administratorzy również otrzymali błąd ładowania po kliknięciu kafelka.
Rozwiązanie 1: Wyczyść pamięć podręczną przeglądarki i wycofaj wersję UI5
Początkową hipotezą było to, że QAS miało uszkodzoną pamięć podręczną SAPUI5 lub niezgodność wersji w repozytorium ABAP. Zespół wyczyścił pamięci podręczne przeglądarek dla wszystkich użytkowników i ręcznie unieważnił pamięć podręczną repozytorium MIME przy użyciu /UI5/APP_INDEX_CALCULATE.
Zalety: To szybkie, nieinwazyjne rozwiązanie, które często rozwiązuje problemy z ładowaniem zasobów SAPUI5 (404 na Component-preload.js). Nie wymaga żadnych zmian kodu ABAP.
Wady: Nie rozwiązało to problemu. Błąd nadal występował, co ważniejsze, nie wyjaśniło, dlaczego kafelek był niewidoczny dla pracowników. Rozwiązywało to objaw (błąd ładowania), nie diagnozując, dlaczego metadane nie były w stanie załadować, potencjalnie maskując głębszy problem z konfiguracją usługi OData.
Rozwiązanie 2: Pełna regeneracja roli PFCG i porównanie użytkowników
Zespół podejrzewał, że przypisanie Katalogu w PFCG było brakujące. Odnowili wszystkie profile dla ról działu zaopatrzenia i uruchomili PFUD z opcją „Pełna rekonsyliacja”, aby upewnić się, że wszyscy użytkownicy otrzymali zaktualizowane uprawnienia.
Zalety: Zapewnia synchronizację Profilów Autoryzacyjnych (PROF_NAME w UST04) z definicjami Roli. To naprawiło problem „niewidocznego kafelka” dla pracowników, ponieważ przypisanie grupy Katalogu faktycznie było brakujące w wersji QAS roli.
Wady: Choć kafelek stał się widoczny, kliknięcie w niego nadal powodowało błąd „nie można załadować komponentu”. To podejście zawiodło, ponieważ koncentrowało się wyłącznie na warstwie autoryzacji (PFCG) i ignorowało warstwę mapowania OData do RFC. Administratorzy, którzy mogli zobaczyć kafelek, wciąż nie mogli go otworzyć, co udowodniło, że problem wykraczał poza autoryzację.
Rozwiązanie 3: Systematyczna weryfikacja stanu Gateway i węzła ICF (wybrane podejście)
Wybrane podejście obejmowało sprawdzenie stanu aktywacji usługi OData niezależnie od aplikacji UI5. Używając transakcji /IWFND/GW_CLIENT, zespół wykonał żądanie GET do C_PURCHASEREQ_SRV?sap-client=100. Żądanie zwróciło HTTP 200, ale ładunek XML pokazał, że Metadane pochodziły z wersji pamięci podręcznej sprzed niedawnej zmiany interfejsu RFC. Następnie sprawdzenie transakcji SICF (Zarządzaj usługami) ujawniło, że węzeł ICF /sap/bc/ui5_ui5/sap/ui_sscim_prereq był aktywny w DEV, ale nieaktywny w QAS (import zakończył się cicho z powodu zablokowanego obiektu). W końcu sprawdzając /IWFND/ERROR_LOG pokazało, że gdy aplikacja próbowała pobrać $metadata, natrafiła na błąd autoryzacji dotyczącą mapowania System Alias, które wskazywało na przestarzałe docelowe połączenie SM59, które zostało wycofane po migracji.
Dlaczego wybrano: To podejście zidentyfikowało trzy równoczesne awarie: (1) Desynchronizacja pamięci podręcznej OData między DEV a QAS, prowadząca do błędów metadanych, (2) nieaktywność węzła ICF, uniemożliwiająca serwowanie zasobów SAPUI5 przez HTTP, oraz (3) błędna konfiguracja System Alias w QAS, wskazująca na nieistniejące połączenie RFC. Zapewniło określone kody błędów (ICF 403 w przeciwieństwie do OData 404), a nie ogólne komunikaty skierowane do użytkowników.
Wynik
Wykonanie /IWFND/CACHE_CLEANUP odświeżyło metadane OData, aby odpowiadały nowemu podpisowi RFC. Aktywacja węzła ICF za pośrednictwem SICF rozwiązała błąd „nie można załadować komponentu” poprzez udostępnienie plików HTML i JS aplikacji BSP. Poprawa System Alias w /IWFND/MAINT_SERVICE → Aliasy systemów SAP zapewniła, że Gateway mógł dotrzeć do backendu. Pracownicy działu zaopatrzenia mogli teraz zobaczyć i otworzyć aplikację, ponieważ rola PFCG (poprawiona w Rozwiązaniu 2) przyznała dostęp do działającego kafelka. Systematyczne podejście zaoszczędziło około 8 godzin debugowania ABAP, które zostałyby stracone na założeniu, że kod był wadliwy.
Jak definitywnie określić, czy brakujący kafelek Fiori jest spowodowany brakującym mapowaniem docelowym (LPD_CUST) czy brakującym przypisaniem katalogu w PFCG, biorąc pod uwagę, że oba skutkują tym, że kafelek nie jest wyświetlany?
Odpowiedź:
Brakujące Mapowanie Docelowe (skonfigurowane w LPD_CUST lub w KATALOG Fiori) oznacza, że połączenie Obiektu Semantycznego i Akcji nie ma powiązanej aplikacji SAPUI5, ale kafelek sam w sobie wciąż może się pojawić, jeśli przypisanie Katalogu istnieje w PFCG. Kliknięcie w niego prowadziłoby do błędu „Nie znaleziono celu nawigacji”. Aby zweryfikować, użyj transakcji /UI2/FLIA (Fiori Launchpad Intent Analysis). Wprowadź Obiekt Semantyczny i Akcję; jeśli FLIA zwraca „Nie znaleziono aplikacji dla tego zamiaru”, to brakujące jest Mapowanie Docelowe lub nazwa aplikacji BSP w mapowaniu jest niepoprawna.
Z drugiej strony, jeśli FLIA pomyślnie pokazuje docelową aplikację SAPUI5 i Component ID, ale kafelek jest nieobecny na stronie startowej użytkownika, problem jest związany z PFCG. Sprawdź, czy Katalog zawierający kafelek jest przypisany do roli użytkownika w PFCG (sprawdź kartę Menu), a także upewnij się, że Grupa (która organizuje kafelki na stronie startowej) jest również przypisana. Dodatkowo potwierdź, że obiekt autoryzacji S_START z wartością WEBGUI jest obecny w śladzie SU53 użytkownika, ponieważ jest to wymagane do uruchomienia jakiejkolwiek aplikacji Fiori, a często jest pomijane w aktualizacjach ról z systemów wyłącznie SAP GUI.
Dlaczego test usługi OData może zakończyć się sukcesem za pomocą klienta Gateway (/IWFND/GW_CLIENT), ale nie uda się z błędem 403 Forbidden, gdy jest wywoływany przez aplikację SAPUI5 w przeglądarce?
Odpowiedź:
Gateway Client (/IWFND/GW_CLIENT) wykonuje się w kontekście sesji SAP GUI, używając autoryzacji SAP Logon i pomijając sprawdzanie zabezpieczeń węzła HTTP Internet Communication Framework (ICF). Aplikacja SAPUI5 jednak kieruje żądania przez strukturę węzła ICF (/sap/bc/ui5_ui5/... lub /sap/opu/odata/...).
Dlatego błąd 403 w przeglądarce zazwyczaj oznacza:
Nieaktywność węzła ICF: Konkretny węzeł usługi w SICF jest nieaktywny w docelowym kliencie, mimo że usługa OData sama jest zarejestrowana w /IWFND/MAINT_SERVICE.
Autoryzacja S_ICF: Użytkownik nie ma obiektu autoryzacji S_ICF z odpowiednimi Wartościami Pola ICF (Nazwa usługi, Gospodarz itp.), aby uzyskać dostęp do tej konkretnej ścieżki HTTP. Sprawdź transakcję SU53 natychmiast po błędzie.
Weryfikacja Tokena CSRF: Aplikacje SAPUI5 wymagają ważnego tokena CSRF (Cross-Site Request Forgery) pobranego poprzez żądanie HEAD. Jeśli systemy frontendowe i backendowe są źle skonfigurowane (np. różne ID systemu w scenariuszu Fiori Front-end Server), walidacja tokena kończy się niepowodzeniem z błędem 403, podczas gdy GW_CLIENT (bezstanowy i niezwiązany z CSRF) kończy z powodzeniem.
Jak testować warunki wyścigu w aktualizacjach ról PFCG, gdy wiele żądań transportu zawierających zmiany profilu autoryzacji jest importowanych jednocześnie podczas wąskiego okna wydania?
Odpowiedź:
Gdy wiele Transport Requests zawierających Roli PFCG jest równocześnie importowanych, generacja Profilu (PFCG → Generate Profile) może tworzyć kolizje blokady tabeli w USR10 lub USR12, prowadząc do niekompletnych buforów autoryzacji, w których niektórzy użytkownicy otrzymują częściowe aktualizacje ról. Aby to przetestować:
Symulacja importu stopniowego: W systemie QAS zaimportuj Role transportowe sekwencyjnie, a nie równocześnie. Udokumentuj kody zwrotu (docelowe RC=0 lub RC=4 ostrzeżenia). Następnie zresetuj system i zaimportuj je równocześnie. Porównaj rekordy User Master (tabela UST04) między dwoma scenariuszami za pomocą SE16 lub zapytania AGR_USERS, aby sprawdzić, czy przypisania ról się różnią.
Porównanie Śladu Autoryzacji: Użyj ST01 (Ślad autoryzacji) dla tego samego użytkownika przed i po równoczesnym imporcie. Zbierz bufory Sprawdzenia Autoryzacji. Jeśli sekwencyjny import wykazuje pomyślne kontrole dla Z_CUSTOM_AUTH_OBJECT, ale równoczesny import wykazuje błędy, to prawdopodobnie wystąpiła kolizja wyścigu w generacji Profilu.
Testowanie opóźnienia PFUD: Natychmiast po równoczesnym imporcie uruchom SUIM → Użytkownik → Według złożonych kryteriów wyboru i sprawdź, czy wersje Profilu (PROFN w USR10) odpowiadają wersji Roli w PFCG. Jeśli są różne, dostosowanie User Master (PFUD) zostało pominięte lub zakończone cicho. Rozwiązaniem jest wymuszenie obowiązkowego uruchomienia PFUD z weryfikacją RSUSR200 (Analiza przypisań użytkownika do ról) przed sign-off.