Реализации SAP S/4HANA сильно полагаются на Fiori Launchpad как центральный пользовательский интерфейс, заменяя традиционные транзакции SAP GUI приложениями SAPUI5. Эти приложения потребляют данные через OData сервисы, которые часто оборачивают унаследованные модули функции RFC (Remote Function Call). Архитектура развертывания включает несколько слоев: фронтенд приложение BSP (Business Server Pages), уровень SAP Gateway (экспонирующий OData), бэкенд стек ABAP и профили авторизации PFCG (Profile Generator).
Во время продвижения по ландшафту (Разработка → Контроль качества → Производство) несоответствия часто возникают не из-за дефектов кода, а из-за разнородности конфигураций. OData сервисы агрессивно кэшируют метаданные в компоненте IWBEP, в то время как роли PFCG требуют ручной регенерации (Профиль → Сгенерировать), чтобы распространить новые Объекты Авторизации такие как S_START или пользовательские Z* объекты. Этот вопрос тестирует способность тестировщика ориентироваться в n-уровневой архитектуре и систематически изолировать, является ли отсутствующая плитка следствием кэша фронтенда, метаданных шлюза, последовательности транспортировок или задержки буфера авторизации.
Основная проблема заключается в неоднозначности симптомов: пользователь входит в Fiori launchpad и либо видит серую плитку, либо плитка полностью отсутствует, либо при нажатии на нее появляется сообщение "Не удалось открыть приложение. Пожалуйста, попробуйте еще раз позже." Эти симптомы могут вызывать:
Устаревшие метаданные OData: Приложение SAPUI5 запрашивает $metadata, чтобы понять структуры сущностей. Если кэш Gateway (/IWFND/CACHE) содержит старую версию после транспортировки, приложение может не привязаться к полям RFC, которые изменились на бэкенде.
Задержка распространения роли PFCG: Даже если Транспортный Запрос успешно переместил Роль в QAS, таблицы Пользователь (USR04) могут не отражать новые версии Профиля до выполнения сравнения (PFUD) или повторного входа пользователя. Роль может перечислять Каталог, но не иметь конкретной авторизации S_IWSG (Internet Communication Framework) для сервиса OData.
Сироты целевого отображения: Запись LPD_CUST (Настройка Launchpad) или назначение CATALOG могут ссылаться на Семантический Объект (например, ZPurchaseOrder) и Действие (create), но если транспорт пропустил назначение Группы или идентификатор компонента SAPUI5 в manifest.json не соответствует имени приложения BSP, плитка рендерится, но никуда не ведет.
Без систематического подхода тестировщики тратят часы на проверку кода в SE80, когда проблема заключается в отсутствии System Alias в SM59 или ненадежном буфере авторизации SU56.
Необходима протокол поэтапного исключения, работающий от статической конфигурации к динамическому времени выполнения:
Шаг 1: Аудит Последовательности Транспорта
Перед любым функциональным тестированием, проверьте содержимое Transport of Copies (TOC) или Workbench Request с использованием SE01 и SE09. Подтвердите со-зависимость: BSP приложение, ICF узел (транзакция SICF), OData сервис (/IWFND/MAINT_SERVICE), назначения Fiori Catalog/Group (/UI2/FLPD_CUST) и роль PFCG должны быть либо в одном и том же транспорте, либо иметь задокументированную последовательность. Используйте SCMP (Сравнение представлений/таблиц) для сопоставления таблиц LPD_T (Данные Launchpad) между системами.
Шаг 2: Инвалидация Кэша Метаданных
Выполните /IWFND/CACHE_CLEANUP в системе Gateway, чтобы очистить кэши Model и Metadata. В браузере принудительно выполните жесткую перезагрузку (Ctrl+F5) и добавьте ?sap-ui-xx-noCache=true к URL загрузки SAPUI5. Проверьте вкладку Сеть для запроса на $metadata; убедитесь, что XML ответ содержит правильные EntitySets, соответствующие текущей сигнатуре RFC.
Шаг 3: Очистка Буфера Авторизации
Используйте транзакцию SU56, чтобы удалить текущий буфер авторизации пользователя. Выполните PFUD (Корректировка данных пользователей) с опцией "Сравнить", чтобы гарантировать, что профиль роли PFCG актуален. Запустите SU53 сразу после неудачной попытки доступа к плитке, чтобы отобразить последнюю неудачную проверку авторизации. Обратите внимание на наличие объектов S_START (общая авторизация начала), S_IWSG и S_SERVICE.
Шаг 4: Проверка Разрешения Сопоставления
Используйте транзакцию /UI2/FLIA (Анализ интента Launchpad Fiori), чтобы ввести Семантический Объект и Действие. Это покажет, какое приложение SAPUI5 (через Component ID) разрешено, путь ICF, и является ли запись LPD_CST действительной. Если FLIA показывает сопоставление, но пользователь не может его увидеть, проблема связана с PFCG (отсутствующее назначение каталога). Если FLIA не показывает сопоставление, проблема заключается в LPD_CUST или в транспорте.
Шаг 5: Отслеживание Подключения RFC
Активируйте журналы ошибок Gateway через /IWFND/ERROR_LOG. Отследите назначение RFC с использованием SM59 → Тест соединения, затем SM50 (Обзор процессов), чтобы наблюдать за сбоями RFC, когда сервис OData пытается достичь бэкенда. Проверьте наличие сбоев авторизации S_RFC или S_RFCACL в SM21 (Журнал системы).
Описание проблемы
Во время проекта обновления S/4HANA 2022 приложение SAP Fiori "Управление запросами на покупку" работало идеально в Разработке, но не запускалось в Контроле качества с ошибкой: "Приложение не может быть открыто, потому что компонент SAPUI5 ui.sscim.prereq не может быть загружен." Команда Basis подтвердила, что все транспортные запросы были успешно импортированы с RC=0 (код возврата ноль). В ABAP репозитории SAPUI5 (SE80) было видно, что BSP приложение ui.sscim.prereq присутствует в QAS. Сервис OData C_PURCHASEREQ_SRV был активен в /IWFND/MAINT_SERVICE. Однако плитка отображалась для администраторов, но не для клерков по закупкам, что предполагает проблему с авторизацией, однако администраторы также получали ошибку загрузки при нажатии на плитку.
Решение 1: Очистка кэша браузера и откат версии UI5
Первоначальная гипотеза заключалась в том, что у QAS был поврежденный кэш SAPUI5 или несоответствие версий в ABAP репозитории. Команда очистила кэши браузера для всех пользователей и вручную аннулировала кэш репозитория MIME с помощью /UI5/APP_INDEX_CALCULATE.
Плюсы: Это быстрое, неинвазивное решение часто устраняет проблемы с загрузкой ресурсов SAPUI5 (404 на Component-preload.js). Оно не требует изменений в коде ABAP.
Минусы: Это не решило проблему. Ошибка сохранилась, и что более критично, она не объяснила, почему плитка была невидимой для клерков. Она устранила симптом (ошибку загрузки), не диагностируя, почему метаданные не загружались, потенциально скрывая более глубокую проблему конфигурации сервиса OData.
Решение 2: Полная регенерация роли PFCG и сравнение пользователей
Команда заподозрила, что назначение Каталога Fiori в PFCG отсутствует. Они регенерировали все профили для ролей закупок и запустили PFUD с опцией "Полная сверка", чтобы гарантировать, что все пользователи получили обновленные авторизации.
Плюсы: Гарантирует, что Авторизационные Профили (PROF_NAME в UST04) синхронизированы с определениями Ролей. Это решило проблему "невидимой плитки" для клерков, так как назначение Каталога действительно отсутствовало в версии роли QAS.
Минусы: Несмотря на то, что плитка стала видимой, нажатие на нее все еще приводило к ошибке "компонент не может быть загружен". Этот подход провалился, потому что сосредоточился исключительно на уровне авторизации (PFCG) и игнорировал уровень сопоставления сервиса OData с RFC. Администраторы, которые могли видеть плитку, все же не могли ее открыть, что доказывало, что проблема превышает авторизацию.
Решение 3: Систематическая проверка шлюза и узла ICF (выбранный подход)
Выбранная методология включала проверку состояния активации сервиса OData независимо от приложения UI5. С использованием транзакции /IWFND/GW_CLIENT команда выполнила запрос GET к C_PURCHASEREQ_SRV?sap-client=100. Запрос вернул HTTP 200, но полезная нагрузка XML показала, что Метаданные были из кэшированной версии до недавнего изменения интерфейса RFC. Затем проверка транзакции SICF (Поддержка сервисов) показала, что узел ICF /sap/bc/ui5_ui5/sap/ui_sscim_prereq был активен в DEV, но неактивен в QAS (импорт молчаливо провалился из-за заблокированного объекта). Наконец, проверка /IWFND/ERROR_LOG показала, что когда приложение пыталось получить $metadata, оно столкнулось с ошибкой авторизации на сопоставлении System Alias, которое указывало на устаревшую назначение SM59, которое было выведено из эксплуатации после миграции.
Почему выбрано: Этот подход изолировал три одновременные ошибки: (1) десинхронизация кэша OData между DEV и QAS, вызывающая несоответствие метаданных, (2) неактивность узла ICF, предотвращающая обслуживание ресурсов SAPUI5 через HTTP, и (3) ошибка конфигурации System Alias в QAS, указывающая на несуществующее назначение RFC. Это обеспечивало конкретные коды ошибок (ICF 403 против OData 404), а не общие сообщения для пользователей.
Результат
Выполнение /IWFND/CACHE_CLEANUP обновило метаданные OData для соответствия новой сигнатуре RFC. Активация узла ICF через SICF разрешила ошибку "компонент не может быть загружен", сделав HTML и JS файлы BSP приложения доступными. Коррекция System Alias в /IWFND/MAINT_SERVICE → SAP System Aliases гарантировала, что Gateway сможет достичь бэкенда. Клерки по закупкам смогли увидеть и открыть приложение, поскольку роль PFCG (исправленная в Решении 2) предоставила доступ к теперь функциональной плитке. Систематический подход сэкономил приблизительно 8 часов отладок ABAP, которые были бы потрачены впустую из-за предположения, что код был дефективным.
Как вы определите, вызвано ли отсутствие плитки Fiori отсутствием сопоставления цели (LPD_CUST) или отсутствием назначения каталога в PFCG, учитывая, что оба случая приводят к отсутствию плитки?
Ответ:
Отсутствие Sopоставления цели (настроенного в LPD_CUST или дизайнере Fiori CATALOG) означает, что комбинация Семантического Объекта и Действия не имеет связанного приложения SAPUI5, но сама плитка может все еще появляться, если назначение Каталога существует в PFCG. Нажатие на нее вызовет ошибку "Цель навигации не найдена". Для проверки используйте транзакцию /UI2/FLIA (Анализ интентов Launchpad Fiori). Введите Семантический Объект и Действие; если FLIA возвращает "Нет найденного приложения для этого интента", то Sopоставление цели отсутствует или имя приложения BSP в сопоставлении неверно.
С другой стороны, если FLIA успешно отображает целевое приложение SAPUI5 и Component ID, но плитка отсутствует на стартовом экране пользователя, проблема связана с PFCG. Проверьте, назначен ли Каталог, содержащий плитку, роли пользователя в PFCG (проверьте вкладку Меню), и убедитесь, что Группа (которая организует плитки на главной странице запускного экрана) также назначена. Кроме того, проверьте наличие объекта авторизации S_START со значением WEBGUI в трассировке SU53 пользователя, так как это требуется для запуска любого приложения Fiori, и часто упускается в обновлениях ролей из систем, работающих только с SAP GUI.
Почему тестирование сервиса OData может успешно проходить через Gateway Client (/IWFND/GW_CLIENT), но давать ошибку 403 Forbidden при вызове приложения SAPUI5 в браузере?
Ответ:
Gateway Client (/IWFND/GW_CLIENT) выполняется в контексте сессии SAP GUI, используя аутентификацию SAP Logon и обходя проверки безопасности узла HTTP Internet Communication Framework (ICF). Однако приложение SAPUI5 направляет запросы через структуру узлов ICF (/sap/bc/ui5_ui5/... или /sap/opu/odata/...).
Таким образом, 403 в браузере обычно указывает на:
Неактивность узла ICF: Конкретный узел сервиса в SICF неактивен в целевом клиенте, даже если сервис OData сам по себе зарегистрирован в /IWFND/MAINT_SERVICE.
Авторизация S_ICF: У пользователя отсутствует объект авторизации S_ICF с правильными значениями полей ICF (Имя сервиса, Хост и т.д.), чтобы получить доступ к этому конкретному пути HTTP. Проверьте транзакцию SU53 сразу после сбоя.
Проверка токена CSRF: Приложения SAPUI5 требуют действительный CSRF (Cross-Site Request Forgery) токен, полученный через HEAD запрос. Если фронтенд и бэкенд системы неправильно сконфигурированы (например, разные ID систем в сценарии Fiori Front-end Server), проверка токена не проходит с ошибкой 403, тогда как GW_CLIENT (без состояния и не зависящий от CSRF) успешно выполняется.
Как вы тестируете наличие условий гонки в обновлениях ролей PFCG, когда несколько транспортных запросов, содержащих изменения профиля авторизации, одновременно импортируются в рамках плотного окна релиза?
Ответ:
Когда одновременно импортируются несколько Транспортных Запросов, содержащих роли PFCG, генерация Профиля (PFCG → Сгенерировать Профиль) может создать Конфликты блокировки таблиц в USR10 или USR12, что приводит к неполным буферам авторизации, когда некоторые пользователи получают частичные обновления ролей. Чтобы протестировать это:
Симуляция поэтапного импорта: В системе QAS импортируйте Роль последовательным образом, а не одновременно. Задокументируйте Коды Возврата (целевой RC=0 или RC=4 предупреждения). Затем сбросьте систему и импортируйте их одновременно. Сравните записи Пользовательской Мастери (таблица UST04) между двумя сценариями с использованием SE16 или запросите AGR_USERS, чтобы узнать, есть ли различия в назначениях ролей.
Сравнение трассировок авторизации: Используйте ST01 (Трассировка авторизации) для одного и того же пользователя до и после одновременного импорта. Зафиксируйте Проверки Авторизации буферов. Если последовательный импорт показывает успешные проверки для Z_CUSTOM_AUTH_OBJECT, но одновременный импорт показывает сбои, вероятен конфликт гонки в генерации Профиля.
Тестирование задержки PFUD: Сразу после одновременного импорта выполните SUIM → Пользователь → По сложным критериям выбора и проверьте, совпадают ли версии Профиля (PROFN в USR10) с версией Роли в PFCG. Если они не совпадают, то корректировка данных пользователей (PFUD) была пропущена или завершилась молча. Решение состоит в том, чтобы обеспечить обязательное выполнение PFUD с проверкой RSUSR200 (Анализ назначений пользователя и роли) перед подписанием.