Часть 6. Продолжение.

Часть 1  Часть 2  Часть 3  Часть 4  Часть 5  

Оглавление

1. СОЗДАНИЕ ПЛИТКИ SAP FIORI ИЗ CDS-РАКУРСА

1.1. Архитектура SAP Fiori

1.2 Основные термины

1.3 Fiori Launchpad Designer

1.4 OData Services: публикация ракурса и активация сервиса

1.5 Полномочия пользователя Fiori Launchpad

1.6 Создание плитки из CDS-ракурса через OData Service

1.6.1 Начало работы через каталог в Fiori Launchpad Designer

1.6.2 Определение Service URL для создаваемой плитки

1.6.3 Завершение настроек и размещение плитки в группе

1. СОЗДАНИЕ ПЛИТКИ SAP FIORI ИЗ CDS-РАКУРСА

1.1. Архитектура SAP Fiori

Использование приложений и пользовательского интерфейса SAP Fiori для S/4HANA требует конфигурации определённого системного ландшафта. Специфика этого ландшафта определяет и те действия, которые потребуются для создания Fiori-приложения из CDS View. Поэтому в данном разделе приводится краткий обзор архитектуры SAP Fiori. На Рис.1 приведены основные элементы архитектуры на примере версии S/4HANA 1709. Именно эта версия использовалась для построения примеров в данной работе. В других версиях S/4HANA архитектура та же, различия только в релизах программных компонент. Аббревиатура «OP» на Рис.1, означает «on-premise», то есть традиционный вариант инсталляции SAP-систем с использованием серверов и другого оборудования, принадлежащих компании-пользователю системы. Альтернативой варианту «on-premise» является развёртывание систем в облаке.

Рис.1. Архитектура SAP Fiori в системе S/4HANA 1709 (on-premise)

Несколько слов подробнее о компонентах, перечисленных на Рис.1.

Браузер. Обычный веб-клиент, который может быть использован как на персональном компьютере пользователя, так и на мобильных устройствах. Браузер визуализирует для пользователя интерфейс Fiori-приложений. Для доступа ко всем приложениям пользователь использует единую централизованную точку входа, единый URL. Эта точка называется SAP Fiori Launchpad. Он содержит ссылки на все приложения, доступные пользователю в рамках присвоенных ему полномочий. Визуально эти ссылки оформлены так, что напоминают ряды плиток. Поэтому они и получили название «плитки» (Tiles).

SAP Web Dispatcher. Это прокси-сервер специального типа, так называемый Reverse Proxy. Задача данного сервера – перенаправлять запросы, поступающие через веб-браузер, к тем серверам, которые предназначены для обработки этих запросов. Но при этом конечный пользователь работает с единым интерфейсом, с одним URL. То есть пользователь «не замечает» того, что обработка его запросов поручается различным серверам системы. Необходимость использования Reverse Proxy  объясняется двумя основными соображениями. Во-первых, между Reverse Proxy и остальными элементами архитектуры можно установит файрволлы, что существенно повысит уровень безопасности. Во-вторых, Reverse Proxy обеспечивает различную обработку веб-запросов в зависимости от типа Fiori-приложения.  Существуют следующие типы Fiori-приложений:

• Транзакционные. Это аналоги обычных транзакций в SAP GUI. Они предназначены для создания, изменения отдельных проводок и документов, для их согласования и т.п.
• Операционные отчёты (Fact Sheet). Это приложения, позволяющие пользователю получить полный обзор текущей контекстной информации по какому-то заданному объекту
• Аналитические. Приложения данного типа предоставляют доступ к большому объему обобщённых, агрегированных бизнес-данных, позволяя пользователю контролировать и оценивать как стратегические, так и операционные KPI.

В зависимости от типа Fiori-приложения, Reverse Proxy направляет запросы из браузера к тому или иному из серверов, изображённых на Рис.1. Подготовка данных для аналитических приложений происходит на уровне сервера SAP HANA. Для операционных отчётов запросы направляются на сервер Back-End (то есть непосредственно в ABAP-систему S/4HANA). Для всех трёх типов Fiori-приложений требуется «завернуть» данные в пользовательский интерфейс. Для этого Reverse Proxy направляет запрос к серверу Front-End.

• -End Server. Работа этой системы обеспечивается сервером приложений ABAP на основе платформы SAP Netweaver. На сервере Front-End хранится и выполняется вся специфическая логика, обеспечивающая работу интерфейса приложений SAP Fiori. При использовании сервера Front-End в ландшафте S/4HANA, на нём также инсталлируются дополнительные компоненты SAP Fiori for SAP S/4HANA. Они содержат интерфейсную логику тех приложений, которые включены в стандартную поставку системы S/4HANA. В состав сервера входит также компонент SAP Gateway. Он обеспечивает механизм доступа к данным и приложениям бизнес-логики в системе Back-End. Данный механизм носит название OData Services.
• -End Server. Эта система является центральным компонентом ландшафта S/4HANA. На данном сервере хранится и выполняется вся бизнес-логика, обеспечивающая стандартную функциональность в S/4HANA. В частности, это приложения S/4HANA Embedded Analytics, основанные на CDS-ракурсах стандартной VDM, либо на пользовательских ракурсах.
• Database. База данных, обеспечивающая хранение информации и функционирование сервера Front-End. Это может быть как in-memory база SAP HANA, так и базы с традиционным дисковым хранением данных: SAP MaxDB или SAP/Sybase ASE.
• HANA. Платформа, которая обеспечивает как СУБД для инсталляции сервера Back-End, так и обработку запросов от аналитических приложений.

Взаимодействие между компонентами Front-End и Back-End требует выполнения ряда специальных настроек. Здесь эти вопросы не рассматриваются, далее предполагается, что все настройки уже проведены администраторами SAP Basis. Подробная инструкция SAP по выполнению этих настроек и созданию полномочий доступна по ссылке: https://support.sap.com/content/dam/SAAP/Sol_Pack/Library/Configuration/MAA_S4HANA1709_BB_ConfigGuide_EN_XX.docx

Для функционирования S/4HANA Embedded Analytics требуется специальным образом сконфигурировать продуктивный мандант в системе Back-End. Инструкции по конфигурации даны в SAP-ноте 2289865. Здесь эти вопросы не рассматриваются, далее предполагается, что все настройки уже проведены администраторами SAP Basis.

1.2 Основные термины

В данном разделе поясняются несколько стандартных терминов, которыми необходимо оперировать в процессе создания и настройки Fiori-плиток.

• Object. Какая-либо бизнес-сущность (например, материал, сбытовой заказ, контрагент). Использование семантических объектов позволяет при разработке приложений не вникать в детали реализации этих сущностей. Достаточно знать набор их свойств и действий, которые с ними можно выполнять.
• Object parameters. Определение конкретного экземпляра семантического объекта. Например, если семантическим объектом является «сотрудник», то его параметром является табельный номер.
• . В данном случае подразумевается конкретное действие, которое необходимо выполнить с экземпляром семантического объекта. Например – изменить должность сотрудника с определённым табельным номером. Или утвердить сбытовой заказ с определённым номером.
• . Ситуация, в которой известно: какое действие, над каким экземпляром какого семантического объекта требуется выполнить. Для такой ситуации действительно подходящим названием является «намерение».
• Mapping. «Цель». Реальное приложение на сервере, которое запускается для исполнения «намерения».
• . Плитка, ссылка специального вида на SAP Fiori Launchpad. Эта ссылка увязывает между собой «намерение» и «цель». Иными словами, когда конечный пользователь нажимает на плитку, система получает сигнал о том, что необходимо реализовать определённое «намерение» с помощью приложения, заданного в «цели».
• . Каталог. Набор плиток и Target Mappings, объединённых по какому-либо критерию. Например, стандартные каталоги, поставляемые в SAP S/4HANA группируют плитки по линиям бизнеса (MM, CRM и т.п.) и по типам приложений (транзакционные, операционные, аналитические).
• . Группа. Содержит плитки из каталогов. Группировка происходит по должностным функциям сотрудников. Например, в одну группу собираются плитки, необходимые в работе менеджера по продажам. А в другую группу – плитки для работы финансового аналитика.

На Рис.2 приведена схема соотношений между перечисленными объектами, с указанием кардинальности этих взаимосвязей.

Рис.2. Взаимосвязи основных понятий, используемых при создании Fiori-плиток

1.3 Fiori Launchpad Designer

Как уже говорилось, SAP Fiori Launchpad – это центральная точка входа для конечного пользователя интерфейса SAP Fiori. Это веб-страница, на которой пользователь видит все плитки в соответствии с теми ролями и полномочиями, которые у него есть. Адрес этой страницы имеет следующий вид: <protocol>://<server>:<port>/sap/bc/ui2/flp  Здесь:

• protocol – Протокол, используемый для доступа. Зависит от настроек системы, сконфигурированных администраторами SAP Basis. Возможные варианты – http или https.
• server – полное доменное имя сервера (например, servername.domainname.ru). В зависимости от конфигурации это может быть как имя сервера, на котором инсталлирована система Front-End, так и имя сервера, на котором работает предварительно сконфигурированный SAP Web Dispatcher.
• port – номер порта, к которому идёт обращение на сервере. Номер порта также устанавливается при конфигурации системы администраторами SAP Basis.

Запоминать указанный веб-адрес или сохранять его в закладках браузера необязательно. Вызвать SAP Fiori Launchpad можно напрямую из SAP GUI, набрав код транзакции /n/UI2/FLP.

При входе по указанной ссылке пользователю потребуется указать логин и пароль, так же как при обычном входе в систему через SAP GUI (см. Рис.3).

Рис.3. Экран входа в SAP Fiori Launchpad

Для создания и редактирования плиток используется специальное веб-приложение. Оно называется Fiori Launchpad Designer. Также это приложение позволяет упорядочивать плитки, объединяя их в группы.

Ссылка для доступа к Fiori Launchpad Designer имеет вид  <protocol>://<server>:<port>/sap/bc/ui5_ui5/sap/arsrvc_upb_admn/main.html

Нужно подчеркнуть, что Fiori Launchpad Designer не является инструментом разработки Fiori-приложений. Для этого используется отдельный самостоятельный инструмент SAP Web IDE.

Как видно из Рис. 2, для создания плитки нужно предварительно разработатьобъекты, обеспечивающие «размещение» этой плитки на Fiori Launchpad. А именно, создаются каталог и группа, затем роль. Детально последовательность действий описана в официальной документации SAP: 

https://support.sap.com/content/dam/SAAP/Sol_Pack/Library/Configuration/MAG_S4HANA1709_BB_ConfigGuide_EN_XX.docx (см. разделы 3.2-3.4). Далее предполагается, что в целях выполнения демонстрационных примеров созданы каталог Z_RDS_BC, группа Z_RDS_BCG и роль Z_RDS_BCR, описанные в этой документации.

1.4 OData Services: публикация ракурса и активация сервиса

Исходя из описанной архитектуры, для создания Fiori-плитки на основе CDS-ракурса необходимо выполнить следующие действия:

1. Создать ракурс использования (Consumption View) в системе Back-End. В нашей демонстрационной модели он уже был создан ранее – это ракурс ZC_AIRLINEQUERY.
2. Добавить в этот ракурс специальную аннотацию, обеспечивающую доступ к ракурсу через механизмы OData Services.
3. Активировать OData-сервис, который автоматически будет создан благодаря использованной аннотации.
4. Присвоить пользователю системы Front-End полномочия, необходимые для создания Fiori-плиток.
5. Используя Fiori Launchpad Designer, создать плитку с данными из CDS-ракурса.
6. Настроить объекты (каталоги и роли) в Fiori Launchpad для предоставления доступа пользователям к созданной плитке.

В этой последовательности шаги 1-3 выполняет разработчик (модульный консультант и/или программист ABAP). Шаг 4 выполняет администратор полномочий SAP Basis. Шаги 5 и 6 может самостоятельно выполнить конечный пользователь. Если же ролевая матрица доступа не предполагает у конечных пользователей прав по работе с Fiori Launchpad Designer, то шаг 5 также нужно выполнить разработчику.

Для того, чтобы данные из ракурса использования стали доступны «внешним» потребителям (в том числе и системе Front-End) через OData Service, нужно всего лишь добавить в DDL-код аннотацию @OData.publish: true. После повторной активации ракурса рядом с аннотацией появится пиктограмма с предупреждением. Чтобы увидеть подробности, достаточно подвести курсор мыши к пиктограмме. Тот же текст предупреждения можно увидеть и ниже, на закладке Problems (см. Рис.4).

Рис.4. Предупреждение о том, что неактивен OData-сервис, сгенерированный на основе CDS-ракурса

Использование аннотации вызывает автоматическую генерацию OData-сервиса, обеспечивающего доступ к данным из ракурса. Техническое имя такого сервиса будет состоять из технического имени ракурса и постфикса _CDS. Однако аннотация только создаёт OData-сервис, но не активирует его. И полученное выше предупреждение как раз сообщает об этом. Для анализа подобных сообщений можно использовать встроенную справку. Достаточно в закладке Problems нажать правой кнопкой на текст сообщения. В появившемся контекстном меню выбрать Problem Description. Откроется новое окно ABAP Problem Description (см. Рис.5).

Рис.5. Подробная справка для предупреждения, показанного на Рис.4

Ранее указывалось, что доступ к данным сервера Back-End через OData-сервис происходит из системы Front-End. Именно она получает запрошенные данные и отвечает за их визуализацию в веб-браузере. Поэтому активировать OData-сервис необходимо именно в Frontend-системе, содержащей компонент Gateway.

Итак, нужно через SAP GUI войти в систему Front-End и запустить транзакцию /IWFND/MAINT_SERVICE. Поскольку код транзакции начинается с символа /, то SAP GUI не может его корректно интерпретировать без дополнительных указаний. Чтобы транзакция запустилась, необходимо перед кодом добавить стандартную команду /o или /n (см. Рис.6).

Рис.6. Вызов транзакции /IWFND/MAINT_SERVICE

Открывшаяся транзакция выводит список уже активированных OData-сервисов, позволяет активировать дополнительные сервисы (которые предварительно созданы в системе, например как у нас – через публикацию CDS-ракурса), тестировать работоспособность активированных сервисов (см. Рис.7).

Рис.7. Стартовое окно транзакции /IWFND/MAINT_SERVICE

Для активации нового сервиса нужно нажать кнопку . В открывшемся окне сначала требуется заполнить поле System Alias. Это поле – псевдоним той ABAP-системы, в которой выполняется OData-сервис. В нашем случае необходимо выбрать Alias, указывающий на систему Back-End. Этот Alias уже доступен для выбора из списка, если проведены настройки, упомянутые в завершении раздела «Архитектура SAP Fiori». Как правило, имя такого псевдонима составляется из SID системы (её трёхсимвольного имени), букв CLNT и трёх цифр с номером рабочего манданта. Например: SIDCLNT001 (см. Рис.8).

Рис.8. Выбор псевдонима для поиска OData-сервисов