SAP Fiori Front-end-сервер - это самостоятельная система на базе SAP Net Weaver в ABAP-стеке. Задачей SAP Fiori Front-end является отображение интерфейса пользователя. Fiori Front-end может существовать как отдельно, так и в составе бизнес-системы, к примеру, ERP-системы S/4HANA.

Обозначенная в заголовке статьи архитектура раскрыта кратко, только в разрезе, необходимом для понимания того, как работают полномочия в Fiori.

  1. Что такое Front-end и Back-end?

SAP Fiori Front-end-сервер - это самостоятельная система на базе SAP Net Weaver в ABAP-стеке. Задачей SAP Fiori Front-end является отображение интерфейса пользователя. Fiori Front-end может существовать как отдельно, так и в составе бизнес-системы, к примеру, ERP-системы S/4HANA. Сама ERP-система S/4HANA является Back-end-системой по отношению к Fiori Front-end. Как аналогию SAP Fiori Front-end-серверу можно привести обычный web-сервер: выполняемые им функции примерно те же самые. Смысл этого разделения — это возможность отделить интерфейсную часть Front-end от бизнес-логики и данных в Back-end.

Обозначенная в заголовке статьи архитектура раскрыта кратко, только в разрезе, необходимом для понимания того, как работают полномочия в Fiori.

  1. Технические компоненты Fiori Launchpad

SAP Fiori Launchpad - это интерфейс, который вы можете видеть ниже на рисунке 1, голубого цвета с белыми квадратами-плитками приложений.  SAP Fiori Launchpad сам по себе является приложением (пустой, без плиток) и входит в состав компонента Central UI - технического компонента системы SAP_UI. Интерфейс Fiori Launchpad работает по протоколу HTTP(s) и так же, как и все остальные приложения, отображаемые Launchpad-ом, для передачи данных использует протокол OData. Сами данные по протоколу OData обрабатываются OData-сервисами, работу которых в свою очередь обеспечивает SAP Gateway – технический компонент SAP_GWFND.

Рис. 1 Central UI и Gateway

Product UI – это транзакционные и аналитические приложения разных продуктов SAP (отображаются Fiori Launchpad в виде плиток), также расположенные на Fiori Front-end Server. Они не являются частью Central UI и нуждаются в специфичных для каждого продукта UI add-on-ах. Этих add-on-ов множество для самых разных областей бизнеса, и они устанавливаются на Fiori Front-end-сервер. Как видно ниже, в примере на рисунке 2, это несколько компонентов, начинающихся на буквы UI……….

Рис. 2 Product UI

  1. Модель организации интерфейса Fiori для S/4HANA

Основные компоненты модели организации интерфейса Fiori: бизнес-роли, бизнес-группы, бизнес-каталоги, технические каталоги, технические back-end-каталоги, OData-сервисы.

Fiori-бизнес-роль - это обычная роль, создаваемая в транзакции PFCG. Кроме стандартных полномочий на доступ к транзакциям и данным ABAP-системы, она содержит в себе Fiori-каталоги и Fiori-группы. В зависимости от типа ландшафта, например, для типа embedded, Fiori-группы и Fiori-каталоги могут быть в одной и той же PFCG-роли. В случае варианта ландшафта hub в back-end-системе нет необходимости добавлять Fiori-группу в роль пользователя. Ландшафт embedded и hub будут объяснены ниже, в следующей главе. Бизнес-роль содержит полномочия на запуск Fiori-приложений через объект S_SERVICE и полномочия на доступ к данным в Back-end-системе. Соответственно, есть различия в случае hub и embedded, но об этом как-нибудь в другой раз. Именование стандартных, поставляемых SAP бизнес-ролей имеет следующий префикс – SAP_BR_(ROLENAME). См. Рис. 3.

Fiori-бизнес-группа формирует начальный экран рабочего места пользователя, то есть отображает плитки, добавленные в Fiori-группу из одного или нескольких каталогов. Группа, в свою очередь, добавлена в PFCG-бизнес-роль, а роль уже присвоена пользователю. Именование стандартных, поставляемых SAP бизнес-групп имеет следующий префикс – SAP_BCG_(GROUPNAME). См. Рис. 3.

ПРИМЕЧАНИЕ: если в группе содержится приложение из каталога, который не присвоен роли пользователя (забыли, к примеру, присвоить), то плитка этого приложения данному пользователю в Launchpad отображаться не будет.

Fiori-бизнес-каталоги, поставляемые SAP, - созданные SAPом наборы приложений по узкой функциональной направленности, например, часть FI, по платежам относящаяся к отдельному бухгалтерскому бизнес-процессу и объединяющая в себе приложения только для этого бизнес-процесса. Рекомендуется использовать бизнес-каталоги, поставляемые SAP, но не менять их содержимое. В случае, если необходимо изменить стандартный SAP-каталог, то рекомендуется скопировать его в Z-область именования и уже после менять, как заблагорассудится. Другими словами, бизнес-каталоги — это небольшой атомарный набор приложений для отдельного бизнес-процесса или шага бизнес-процесса. Все содержимое бизнес-каталога, то есть плитки, является ссылками на объекты в технических каталогах. Если бизнес-каталог присвоен пользователю через PFCG-роль, то пользователь получает все полномочия на приложения, входящие в данный бизнес-каталог, даже если не все плитки, а только часть плиток данного каталога отображаются пользователю через бизнес-группу. Именование стандартных, поставляемых SAP бизнес-каталогов имеет следующий префикс – SAP_BС_(CATALOGNAME). См. Рис. 3.

Технический каталог – это набор приложений (плиток и target mapping), более широкий чем бизнес-каталог и состоящий из приложений, относящихся к какой-либо функциональной области (к примеру, FI, но не полностью, конечно). Имеется ограничение на количество объектов в техническом каталоге, связанное с производительностью системы (смотреть в технической документации). На объекты в техническом каталоге ссылаются плитки из бизнес-каталогов. Содержимое технических каталогов недоступно для вывода напрямую в виде плиток для пользователя. Вывод для пользователя выполняется только через бизнес-каталоги. Именование стандартных, поставляемых SAP технических каталогов имеет следующий префикс – SAP_TC_(CATALOGNAME). См. Рис. 3.

Технический back-end-каталог – это технический каталог для унаследованных приложений (транзакций и Webdynpro) из предыдущих версий SAP ERP. App Descriptors – так называются ABAP-транзакции для GUI HTML и Webdynpro-приложения, доставшиеся по наследству S/4HANA из предыдущей версии ERP и существующие в виде плиток в Fiori Launchpad, добавленные в технический back-end-каталог. Именование стандартных, поставляемых SAP технических back-end-каталогов имеет следующий префикс – SAP_TC_(CATALOGNAME) См. Рис. 3.

OData-сервисы – это сервисы, через которые приложения Fiori из Front-end взаимодействуют с Back-end, то есть обеспечивают передачу данных. Обычно они активируются во время первоначальной настройки после установки системы (Fiori Rapid Activation). 

Рис. 3 Модель организации интерфейса Fiori

На рисунке 4 изображен пример отображения в Fiori Launchpad двух групп плиток для рабочего места бухгалтера. Первая группа - «Оперативная отчетность по ГК», вторая группа -  «Аналитическая отчетность и контроль БУ-НУ».

Рис. 4 Пример отображения в Fiori Launchpad двух групп плиток

  1. Стандартные роли для работоспособности Fiori Launchpad

Для того, чтобы пользователь мог запустить Fiori Launchpad даже без плиток, то есть пустой, как самостоятельное приложение, обязательно необходимы стандартные роли. Данные роли генерируются при начальных шагах настройки системы, как правило автоматизированным сценарием, который носит название Fiori Rapid Activation. Этот сценарий обычно запускает специалист, инсталлирующий систему. Если при запуске сценария названия ролей принудительно не изменены, то по умолчанию их именование будет примерно таким (зависит от версии системы):

Групповая роль – Z_FIORI_FOUNDATION_USER

В данную групповую роль входят простые роли - Z_UI2_USER_700, Z_UI2_USER_750

  1. Архитектура SAP Fiori в разрезе системного ландшафта SAP

Данный раздел повествует не о полномочиях и не о всем, что с ними связано, а об устройстве системного ландшафта S/4HANA в сочетании с SAP Fiori-частью (она же часто в документации именуется SAP Gateway). Схема системного ландшафта будет влиять на то, как вы будете работать с каталогами Fiori и, соответственно, с полномочиями конечных пользователей, поэтому слегка затронем данную тему. Информацию по рекомендациям от SAP можно найти в интернете, введя в поиске «SAP Fiori Deployment Recommendations». Последняя на момент написания данной статьи версия рекомендаций — это 6 версия за октябрь 2020 года.

Термин On-Premise означает локальное размещение системы на сайте заказчика. При размещении системы SAP S/4HANA On-Premise имеется два варианта размещения. Главная рекомендация от SAP - использовать Embedded (Рис. 5.) для S/4HANA или совмещенный тип размещения, так как это упрощает планирование, развертывание и эксплуатацию. И как дополнительная альтернатива - тип размещения standalone или hub (Рис. 6.). Для развертывания старых систем SAP Business Suite рекомендуемым сценарием остается тип развертывания hub.

Рис. 5. Совместное размещение Fiori Front-End Server (FES) и S/4HANA типа Embedded on-Premise

Рис. 6. Отдельное размещение Fiori Front-End Server (FES) и S/4HANA типа Hub on-Premise

Условно в любой из схем ландшафта, либо Embedded, либо Hub присутствуют понятия Front-end- и Back-end-систем, хотя фактически в варианте Embedded они размещены в одной системе. Front-end, он же Fiori, иногда называют так же, как Gateway - это add-on для сервера приложений SAP на базе SAP Net Weaver.

  1. Где найти информацию о приложениях Fiori

Прежде чем приступать к внедрению системы, консультанты должны изучить функционал приложений, входящих в Fiori. Помимо группы транзакций, которые в S/4HANA вообще заблокированы как устаревшие, хотя некоторые ещё действуют параллельно с новыми приложениями Fiori, существует функционал, который реализован только на Fiori. Лучшим вариантом будет первоначально изучить функционал Fiori на песочнице, то есть тестовой S/4HANA-системе. Конечно, если таковая имеется. Вся текущая информация о приложениях и всех сопутствующих компонентах находится на портале SAP. Искать следующим образом – набрать в поиске google "Fiori library". Первая же строка будет ссылкой на библиотеку приложений Fiori Apps Reference Library (см. Рис 7).

Рис. 7. Поиск Fiori Apps Reference Library в поисковой системе

Так выглядит интерфейс Fiori Library (см. Рис 8). Доступ предоставлен для всех, войти можно и без S-user-а. Можно искать по множеству критериев, по системам и их версиям, по типу бизнеса и так далее. Можно найти по транзакции или по приложению, если оно известно. Всего на момент написания статьи около 12800 доступных приложений, и с каждой версией их количество увеличивается.

В интерфейсе Fiori Apps Reference Library (см. Рис 8) можно вбить в строку поиска один из известных объектов для изучения связанной с ним информации:

1) приложение Fiori – обычно имя приложения Fiori выглядит Fyyy (yyy цифры).

2) Имя ABAP-транзакции для поиска, к примеру, каталога, в который она может входить.

4) OData-сервис для поиска связанных с ним каталогов.

5) Каталог для обратного поиска OData-сервиса.

К примеру, поищем транзакцию fb02 (если транзакция отображается в поиске Fiori Library, это значит, что транзакция имеется в системе и включена в каталог). Если транзакция не найдена, значит, она не включена в каталоги. Она, возможно, существует, не заблокирована как устаревшая, но не включена в каталог. В этом случае надо самостоятельно делать технический каталог или включать в существующий технический каталог. И затем следующим шагом включать в бизнес-каталог.

Рис. 8. Интерфейс Fiori Apps Reference Library

Если Fiori-приложение или транзакция обнаружились в Fiori Library, они обязательно должны принадлежать «техническому каталогу». Чаще всего, но не всегда, они в дополнение к «техническому каталогу» могут принадлежать и к «бизнес-каталогу», и к «бизнес-группе». На рисунке 9 ABAP-транзакция FB02 входит в «технический каталог» SAP_TC_FIN_FO_COMMON. Но ни «бизнес-каталога», ни «бизнес-группы» для данной транзакции не существует. При необходимости «бизнес-каталог» и «бизнес-группу» можно создать самостоятельно.

Рис. 9. Транзакция FB02 входит в «технический каталог» SAP_TC_FIN_FO_COMMON

Транзакция FINTAP, также взятая для примера, входит в «технический каталог» SAP_TC_FIN_FO_BE_APPS и в «бизнес-каталог» SAP_SFIN_BC_AP_DOC_PROC. Также имеется стандартная SAP-бизнес-группа SAP_SFIN_BCG_SUPP_ACC и «бизнес-роль» SAP_BR_AP_ACCOUNTANT. Смотреть Рис. 10, 11. В данном случае, можно сразу присвоить пользователю существующую «бизнес-роль», и он сможет приступить к работе.

Рис. 10. Транзакция FINTAP

Рис. 11. Транзакция FINTAP

ПРИМЕЧАНИЕ – Данная статья была написана для версии S/4 Hana 1909, но в версии S/4 Hana 2020 концепция несколько меняется, на смену бизнес - группам приходят другие сущности. Называются они SPACES and PAGES. Но и старые группы будут действовать ещё продолжительное время.

  1. Последовательность запуска приложений Fiori

Названная в заголовке раздела последовательность изложена только для Fiori приложений, но не касается унаследованных ABAP транзакций и Webdynpro приложений.

  1. При входе в Fiori Launchpad пользователю в первую очередь показываются плитки объединённые «бизнес - группами» и «бизнес - каталогами», которые присвоены в PFCG роль данного пользователя. Это делает специальный OData сервис, отвечающий за отображение плиток для пользователя в Fiori Launchpad.
  2. Для запуска Fiori приложения пользователь нажимает на плитку. Далее система определяет технические параметры приложения при помощи целевого указания (target mapping).
  3. Когда браузер пользователя загружает Fiori приложение, то оно получает свои динамические данные из OData сервиса на Frontend сервере для данного конкретного приложения. Frontend сервер переключает HTTP запрос через доверительный RFC вызов на Backend сервер и далее извлекает данные в соответствии с бизнес - логикой OData службы приложения. Пользователю нужны полномочия для запуска OData сервиса, связанного с запускаемым приложением и на Frontend сервере и на Backend сервере, а также еще и полномочия на данные и бизнес-логику в Backend. Плитки могут использовать старые GUI и Webdynpro приложения, в этом случае, приложение вызывается напрямую в Backend без задействования OData сервисов и в данном случае, полномочий S_SERVICE на Frontend не нужно.

Общее резюме главы - чтобы работали плитки, один и тот же каталог надо добавить и на Frontend и на Backend (ландшафт типа hub) для конкретного пользователя в его роли. Чтобы работали плитки, имеются и другие условия, которые в этой статье не рассмотрены, то есть, к примеру, должен быть активирован OData сервис, имеющий отношение к этому каталогу. Чтобы плитки статично отображались, каталог должен входить в какую-либо группу, которая также добавлена в роль пользователя. Бизнес – каталоги, поставляемые SAP, уже настроены, так что никаких дополнительных действий на добавление полномочий в большинстве случаев не нужно, достаточно добавить сам каталог, всё с ним связанное подтянется автоматически. Но кончено же имеются исключения, когда необходимо добавлять специальные инструменты аналитики и отчетности.

  1. Практический пример добавления в роль транзакции и Fiori приложения

    1. Шаг 1 - Поиск транзакций и Fiori приложений в стандартных каталогах

Пример будет рассмотрен на варианте ландшафта типа hub для лучшего понимания того, как распределены полномочия между системами. Для примера можно взять ту транзакцию, что выше упоминалась в статье, то есть FB02. Необходимо найти в каком стандартном техническом или бизнес каталоге она содержится, а затем добавить её в Fiori Launchpad.

Выполнить поиск, в каком из каталогов находится транзакция FB02, можно при помощи транзакции /UI2/FLPCM_CUST - «Менеджер контента Fiori Launchpad» (добавить /n перед транзакцией). При помощи данной транзакции управляется содержимое каталогов Fiori Launchpad в конкретном манданте.

Первым шагом выполнить поиск транзакции FB02 через функцию «плитки/мэппинги целей». См. Рис. 12. В результате поиска можно убедиться, что плитка для транзакции FB02 находится в техническом каталоге SAP_TC_FIN_GL_BE_APPS.

Рис. 12. Поиск каталога, содержащего транзакцию FB02

Теперь

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти