 База знаний

Практика освоения ABAP CDS для непрограммистов. Часть 1

Виталий Васильев
Прочитать позже
2567
1

АННОТАЦИЯ
Публикация предназначена для консультантов по различным модулям SAP ERP. Описываемая
технология ABAP CDS наиболее актуальна для систем SAP S/4HANA, но может применяться и в
любых системах, начиная с платформы SAP Netweaver 7.40 SPS05, независимо от используемой
базы данных.

Для быстрого погружения в тему приводится серия практических примеров, которые читатель
может самостоятельно повторить в своей системе.

Изложенная информация будет полезна при решении задач, связанных с разработкой операционной
и аналитической отчётности: самостоятельное создание отчётов, постановка задач для
разработчиков ABAP или BW, анализ и использование уже существующих в системе стандартных
или пользовательских разработок.

От читателя предполагается начальное знакомство с инструментальными средствами и элементами

языка ABAP в объеме учебного SAP-курса BC400: работа с ABAP-словарём, программы,
функциональные модули, классы и методы. Также необходимо знакомство с основами SQL.

Некоторые из запланированных в дальнейшем глав публикации будут адресованы разработчикам

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

ПРЕДИСЛОВИЕ
Линейка продуктов компании SAP постоянно пополняется новыми наименованиями, на смену
привычным версиям знакомых систем приходят новинки, полностью пересмотренные
архитектурно, появляются новшества и в технологиях разработки. Изменений много, происходят
они быстро. Порой даже то, что преподносилось как новшество, отходит на второй план и перестаёт
развиваться уже в следующем пакете обновлений. В такой ситуации следить за развитием событий,
быть в курсе новинок – задача, которая иногда оказывается непростой не только для компаний,
использующих продукты SAP, но и для профессиональных консультантов. Знакомиться с новыми
продуктами и технологиями работы приходится по презентациям, слайдам, видеороликам. Но такие
источники зачастую ограничиваются общими словами и приукрашивают действительность в
интересах маркетинга.

Для консультантов здесь возникает разрыв между презентационной информацией о новинках и

реальностью их применения, техническими подробностями. Подробностями, которые бы позволили
оценить истинные возможности продукта, его технологические преимущества, пути миграции с
используемых старых решений, трудозатраты на поддержку и развитие, на переобучение или
привлечение новых специалистов. И при этом никто не отменит необходимость для консультанта
быть готовым к включению в работу с этими новинками. Причём ожидается, что для бизнес-
пользователей качество поддержки и развития новых решений будет как минимум не ниже, чем
было с предыдущим поколением систем.

Одной из таких технологий, появившихся сравнительно недавно, продолжающей интенсивное

развитие и получающей всё больше практических применений в новейших версиях SAP-систем,
является ABAP Core Data Services (CDS). Предлагаемая вниманию читателя работа имеет целью
дать первоначальное представление о возможностях этой технологии, привести практические
примеры, иллюстрирующие способы разработки и возможности применения CDS. Имея в виду
упомянутый разрыв между презентациями и техническими деталями, основной упор сделан именно
на практические примеры, которые читатель мог бы самостоятельно воспроизвести в своей
тестовой системе.

Первая публикация содержит краткий теоретический обзор: предпосылки возникновения ABAP

CDS, «взаимоотношения» этой технологии с классическим OpenSQL. Затем рассматривается
понятие виртуальной модели данных (VDM) и на серии простых практических примеров строится
небольшая демонстрационная VDM. Параллельно с практическими примерами, по мере их
расширения и усложнения, приводятся и краткие теоретические сведения о таких элементах CDS,
как аннотации, ассоциации, path expressions.

В дальнейших публикациях планируется рассмотреть такие применения CDS-ракурсов, как

построение Fiori-приложений, Query Browser и визуализация с помощью программ линейки SAP
BusinessObjects. Также запланирована отдельная серия практических примеров, ориентированных
на работу консультантов SAP BW. Методами CDS можно создавать достаточно сложные и
функциональные отчёты BW непосредственно на «живых» данных из таблиц транзакционной
системы.

Поскольку основной задачей данных публикаций является начальное практическое освоение

возможностей ABAP CDS консультантами, то подборку публикаций планируется включить также
следующие темы. Они не взаимосвязаны между собой, но могут быть востребованы на практике:

 Расширение (extending) существующих CDS-ракурсов

 Опции ABAP Development Tools, делающие работу с CDS более удобной: Dependency
Analyzer, Graphical Editor, Active Annotations
 Табличные функции
 Работа в CDS-ракурсами в ABAP программах: вывод в ALV. Оптимизация вывода грида с
использованием SALV IDA
 Роли и авторизации через DCL

Оглавление
1. ВВОДНАЯ ИНФОРМАЦИЯ

1.1. Эволюция работы с SQL в ABAP: от Open SQL к Core Data Services

1.1.1 Ограничения при использовании OpenSQL

1.1.2 Новые подходы к разработке приложений в SAP HANA и ABAP CDS

1.1.3 Преимущества ABAP CDS по сравнению с классическими инструментами

1.2. Virtual Data Model

1.2.1 Предпосылки появления VDM

1.2.2 Преимущества VDM в SAP S/4HANA

1.2.3 Виды CDS-ракурсов в VDM. Иерархическая организация VDM

1. ВВОДНАЯ ИНФОРМАЦИЯ
1.1. Эволюция работы с SQL в ABAP: от Open SQL к Core Data
Services

1.1.1 Ограничения при использовании

OpenSQL
Классическим подходом, реализующим SQL при работе с ABAP Application Server, являлся Open
SQL. Это подмножество стандартного SQL, встроенное в язык ABAP.  То есть команды Open SQL
можно писать напрямую в ABAP-коде без каких-то специальных мер адаптации. Безусловно, это
очень удобный способ работы из ABAP с информацией таблиц БД, но он имеет ряд значительных
ограничений по сравнению с полноценным SQL.

Наиболее сильным из таких ограничений является следующее. Команды классического SQL можно
разделить на три подмножества:

 DML – Data Manipulation Language. Содержит команды, выполняющие выборку или

изменение данных (SELECT, INSERT, UPDATE, DELETE)
 DDL – Data Definition Language. Содержит команды, позволяющие создавать или изменять
объекты БД. Например – CREATE/ALTER/DROP TABLE
 DCL – Data Control Language. Содержит команды, позволяющие управлять правами доступа
к объектам БД.

Из этих трёх подмножеств в Open SQL реализован только DML. Конструирование объектов БД
выполняется через инструментарий ABAP Dictionary (транзакция SE11 и т.п.). А настройки
полномочий через DCL вообще нерелевантны для ABAP, так как полномочия пользователей
никогда не определяются на уровне объектов БД.

Если же вернуться к DML, то и его стандартные возможности доступны в Open SQL не полностью.
Вот только некоторые из возможностей классического DML, недоступные в Open SQL:

 Команда UNION
 Условия ветвления (команда CASE)
 Вычисляемые значения в условиях WHERE
 Вычисляемые поля в списке после SELECT
 SQL-функции
 Full/right outer join
  Non-equi-join (то есть возможность использования знаков неравенства в условиях WHERE
при сравнении значений полей из двух таблиц)
 Определение ракурсов БД не только на основе таблиц, но и на основе других ракурсов.

Обойти столь жёсткие ограничения позволет использование так называемого Native SQL. В 
программном блоке между командами EXEC SQL и ENDEXEC можно написать SQL-выражение,
использующее возможности, специфические для той конкретной СУБД, на которой развёрнут
сервер приложений. Однако такой подход имеет свои особенности и риски. Наиболее очевидный из
которых – невозможность простой миграции такого приложения на другую СУБД.

Есть две основных причины серьёзных коллизий в использовании Open SQL. Во-первых, являясь
частью языка ABAP, команды Open SQL должны обеспечивать одинаковый и корректный результат
работы вне зависимости от того, на какой СУБД развёрнут сервер приложений. И если какие-то
операции DML могут быть по-разному реализованы в различных СУБД (например – округление
при арифметических вычислениях), то такие операции исключаются из Open SQL. Во-вторых, при
работе с классическими СУБД считается, что для улучшения производительности необходимо
максимально переносить вычислительную нагрузку с уровня БД на уровень сервера приложений. А
для него не требуются развитые возможности SQL.

1.1.2 Новые подходы к разработке приложений

в SAP HANA и ABAP CDS
Появление SAP HANA, с её мощными возможностями обработки больших массивов данных,
повлекло фундаментальные изменения в подходах к разработке приложений. Важнейшую роль стал
играть перенос на уровень БД той части логики, которая отвечает за массовую обработку данных
(так называемая Data-Centric Logic). Для традиционных СУБД такой перенос осуществим лишь
частично, для SAP HANA – практически полностью.  Распространённым названием для такого
подхода стал термин «Code-to-data», иллюстрируемый на Рис.1:

Рис.1. Перенос логики «Code-to-data»

Перевод картинки:
  Classic Approach – Классическое выполнение кода
 Intensive computations in APPLICATION layer – Основные расчёты на сервере приложений
 Database – База данных
 Application Programming Models – Программный код приложений
 Data Centric Approach – Выполнение кода на уровне данных
 Intensive computations in DATABASE layer – Основные расчёты в СУБД

С появлением SAP HANA также связано и ещё одно важное изменение в разработке приложений.
Возможности SAP HANA XS позволяют создавать приложения непосредственно на базе данных, а
не на сервере приложений. Такая разработка, в свою очередь, влечёт необходимость в
инструментарии работы с метаданными (вместо ABAP Dictionary). Этот инструментарий не может
ограничиваться просто созданием таблиц или ракурсов БД. Он должен также обладать широкими
возможностями семантического обогащения этих ракурсов. Например, определять удобные
словесные названия для полей, выделять специфические поля, содержащие тексты, обозначения
языка, валюты, единиц измерения, и т.д. Также появляется необходимость и в определении
полномочий напрямую на создаваемых объектах БД. Для решения этих задач SAP предоставил Core
Data Services (CDS). CDS – это совокупность из трёх предметно-ориентированных языков,
предназначенных для создания и использования семантически обогащённых моделей данных.
Задачи, решаемые каждым из этих языков, проиллюстрированы на Рис.2:

Рис.2. Предметно-ориентированные языки в CDS

Перевод картинки:

 Data modelling and retrieval… – Семантически обогащённое моделирование и представление

данных
 Extends native SQL means… – Расширение возможностей Native SQL для повышенной
производительности
 Consume CDS entities… - Использование CDS-ракурсов в ABAP средствами Open SQL
 Fully transparent… - Доступные для понимания расширения SQL
 Define authorizations for… - Создание полномочий для доступа к CDS-ракурсам
 Modelled and declarative approach – Однократно декларируемые правила доступа к CDS
 Integrates with classic… - Возможно использование в классических ролях и объектах
полномочий
Появление CDS, также как концепции «Code-to data», было мотивировано возможностями SAP
HANA. Но они не ограничиваются только этой платформой. С выходом SAP Netweaver 7.40 SP5
впервые стала доступна технология ABAP CDS. В распоряжении консультантов, ведущих
разработку на сервере приложений, уже имелся ABAP Dictionary. Но DDL в  ABAP CDS
предоставляет разработчику более широкие возможности (об этом чуть ниже). Поэтому логичным
стало добавление CDS-сущностей к ABAP-словарю: сначала разработчик с использованием DDL
составляет код, определяющий CDS-сущность, а потом в процессе активации этого кода создаётся
объект ABAP-словаря. В том числе, такой объект может далее использоваться через Open SQL.

Итак, Data-Centric Logic перенесла массивные вычисления с сервера приложений на уровень БД.
CDS расширил возможности использования SQL в программном коде ABAP. И в то же время
появился подход, при котором логика работы пользовательского интерфейса (UI Application Logic)
стала отделяться от основного приложения, а иногда и переноситься на сторону клиента или
отдельного сервера приложений. Разделение UI-логики и бизнес-логики приложений позволило
разделить жизненные циклы соответствующих частей программного кода. Всё это вместе привело к
архитектурным изменениям, как в системном ландшафте, так и в разработке приложений.
Классическое «распределение обязанностей» проиллюстрировано на Рис.3:

Рис.3. В классических SAP-системах вся логика исполняется на сервере приложений

Перевод картинки:

 UI Rendering – Визуализация интерфейса

 Presentation Server – Сервер визуализации
 UI Application Logic – Логика функционирования интерфейса
 Service Logic – Бизнес-логика приложения
 Data-Centric Logic – Логика обработки данных
 Database – База данных
  Relational Database – Реляционная СУБД
 Application Server – Сервер приложений

Теперь же описанные инновации изменили картину. Выполнение различных «участков» логики

приложений распределилось так, как это показано на Рис.4:

Рис.4. Распределение исполнения логики приложений в современных SAP-системах

Перевод картинки:

 UI Rendering – Визуализация интерфейса

 UI & Client Side Application Logic  – Сервер интерфейсной логики и визуализации
 UI Application Logic – Логика функционирования интерфейса
 Service Logic – Бизнес-логика приложения
 Application Server ABAP – Сервер приложений ABAP
 Data-Centric Logic – Логика обработки данных
 Database – База данных
 CDS ABAP (as part of ABAP Dictionary) – CDS ABAP (в составе ABAP-словаря)
 Database Schema – Схема БД
 (Any) Database – База данных (в.т.ч SAP HANA)

1.1.3 Преимущества ABAP CDS по сравнению с

классическими инструментами
Какие же преимущества даёт DDL в ABAP CDS по сравнению с традиционным созданием ракурсов
БД через ABAP-словарь? Есть изменения, связанные непосредственно с возможностями
определения ракурсов. Эти новшества проиллюстрированы на Рис.5:
Рис. 5. ABAP Dictionary vs ABAP CDS

Перевод картинки:

 ABAP Dictionary Views – Ракурсы ABAP-словаря

 ABAP CDS Views – CDS-ракурсы
 Support on all DBMSs – Поддерживается на всех СУБД
 inner join & simple selection only – только inner join и простые выборки
 not supported – не поддерживается
 Calculation expressions, aggregation, grouping – Вычисляемые выражения, агрегация,
группировка
 Nested views (on views)  – Ракурсы, вложенные друг в друга

Но помимо этого, появляются ещё и возможности, ранее недоступные при разработке приложений:

 Аннотации (Annotations) для обогащения модели данных дополнительными метаданными. В

том числе, можно добавлять семантическую информацию для приложений-потребителей
(аналитические приложения, OData-сервисы, SAP UI5)

 Определение семантических взаимосвязей между CDS-объектами, которое при компиляции

кода транслируется в JOIN. Такие взаимосвязи называют ассоциациями (Associations).
 Определение полномочий для доступа к CDS-объектам

 Выражения, используемые для вычислений и подзапросов в модели данных

Схематически эти возможности проиллюстрированы на Рис.6:

 Рис.6. Возможности семантического обогащения данных в CDS DDL

Перевод картинки:

 Entities with… – Структурные и пользовательские типы данных

 Associations… – Ассоциации, т.е. семантические взаимосвязи
 Calculated Fields… - Определение расчётных полей внутри модели данных
 Annotations – Аннотации для обогащения метаданных

Возможности DDL постоянно расширяются. Это необходимо учитывать при изучении

примеров, приведённых в дальнейших разделах. Например, только в Netweaver 7.5
появилась поддержка таких возможностей, как Foreign Keys, Table Functions, Graphical
Editor, OData и публикация в Fiori

Ниже по тексту будет часто использоваться термин «CDS-ракурс». Это некоторое упрощение,
сделанное для краткости. На самом деле, в зависимости от контекста, речь может идти про один из
трёх объектов:

1. DDL Source – Текстовое описание CDS-сущности, написанное на DDL. В ходе активации из

DDL Source создаются два следующих объекта
2. SQL View – Объект, который доступен (только для просмотра!) в ABAP-словаре. Является
представлением для объекта базы данных. Не показывает семантические добавки,
включённые в DDL через аннотации
3. CDS View Entity – Объект, который несёт в себе всю семантику, определённую аннотациями.
Может быть использован в ABAP-коде через Open SQL (и поэтому не содержит в явном виде
поля «мандант»). Но при этом данный объект не существует в базе данных и в ABAP-
словаре.

Иллюстрация описанных объектов приведена на Рис. 7:

Рис.7. Три основных объекта в ABAP CDS

Перевод картинки:

 DDL Source – DDL-источник

 SQL View – SQL-ракурс
 CDS View – CDS-ракурс
 Repository Object (Dictionary) – Объект ABAP-словаря
 Represents… - Представляет «реальный» объект БД
 Is an ABAP data type (structure, with client field) – ABAP-структура (с полем «мандант»)
 No additional semantics – Нет дополнительных метаданных
 Not found in repository – Не содержится в ABAP-словаре
 Not known to database – Недоступен в БД
 Is an ABAP data type (structure, without client field) – ABAP-структура (без поля «мандант»)
 Additional semantics (Annotations) – Дополнительные метаданные (Аннотации)

Необходимо отметить важное обстоятельство. Спецификация CDS является независимой от

платформы, на которой ведётся разработка, но реализации HANA CDS и ABAP CDS являются
различными. Они имеют различные возможности, несовпадающие жизненные циклы,
совместимость разработок между этими реализациями не может быть гарантирована. Дело в том,
что HANA CDS – это часть платформы SAP HANA. Назначение HANA CDS – это разработка
приложений напрямую в SAP HANA XS. Поэтому HANA CDS может использовать возможности,
имеющиеся только в SAP HANA и недоступные для других СУБД. Помимо этого, HANA CDS
ориентирована на построение модели данных «с нуля». С другой стороны, ABAP CDS – это часть
сервера приложений ABAP. Она интегрирована в ABAP Dictionary. Жизненный цикл объектов,
разработанных в ABAP CDS, управляется обычной транспортной системой, как и для других
ABAP-разработок. ABAP CDS не имеет специфики, связанной с какой-то определённой СУБД.
Основное назначение ABAP CDS – это разработки на сервере приложений.

1.2. Virtual Data Model

1.2.1 Предпосылки появления VDM
Со стороны бизнес-пользователей SAP ERP всегда существовал запрос на возможность
самостоятельно анализировать данные, группируя и фильтруя их по собственному усмотрению.
Такая возможность получила название self-service BI. Проводить такой анализ непосредственно на
основе таблиц ABAP-словаря невозможно, так как они имеют неинформативные, технические
названия полей. А структура таблиц и их взаимосвязи сформированы исходя из правил организации
реляционной БД и из логики работы стандартного ABAP-кода SAP ERP.  Для конечного
пользователя, не являющегося IT-специалистом, работа с таким первоисточником недоступна.
Чтобы преодолеть эти сложности, необходимо создать так называемую виртуальную модель
данных (VDM) над таблицами ERP. VDM - это совокупность ракурсов, созданных на таблицах SAP
ERP. VDM предоставляет конечному пользователю упрощённое бизнес-ориентированное
представление данных. «Виртуальность» модели данных означает, что информация доступна в
форме, порой значительно отличающейся от таблиц ERP с их неудобными названиями и
непонятными полями. Большое внимание уделяется семантическому обогащению модели, то есть
такому представлению данных, которое будет понятнее и удобнее для бизнес-пользователя.
Помимо этого, VDM может служить источником данных для аналитических приложений (см.
Рис.8).

Рис.8. Место VDM в аналитике транзакционных данных

Перевод картинки:

 Database Layer, e.g SAP HANA -  уровень БД (например, SAP HANA)

 Physical Tables – Таблицы БД
 Virtual Data Model – Виртуальная модель данных
 View – Ракурс
 Transactional system, e.g. SAP S/4HANA – Транзакционная система (например, SAP S/4HANA)
 UI’s – Пользовательские интерфейсы
 Application – Приложение

Можно предположить, что дальним предком такой VDM являлись так называемые инфо-наборы,
уже давно появившиеся в старых версиях SAP ERP. Там с помощью транзакций SQ01-SQ03
продвинутый пользователь, не прибегая к помощи SAP-консультантов (а тем более программистов
ABAP), мог составить простейшие соединения из нескольких таблиц, оформить селекционный
экран для ограничения выборки данных, создать простейший «дизайн» своего отчёта. Более
сложным инструментом подобной разработки является Report Painter. Самым гибким подходом, но
в то же время и требующим самой глубокой профессиональной квалификации, является разработка
операционных отчётов на данных SAP ERP с помощью ABAP-программирования.

Русские аналоги технических терминов, предлагаемые ниже по тексту, могут разниться

с другими публикациями, так как устоявшейся русской терминологии, относящейся к
данной области, пока нет.

С появлением нового поколения SAP-систем, построенных на базе SAP HANA, было предложено
такое развитие концепции инфо-наборов, как HANA Live. Вендор предлагал очень широкий спектр
заранее разработанных HANA-моделей, позволявших строить разнообразную операционную
отчётность по данным различных модулей в ERP. Совокупность моделей, предложенного контента
и образовывала VDM над таблицами HANA. Такая модель была ориентирована на удобное для
пользователей представление данных при использовании в операционной отчётности. При этом,
разумеется, вступали в игру все преимущества SAP HANA, связанные с быстродействием и
способностью обрабатывать в режиме реального времени большие объемы первичной информации.
Однако работа с моделями данных на уровне HANA имела и свои недостатки:

 Не поддерживаются иерархии ERP

 Не поддерживается концепция полномочий ERP, требуется отдельное администрирование
полномочий на уровне HANA
 Жизненный цикл объектов реализуется транспортными средствами HANA и не совместим с
транспортной системой SAP ERP

Учитывая перечисленные проблемы, SAP заявил, что дальнейшее развитие продукта HANA Live
прекращено. Продолжением развития стала концепция VDM на основе ракурсов CDS. Эта
виртуальная модель данных появилась и развивается в системах SAP S/4HANA (см. Рис. 9)

Рис. 9. VDM в SAP S/4HANA

Перевод картинки:

 Database Layer, e.g SAP HANA -  уровень БД (например, SAP HANA)

 Physical Tables – Таблицы БД
 Virtual Data Model (based on open CDS) – Виртуальная модель данных (на основе CDS)
 View – Ракурс
 Business Transctions/Finance/Logistics/Etc. – Транзакции/Финансы/Логистика/И т.д.
 UI’s – Пользовательские интерфейсы
  Названия в верхнем ряду (группа UI’s) не переводятся

1.2.2 Преимущества VDM в SAP S/4HANA

Ключевым отличием данного решения является его полная интегрированность в ABAP-стек. Это
позволило преодолеть ограничения HANA Live и даже более:

 Жизненный цикл CDS Views обеспечивается в рамках стандартной системы переносов

 Поддерживаются обычные полномочия SAP ERP
 Поддерживается отображение ERP-иерархий при использовании в отчётах встроенной BW-
функциональности
 CDS Views предоставляют возможность создавать расширения. Тем самым обеспечивается
гибкость модели. Но в то же время коды стандартных CDS Views не изменяются, что
обеспечивает отсутствие ошибок при установке обновлений на систему
 ABAP CDS  поддерживает так называемый «code-to-data», то есть перенос сложных
вычислений с уровня сервера приложений на уровень БД. И в то же время, что замечательно,
CDS-ракурсы являются элементами ABAP-словаря на сервере приложений.
 VDM на основе CDS позволяет определять и оперировать бизнес-сущностями (такими,
например, как материал, заказ, контрагент), а также семантическими взаимосвязями этих
сущностей. Эти взаимосвязи, с технической точки зрения, близки к таким понятиям из
традиционных баз данных, как Join и Foreign Key.
 VDM предоставляет пресловутую «single point of truth» в метаданных для самых
разнообразных потребителей, таких как: OData Services, приложения Fiori, отчёты BW,
дашборды и другие приложения в Business Objects
 Подобная универсальность модели данных снимает необходимость специфической
интеграции с каждым отдельным потребителем, которая подчас требует повторного
описания одних и тех же данных, усложняет и удорожает поддержку. Это отличие
проиллюстрировано на Рис.10 и Рис.11.

Рис.10. Интеграция различных приложений-потребителей с ERP без использования VDM

Перевод картинки:

 No harmonized data… -  Нет унифицированного использования данных и метаданных

 Application data in tables– Данные приложений в таблицах БД
  Legacy Tables – Таблицы БД

Рис.11. Интеграция различных приложений-потребителей с ERP с использованием

унифицированной VDM

Перевод картинки:

 Application data in tables– Данные приложений в таблицах БД

 Cryptic table and field names – бессодержательные имена таблиц и полей
 Semantic and relations… - Семантика и взаимосвязи таблиц ясны только посвященным
 Unique semantic model (VDM) – Единая семантическая модель (VDM)
 Views and fields in business terminology – Имена ракурсов и полей взяты из бизнес-терминов
 Explicit relations – Явно обозначены взаимосвязи
 Semantically enriched – Ракурсы семантически обогащены
 Ready to use – Готовы к использованию
 Harmonized consumption – Унифицированное использование
 Analytics – Аналитические приложения
 Fiori apps – Приложения Fiori
 OData and openSQL interfaces – Поддержка интерфейсов OData и openSQL

Резюмируя преимущества VDM, можно сказать, что она является стабильной, расширяемой,
доступной для повторного использования различными потребителями. На уровне VDM
упрощается имплементация нового функционала сразу для всех потребителей, что снижает общие
затраты на использование систем. (см. Рис.12)
Рис.12. VDM позволяет предоставлять новый функционал всем потребителям одновременно

Перевод картинки:

 Application data – Данные приложений

 Semantically rich… – Семантически богатая, всеобъемлющая, готовая к использованию
модель данных, описанная в понятных бизнес-терминах
 Harmonized data and metadata consumption – Унифицированное использование данных и
метаданных

1.2.3 Виды CDS-ракурсов в VDM.

Иерархическая организация VDM
Виртуальная модель данных для CDS Views строится как бы «снизу вверх» в несколько уровней,
каждый из которых выполняет свои задачи. Рассмотрим эти уровни подробнее.

Basic view. Базовый ракурс создаётся для того, чтобы представить в VDM ключевые сущности
(например, контрагента или сбытовой заказ) в простой неизбыточной форме. Неизбыточность
означает, что каждый объект представлен ровно один раз. Причём в представление объекта
включены только неотъемлемо относящиеся к нему поля, которые не могут быть вычислены из
других полей. Базовые ракурсы определяются универсально, независимо от способа их
дальнейшего использования в VDM.

Базовые ракурсы – это единственный тип CDS Views, в определении которых могут
быть напрямую использованы таблицы базы данных.

Composite view. Композитные ракурсы строятся на основе одного или нескольких базовых
ракурсов. Между составляющими базовыми ракурсами могут быть определены семантические
взаимосвязи (в упрощённом понимании – аналог операции JOIN в SQL). Могут использоваться
операции фильтрации, агрегирования, вычисляемые поля. Строение композитного ракурса может
учитывать цель и способ его дальнейшего использования в модели. В зависимости от сложности
модели, могут быть определены несколько уровней композитных ракурсов, построенных друг на
друге. По определению данные в композитных ракурсах представляются в избыточной форме,
ориентированной на дальнейшее использование для анализа.
Совокупность базовых и композитных ракурсов называется Interface views. Интерфейсные ракурсы
создаются так, чтобы образовать целостную модель данных, ориентированную на представление их
бизнес-семантики. Эти ракурсы должны быть пригодны для повторного использования в новых
конструкциях VDM.

Consumption view. Ракурс использования. Данные ракурсы строятся с использованием одного или
нескольких интерфейсных ракурсов. Ракурс использования должен предоставлять приложению-
потребителю широкую функциональность:

 Формировать из составляющих интерфейсных ракурсов подмножество данных, релевантных

для отчётов. При необходимости накладывая глобальные условия фильтрации для отбора
таких данных
 Иметь параметры для задания пользовательских ограничений на выбор данных
 Определять и использовать ограниченные показатели взамен исходных показателей из
интерфейсных ракурсов
 Определять рассчитанные показатели, в особенности такие, которые должны вычисляться
после агрегации
 Поддерживать специальную агрегацию показателей. Например, показатели-счётчики числа
значений
 Поддерживать использование текстов и иерархий, релевантных для используемых в отчёте
аналитик

Роль различных видов ракурсов в VDM проиллюстрирована на Рис.13:

Рис.13. Иерархическая структура ракурсов в VDM

Перевод картинки:

 Database Tables – Таблицы БД

 Basic Views – Базовые ракурсы
 Composite Views – Композитные ракурсы
 Interface Views – Интерфейсные ракурсы
 Consumption Views – Ракурсы использования
  Analytics – Аналитика
 Search – Поиск
 Data retrieval for transactional applications – Получение данных для транзакционных
приложений
 Application-specific views – Ракурсы, специфичные для конкретных приложений
 Suite database model “as is” – Представляет модель данных БД «как есть»
 Expose the public… - Публикует устоявшийся интерфейс VDM для приложений-
потребителей
 Provide business semantics…- Показывает бизнес-семантику как модель данных, которую
легко применима и пригодна для повторного использования
 Domain-specific views… - Ракурсы для разных областей применения (например, для
аналитики или поиска)
 Instance authorizations… - Определение прав доступа через DCL
 Executed via… - Возможность использования в ABAP через Open SQL
 Views from various… - Ракурсы для различных приложений-потребителей используют
интерфейсные ракурсы и создают аналитические запросы на их основе

База знаний
Практика освоения ABAP CDS для непрограммистов. Часть 2

Виталий Васильев
Прочитать позже
1392

2. ИНСТАЛЛЯЦИЯ, КОНФИГУРИРОВАНИЕ,
ПОДГОТОВКА ДАННЫХ для примеров
Часть 1

Продолжение статьи.
2.1. Настройки ABAP Backend

2.2. ABAP Development Tools: общие сведения, инсталляция

2.2.1 Общие сведения

2.2.2 Установка среды Eclipse

2.2.3 Установка ADT в среде Eclipse

2.2.4 Установка  SAP HANA Studio

2.2.5 Установка ADT в  SAP HANA Studio

2.3. Конфигурирование подключения ADT к Backend-системе

2.4. Подготовка данных для демонстрационных примеров

2.1. Настройки ABAP Backend

 Как уже говорилось, функциональность ABAP CDS доступна в любых системах, начиная с SAP
Netweaver 7.40 SP5. Независимо от того, на основе какой СУБД развёрнута система.

Чтобы работать с CDS, пользователь в первую очередь должен иметь для этого необходимые
полномочия. При настройке полномочий в каждой конкретной системе, администраторы SAP Basis
могут как шаблоны использовать две стандартных роли:  SAP_BC_DWB_ABAPDEVELOPER  - 
роль, содержащая все необходимые полномочия для создания, редактирования и использования
ABAP CDS Views; SAP_BC_DWB_WBDISPLAY – роль с полномочиями, достаточными только
для использования готовых ракурсов в аналитических приложениях. Более тонкие настройки
полномочий, входящих в данные роли, детально разобраны в официальной документации:

http://help.sap.com/download/netweaver/adt/SAP_ADT_Configuration_Guide_Backend_en.pdf  (см.
раздел 2 «Providing Roles and User Authorizations»)

Также для корректной работы с новыми инструментами редактирования кода в среде Eclipse,
необходимо в ABAP-системе активировать ряд ICF-сервисов. Это делается с помощью транзакции
SICF. Как правило, данная задача также выполняется администраторами SAP Basis. Перечень
необходимых сервисов приведён в разделе 3 «Activating ICF Services in Development Systems»
указанного выше официального гайда.

2.2. ABAP Development Tools: общие сведения,

инсталляция
2.2.1 Общие сведения
ABAP Development Tools (ADT) – это инструментарий для работы с ABAP CDS, реализованный в
среде Eclipse. Разумеется, возникает вопрос – почему для работы с новыми ABAP-объектами не
используется классический SAP GUI? Переход к работе в Eclipse имеет ряд преимуществ. ADT в
Eclipse позволяет использовать общее удобство и гибкость Eclipse, сохраняя при этом и
преимущества традиционных функций из ABAP Workbench. ADT объединяет в себе лучшие
стороны обеих сред разработки. ADT повышает производительность разработчиков, предлагая
улучшенную функциональность рефакторинга, завершение кода, шаблоны кода. ADT обеспечивает
удобную навигацию. Работа в локально установленном ПО Eclipse позволяет застраховать
разработку от аварийных потерь связи с сервером. Клиент Eclipse поддерживает возможность
соединения с несколькими BackEnd-системами, работать с их кодом одновременно, быстро и
удобно переключаясь. Поиск и просмотр всех CDS-объектов организованы унифицированно, через
стандартный инструмент Project Explorer. Использование интегрированной среды разработки
(Integrated Development Environment, IDE) позволяет создавать кросс-платформенные разработки,
объединяя ABAP и не-ABAP объекты. В частности, ADT можно интегрировать с разработками в
SAP UI5 и JAVA.

Рассматривается только установка ADT на компьютерах под управлением операционных систем

Windows 7-10 (как 32, так и 64-битной архитектуры).
Прежде чем начинать установку ADT, необходимо установить несколько вспомогательных
программ:

 SAP GUI версии не ниже 7.40. Это ПО обеспечивает коммуникацию с ABAP BackEnd
 Java Runtime (JRE) 1.8. Необходима версия 32 или 64-bit в соответствии с разрядностью
Windows. Ссылки на текущие версии JRE находятся по адресу
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
 Microsoft VC Runtime. Необходимо установить пакет библиотек MS VS2010, также 32 или 64
бита в соответствии с разрядностью Windows

Инсталляция ADT может проходить двумя  способами, в зависимости от того, имеет ли

пользователь доступ к загрузке ПО SAP с сайта https://launchpad.support.sap.com/ (для этого
необходимо иметь специальный логин, так называемый S-User). При наличии такого доступа
удобнее использовать специальную версию среды Eclipse, которую можно загрузить с этого сайта.
Эта версия называется SAP HANA Studio. Альтернативный вариант инсталляции ADT – через
общедоступный дистрибутив среды Eclipse. В следующих подразделах описаны оба способа
установки как самой среды Eclipse, так и ADT в этой среде.

2.2.2 Установка среды Eclipse

Необходимо скачать дистрибутив среды Eclipse, свободно доступный на сайте http://www.eclipse.org
Традиционно один раз в году, в июне, выпускается новый релиз, получающий свой номер и
условное название. На момент написания данного текста текущим является релиз версии 4.7
Oxygen. Важно: во время установки и обновления необходимо действующее подключение к
интернету! Программа установки на старте предлагает выбрать один из нескольких вариантов,
отличающихся набором инсталлируемых компонент. Можно выбрать первый вариант из списка
(см. Рис.14).

Рис.14. Первый шаг установки Eclipse

Далее процесс установки проходит стандартно: принять лицензионное соглашение, выбрать папку
для установки. При первом запуске программа предложит выбрать папку для сохранения локальных
рабочих файлов (workspace). Нужно выбрать удобную папку, например – предложенную по
умолчанию. И включить галку «Use this as default and do not ask again» (см. Рис.15).
Рис.15. Настройка Workspace при первом запуске Eclipse

В открывшемся рабочем окне среды Eclipse перейти по меню Window->Preferences. Появится окно
всевозможных настроек. В левой части выбрать пункт Install/Update->Available Software Sites (см.
Рис.16).

Рис.16. Настройка доступа Eclipse к сайтам обновлений

В этом меню можно управлять источниками, по которым происходит поиск обновлений или новых
компонент для установки. Источниками могут быть сайты проекта Eclipse или локальные файлы
дистрибутивов. К тем источникам, которые указаны по умолчанию, необходимо добавить источник
для установки ADT. Для этого нажать кнопку «Add…» и в поле «Location» добавить адрес
https://tools.hana.ondemand.com/oxygen (см. Рис.17).
Рис.17. Подключение нового сайта обновлений к Eclipse

Подтвердить адрес кнопкой «OK» и закрыть настройки кнопкой «Apply and Close». Теперь можно
запустить проверку и установку обновлений среды Eclipse через меню Help->Check for Updates.
Если в указанных источниках будут найдены обновления, программа выведет их список. Возможно,
для продолжения установки потребуется принять лицензионные соглашения. После чего пойдёт
автоматический процесс загрузки и установки требуемых файлов. По завершении этого процесса
появится сообщение о том, что необходим перезапуск программы (см. Рис.18).

Рис.18. Подтверждение успешного обновления Eclipse

Для продолжения нормальной работы нужно принять это предложение и нажать «Restart Now».

2.2.3 Установка ADT в среде Eclipse

Для установки ADT требуется предварительно установить несколько дополнительных компонент.
Процесс установки одинаков для всех, поэтому рассмотрим его на примере первой компоненты,
которая называется «EMF Edit Data Binding». В окне Eclipse нужно выбрать пункт меню Help-
>Install New Software (см. Рис.19).
Рис.19. Установка дополнительных компонент в Eclipse – стартовое окно

В поле, где по умолчанию написано «type filter text», ввести название нужного компонента. Для
удобства просмотра результатов рекомендуется отключить галку «Group items by category». Затем в
верхней части окна раскрыть выпадающий список в поле «Work with» и выбрать из него «All
Available Sites». Рекомендуется выбирать эту настройку после предыдущих, так как выбор сайтов
немедленно запускает поиск по ним. И если не ввести заранее название компонента, то поиск будет
долгим и выдаст огромный список лишних пунктов. А при рекомендованной последовательности
результат будет таким, как показано на Рис.20. Здесь и далее на рисунках отражены версии
компонент, актуальные на момент написания текста. Пользователь, применяющий описанные
рекомендации, может увидеть более свежие версии.

Рис.20. Установка дополнительных компонент в Eclipse – результат поиска

Остаётся пометить галкой требуемый пункт «EMF Edit Data Binding». После этого в нижней части
окна станет доступна кнопка «Next». Далее установка проходит как обычно, включая окно с
принятием лицензионного соглашения и перезапуск программы.

По такому алгоритму требуется установить следующие компоненты:

 EMF Edit Data Binding

 EMF Model Query
 EMF Model Transaction Workbench Integration
 EMF Validation Framework
 Graphiti (Incubation)
 Mylyn Commons
 Mylyn Task-Focused Interface
 Web Services Tools
 Graphical Editing Framework Zest Visualization Toolkit

Если какая-то из компонент не появляется в результатах поиска, попробуйте отключить галку «Hide
items that are already installed». Тогда искомый компонент может появиться, отображённый серым
цветом (см. Рис.21).

Рис.21. Проверка ранее установленных компонент Eclipse

Это значит, что компонент уже установлен и не нуждается в обновлении.

После установки всех предварительных пакетов, в окне поиска нужно вновь включить галку «Group
items by category» ввести название компонента «ABAP Development Tools». Результат показан на
Рис.22.
Рис.22. Установка ADT – стартовое окно

Теперь нужно или выбрать верхний компонент, или просто нажать кнопку «Select All». И далее
пройти по обычному пути установки.

Чтобы убедиться в корректной установке, можно сделать следующее. Во-первых, нужно вывести в
верхней части рабочего окна набор кнопок (toolbar). Если его там нет, то сначала выполнить
команду меню Window->Appearance->Show Toolbar. Теперь появится кнопочное меню. В том числе
кнопка «Open Perspective» (см. Рис.23).

Рис.23. Кнопка выбора и включения различных перспектив в Eclipse

Если  установка ADT прошла правильно, то при нажатии на данную кнопку появится список, в
котором будет указана перспектива ABAP (см. Рис.24).
Рис.24. Включение ABAP-перспективы в среде Eclipse

Для дальнейшей работы с ADT нужно выбрать эту перспективу и нажать Open. В кнопочном меню
появится кнопка «ABAP» (крайняя справа на Рис.25):

Рис.25. Переход к работе в ранее включённой ABAP-перспективе

Окно «Welcome» заслоняет почти всё рабочее пространство. Поэтому нужно закрыть его, нажав
крестик на заголовке. В результате текущим станет как раз окно ABAP (см. Рис.26).
Рис.26. Рабочий вид ABAP-перспективы

Окно «Feature Explorer» в правой части экрана тоже не потребуется для работы, оно представляет
только вводную информацию для начинающих. Его также можно закрыть.

2.2.4 Установка  SAP HANA Studio

Этот вариант рекомендуется для тех пользователей, которые имеют доступ к загрузке ПО с портала
https://launchpad.support.sap.com/. И при этом компания, в которой работает пользователь, имеет
лицензию на SAP HANA. Тогда вместо среды Eclipse удобнее использовать её специально
доработанную версию, называемую SAP HANA Studio. Важное преимущество этого продукта в
том, что он обновляется синхронно с выпуском новых ревизий самой SAP HANA. Поэтому всегда
можно установить именно ту версию Studio, которая соответствует используемой HANA-системе.

Для установки HANA Studio потребуется скачать её дистрибутив а также специальную программу-
архиватор, используемую только компанией SAP. Это так называемый SAPCAR. Найти архиватор
можно следующим образом. В верхней части web-страницы выбрать из списка раздел Downloads и
ввести слово SAPCAR в поле поиска (см. Рис.27).

Рис.27. Поиск архиватора SAPCAR на официальном портале SAP

Затем нажать Enter или кнопку поиска . Формируются результаты поиска. Нас интересует
строка, в которой написано «Maintenance Software Component» (см. Рис.28).

Рис.28. Результаты поиска архиватора SAPCAR

Перейдя по этой ссылке, видим, что текущей версией программы SAPCAR является 7.21 (см.
Рис.29).

Рис.29. Результат поиска текущей версии SAPCAR

Войдя в данный раздел, выбираем из выпадающего списка подходящую версию операционной

системы. И получаем ссылку на exe-файл для скачивания (см. Рис.30).

Рис.30. Дистрибутив текущей версии SAPCAR для ОС Windows

Рекомендуется скачать этот файл в отдельную папку. Например, C:\Studio. И переименовать для
удобства просто в SAPCAR.EXE.

Теперь ищем дистрибутив для самой SAP HANA Studio. Так же вносим это название в поле поиска
(см. Рис.31).
Рис.31. Поиск дистрибутива SAP HANA Studio

В результатах поиска ищем строку, где указан продукт «SAP HANA STUDIO 2» с пояснением
«Maintenance Software Component» (см. Рис.31a).

Рис.31a. Результаты поиска SAP HANA Studio – строка с текущей версией ПО

Перейдя по ссылке, так же выбираем из списка подходящую версию Windows. И в данном случае
мы получим довольно большой список различных доступных версий для скачивания (см. Рис.32).

Рис.32. Дистрибутивы SAP HANA Studio для ОС Windows и различных ревизий HANA

Какой из этих файлов выбрать? Если предполагается работа с системой на основе SAP HANA, то
лучше всего уточнить у администраторов SAP Basis, какая ревизия HANA используется в вашей
системе. И скачать версию Studio с таким же номером ревизии. Например – 223.00. Загруженный
файл помещаем в ту же папку C:\Studio. Для удобства его тоже можно переименовать в
STUDIO2.SAR (см. Рис.33).

Рис.33. Архиватор SAPCAR и дистрибутив HANA Studio загружены на компьютер пользователя

Поскольку архиватор SAPCAR не имеет windows-интерфейса, то придётся управлять им через

командную строку. Для этого нажать «Пуск->Выполнить» и ввести команду cmd (см. Рис.34).
Рис.34. Запуск командной строки в Windows

Открывается командная строка (см. Рис.35).

Рис.35. Командная строка Windows (здесь Master – имя текущего пользователя ОС)

Теперь нужно переключиться в ту папку, в которой лежат дистрибутивы. Это делается командой cd
с указанием требуемой папки. После ввода команды и нажатия Enter командная строка
переключится в нужную папку. Это будет видно по заголовку строки (см. Рис.36).

Рис.36. Командная строка переключена на работу с файлами в папке C:\Studio

Теперь можно набирать непосредственно команду по распаковке архива с дистрибутивом HANA

Studio. Архиватор SAPCAR имеет много различных дополнительных опций для своей работы. Но
здесь для простоты наберём команду, которая означает распаковку файла STUDIO2.SAR в текущую
папку: SAPCAR.EXE -xvf STUDIO2.SAR (см. Рис.37).
Рис.37. Команда распаковки архива с дистрибутивом HANA Studio

После нажатия Enter начнётся распаковка архива. В зависимости от производительности

компьютера, она может занять до минуты. Сообщения об окончании распаковки выглядят как на
Рис.38.

Рис.38. Итог распаковки дистрибутива HANA Studio

В результате распаковки в папке C:\Studio появляется вложенная папка SAP_HANA_STUDIO,

содержащая уже привычный для пользователей Windows дистрибутив программы (см. Рис.39).

Рис.39. Готовый к установке дистрибутив HANA Studio

Программа установки HANA Studio запускается через файл hdbsetup.exe. Возможно, что для его
корректной работы от пользователя потребуются полномочия администратора на данном
компьютере. В остальном процесс установки типичен для приложений Windows. В частности, на
экране выбора устанавливаемых опций нужно выбрать все доступные галочки (см. Рис.40).

Рис.40. Выбор компонент во время инсталляции HANA Studio

После окончания установки в меню «Пуск» появляется папка «SAP HANA» с ярлыком для запуска
HANA Studio.

После установки необходимо проверить наличие обновлений и установить несколько

дополнительных компонентов. Это делается так же, как описано выше для среды Eclipse. Только
список дополнительных компонентов здесь короче:

 EMF Model Query

 Graphiti (Incubation)
 Mylyn Commons
 Mylyn Task-Focused Interface
 Web Services Tools

2.2.5 Установка ADT в  SAP HANA Studio

Дистрибутив ADT также загружается с портала SAP. Для этого в строке поиска нужно ввести
«ABAP in Eclipse» (см. Рис.41).
Рис.41. Поиск дистрибутива ADT на официальном портале SAP

Так же необходимо перейти по строке, содержащей пометку «Maintenance Software Component». На

момент написания данного текста, текущая версия ADT имеет номер 2.89 (см. Рис.42).

Рис.42. Результат поиска текущей версии ADT

Дистрибутив состоит из одного файла в формате ZIP. Сложностей с выбором здесь нет, так как
версия только одна и от операционной системы она не зависит (см. Рис.43).

Рис.43. Файл с дистрибутивом текущей версии ADT

Файл нужно просто сохранить, не распаковывая. Например, в ту же папку C:\Studio. Затем, в

настройках HANA Studio нужно добавить ещё один источник для поиска обновлений. Это делается
так же, как ранее описано для среды Eclipse. Но теперь это уже не ссылка на сайт, а путь к
загруженному нами архиву. Архив выбирается нажатием кнопки «Archive…» (см. Рис.44).
Рис.44. Добавление локального файла как источника для обновлений в HANA Studio

Здесь можно видеть префикс jar:file перед названием файла. Это нормально, система добавляет его
автоматически, когда с помощью кнопки «Archive…» выбран нужный файл.

В остальном процедура установки ADT такая же, как и в среде Eclipse.

2.3. Конфигурирование подключения ADT к Backend-системе

Здесь предполагается, что соответствующая система ABAP BackEnd (например, система S/4HANA)
уже доступна для SAP GUI, то есть внесена в список систем SAP Logon. Между средой Eclipse и
программой SAP HANA Studio нет различий в процессах подключения к Backend и работы с CDS.

Подключение ADT к системе BackEnd выполняется в перспективе ABAP. Для того, чтобы хранить
параметры подключения и локальные файлы со служебной информацией, требуется создать так
называемый ABAP-проект. Для этого в левой части ABAP-перспективы выбрать закладку Project
Explorer (см. Рис.45).

Рис.45. ABAP-перспектива, Project Explorer

Создать проект можно двумя способами. Либо выполнить пункт меню File->New->ABAP Project,
либо правой кнопкой мыши вызвать контекстное меню на пустом свободном месте в Project
Explorer. И там тоже выполнить New->ABAP Project (см. Рис.46).
Рис.46. Создание ABAP-проекта в ADT. Первый шаг

В открывшемся окне будут перечислены те системы, которые созданы в SAP Logon (см. Рис.47).

Рис.47. Системы и параметры соединения с ними автоматически скопированы в ADT из SAP

Logon

Следует выделить нужную систему и нажать кнопку «Next». В следующем окне будут видны
подробные настройки соединения с ABAP-системой, считанные из SAP Logon. При необходимости
их можно скорректировать (см. Рис.48).
Рис.48. Создание ABAP-проекта в ADT. Параметры подключения к Backend-системе

Затем ещё раз нажать «Next». В следующем окне ввести обычные параметры для входа в систему,
как и при работе в SAP Logon: логин, пароль, мандант и язык  (см. Рис.49).

Рис.49. Системы Создание ABAP-проекта в ADT. Ввод параметров пользователя

Затем ещё раз нажать «Next». Будет выполнена проверка соединения с ABAP-системой,
корректность пароля и полномочия указанного пользователя. Если всё пройдёт успешно, то
появится завершающее окно. В нём можно будет скорректировать (если нужно) предложенное
системой техническое имя проекта. Например, иногда бывает удобно убрать из имени логин
пользователя и язык подключения. А также добавить суффикс ABAP (так как в Project Explorer
могут создаваться и проекты других типов). Пример приведён на Рис.49
Рис.50. Создание ABAP-проекта в ADT. Завершающий этап

Здесь же удобной опцией является выбор избранных пакетов разработки (Favorite Packages). Дело в
том, что все доступные пользователю ABAP-пакеты будут видны в проекте в виде иерархического
дерева. Если полномочия пользователя широки, то число доступных пакетов может быть огромным.
И тогда ориентироваться в этом дереве долго и неудобно. Поэтому некоторые пакеты, с объектами
которых наиболее часто приходится работать, можно сделать избранными. Такие пакеты выводятся
отдельным компактным списком. Для целей дальнейших примеров можно добавить в избранное
пакет $TMP. Для этого нажать кнопку «Add» и ввести имя пакета (или его часть) в строку поиска.
Будет выведен список всех пакетов, чьё техническое имя содержит введённую строку (см. Рис.51).

Рис.51. Создание ABAP-проекта в ADT. Выбор избранных пакетов разработки

Следует выделить подходящий пакет и нажать «ОК». Разумеется, возможность добавлять и удалять
пакеты в список избранных сохраняется и при дальнейшей работе с проектом.

Теперь процесс создания ABAP-проекта завершается нажатием кнопки «Finish» (см. Рис.52).

Рис.52. Создание ABAP-проекта в ADT. Результат привязки избранных пакетов

Созданный проект появляется в Project Explorer. Поскольку при создании были введены логин и
пароль, то соединение с BackEnd-системой уже установлено. Поэтому пиктограмма проекта имеет
вид раскрытой папки (см. Рис.53).

Рис.53. Готовый ABAP-проект в Project Explorer

Иерархию объектов, доступных для работы, можно раскрывать и далее, используя либо значки >
слева от строк иерархии, либо двойной щелчок мышью. Например, можно раскрыть и увидеть
список избранных пакетов (см. Рис.54).
Рис.54. Избранные пакеты разработки в ABAP-проекте

Здесь также видны такие параметры подключения проекта, как SID системы, мандант 001, логин
пользователя (VVV), язык подключения. Соответственно, объекты пакета $TMP тоже выводятся те,
которые ассоциированы с этим пользователем.

Когда работа с системой закончена, необходимо правой кнопкой щёлкнуть на папке проекта и
выбрать в контекстном меню команду Close Project. Это аналог привычной команды выхода из
системы в SAP GUI. При следующем входе в Project Explorer папка проекта будет выглядеть
закрытой (см. Рис.55).

Рис.55. Вид ABAP-проекта, когда соединение с Backend-системой разорвано

При двойном щелчке по папке появится окно, требующее ввести пароль (см. Рис.56).

Рис.56. Повторное соединение в Backend-системой при входе в ABAP-проект

Важно заметить, что здесь требуется только ввод пароля. Такие параметры, как номер
манданта, логин и язык входа – фиксируются в процессе создания проекта и не могут
быть изменены. Это, в частности, связано с тем, что некоторые настроечные данные
проекта сохраняются на компьютере локально. Поэтому они должны быть неизменны и
доступны только правильному пользователю.

2.4. Подготовка данных для демонстрационных

примеров
В последующих разделах данной публикации будут приведены примеры создания различных CDS-
ракурсов. В конечном итоге эти ракурсы образуют небольшую пользовательскую VDM. Все
примеры основаны на широко известном наборе таблиц, часто используемом в упражнениях по
ABAP-программированию. Этот набор часто называю по имени его основной таблицы – SFLIGHT.
Данные в этих таблицах отражают вымышленный бизнес по организации пассажирских
авиаперевозок. Таблицы заполняются условными данными о расписании рейсов и бронировании
билетов, справочником авиакомпаний и типов воздушных судов и т.п. Изначально после установки
ABAP-системы все эти таблицы не содержат данных. Для заполнения необходимо запустить
специальную программу, генерирующую условные данные. Техническое имя программы -
SAPBC_DATA_GENERATOR. Выполнять программу, разумеется, необходимо в той же системе и в
том же манданте, к которому подключён созданный ранее ABAP-проект.

При непосредственном запуске программы через транзакцию SA38, выводится стартовый экран
(см. Рис.57).

Рис.57. Стартовый экран программы SAPBC_DATA_GENERATOR

Основным параметром при запуске программы является объем данных (число записей), которые
будут сгенерированы при заполнении таблиц. Для целей тестирования, конечно, интереснее иметь
достаточно большие массивы данных. Как указано на стартовом экране, массивы размеров
«Maximum» и «Monster» могут быть созданы только через запуск программы в фоновом режиме.
Для фонового запуска в системе уже предусмотрены стандартные варианты:

• SAP&BC_MINI: Minimum dataset, no logging

• SAP&BC_STD: Standard dataset, no logging

• SAP&BC_MAX: Maximum dataset, no logging

• SAP&BC_MONSTER: Monster dataset, no logging

Запустить программу в фоновом режиме с одним из этих вариантов можно через транзакцию SM36.
Подробности создания, запуска фонового задания и мониторинга его исполнения здесь не
приводятся, так как это типичная общеизвестная задача.
Практика освоения ABAP CDS для непрограммистов. Часть 3

Виталий Васильев
Прочитать позже
1130

Часть 1  Часть 2

Продолжение статьи.
3. АННОТАЦИИ

3.1. Общие определения

3.2. Примеры аннотаций

4. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ. БАЗОВЫЕ РАКУРСЫ

4.1. Таблицы демонстрационной модели

4.2. Создание базового ракурса

4.2.1 Создание DDL Source с помощью мастера

4.2.2 Доработка шаблонного кода: заголовок и аннотации

4.2.3 Доработка шаблонного кода: список полей ракурса

4.2.4 Активация DDL Source. Предварительный просмотр данных

4.2.5 Доработка шаблонного кода: завершающие шаги

4.3. Дополнительные базовые ракурсы демонстрационной модели

4.4. Демонстрационная модель: ракурс использования

4.5. Общие рекомендации и требования к написанию DDL Source

3. АННОТАЦИИ
3.1. Общие определения
Аннотации – это команды, имеющие специфический синтаксис и используемые в DDL-источниках
для описания дополнительной семантической информации. Например, аннотации помогают
организовать большую модель, выделить в ней различные уровни элементов: частные, повторно
используемые, аналитические.
Совокупность доступных для использования аннотаций предопределена SAP. Она содержит ABAP-
аннотации, используемые средой во время выполнения, определяющие семантику и поведение
CDS-сущности. Также предусмотрены аннотации, необходимые для работы в других средах (таких
как OData или UI5). Метаданные таких аннотаций доступны приложениям-потребителям через
специальные API (см. Рис.58).

  Рис.58. Группы аннотаций (домены)

    Перевод картинки:

 Analytics – Аналитика
 Search – Поиск
 BI-Tools – Приложения BI
 Planning – Планирование
 Business Logic – Бизнес-логика

Аннотации разбиты на группы (домены) в соответствии с областями их использования. Метаданные

из аннотаций определённого домена позволяют передать в него дополнительную информацию, не
меняя модели данных. Каждый домен, обращаясь к CDS, анализирует только «свои» аннотации,
игнорируя сведения из остальных, предназначенных другим доменам.

3.2. Примеры аннотаций

Код любой аннотации всегда начинается со специального символа @

Приведём примеры наиболее распространённых аннотаций, которые используются в описании

большинства CDS-ракурсов:

 @AbapCatalog - это аннотации, предназначенные для использования в ABAP-словаре. В

частности, аннотация @AbapCatalog.sqlViewName является обязательной для всех CDS-
ракурсов. Она определяет имя ракурса в ABAP-словаре. Иными словами, это то техническое
 имя, под которым ракурс можно будет найти в транзакциях SE11/SE12. Синтаксис
аннотации таков:

@AbapCatalog.sqlViewName: ‘<SQL VIEW NAME>’

 Аннотации VDM описывают предназначение ракурса в рамках виртуальной модели. Этими

аннотациями определяются те самые типы ракурсов, которые описаны ранее.

Например, аннотация @VDM.private: TRUE означает, что это частный ракурс,

являющийся внутренним объектом, предназначенным для преодоления каких-то
технических ограничений ABAP-модели данных. Использование этой аннотации в
пользовательских разработках не допускается за исключением случаев, когда
разработчик берёт создаваемый объект на поддержку.

 @VDM.viewType: #BASIC - пример аннотации, определяющей принадлежность

ракурса к определённому уровню VDM. В соответствии с определениями, данными в
главе 1, возможны следующие значения этой аннотации:

 #BASIC – Базовый ракурс, самый низкий уровень VDM. Как уже говорилось, это
единственный уровень, на котором допустимо прямое обращение к таблицам БД при
определении ракурса. Базовые ракурсы почти всегда представляют собой неизбыточную
нормализованную модель данных
 #COMPOSITE – Композитный ракурс. Определяется на основе нескольких базовых или
других композитных ракурсов. Здесь зачастую не требуется нормализация данных. Более
приоритетной является возможность повторного использования композитных ракурсов, их
адаптация под специфические области данных и под удобное сочетание с другими
ракурсами.
 #CONSUMPTION – Ракурсы использования. Они потребляют ракурсы с нижележащих
уровней, но сами не предназначены для повторного использования. Задача таких ракурсов –
обеспечить информацией приложения-потребители VDM.
 #EXTENSION – Ракурс расширения. Содержит ключевое поле и все дополнительные поля,
используемые при расширении стандартной VDM.

 Аналитические аннотации. Используются OLAP-движком для агрегации данных. Также

необходимы для использования ракурсов в FrontEnd-программах SAP BusinessObjects BI,
таких как Design Studio (в новых версиях переименован в Lumira Designer) и Analysis Office.

@Analytics.dataCategory: #FACT – пример аннотации, определяющей категорию

данных, описываемых в ракурсе, с точки зрения аналитических приложений.
Возможные значения этой аннотации:

 #DIMENSION – Ракурс с такой категорией данных содержит основные данные, включая их

взаимосвязи с атрибутами, текстами и иерархиями. Для OLAP-движка этот ракурс
представляет собой измерение. Может также использоваться как самостоятельный источник
данных для аналитики.
 #FACT – Ракурс описывает транзакционные данные. Потому ожидается, что он будет
содержать хотя бы одно поле-показатель. Представляет данные в нормализованной форме.
Как правило не используется для аналитики напрямую, а поставляет данные в более
сложные модели.
 #CUBE – Ракурс представляет данные в традиционной схеме «звезда». То есть
транзакционные данные и их взаимосвязи со всеми со всеми справочниками (основными
данными). Содержит все измерения и все поля, по которым возможна группировка данных (в
 том числе навигационные атрибуты). Ракурс-куб описывается на основе строго одного
ракурса типа #FACT плюс не менее чем одного ракурса вида #DIMENSION
 #AGGREGATIONLEVEL – Специфический вид ракурса, предназначенный для приложений
планирования, допускающих ручной ввод данных пользователем. Здесь подробно не
рассматривается.

Таблица 1 кратко иллюстрирует различия между этими категориями данных:

Таблица 1. Аналитические категории данных

 Analytics.query: blank (=true), true, false  - «Истинное» значение данной аннотации указывает,
что ракурс предназначен для обработки аналитическим движком. Этот движок может
обрабатывать такие специфические конструкции, как ограниченные показатели, формулы и
показатели со специальной агрегацией. Как правило, ракурсы вида query строятся на основе
ракурса категории #CUBE. Ракурсы вида query являются ракурсами потребления и не имеют
никакой категории данных. Более точно, для таких ракурсов необходимо использовать
аннотацию @Analytics.dataCategory = #NONE
 Analytics.dataExtraction.enabled: true, false – Аннотация указывает: может ли ракурс быть
использован для экстракции (как источник данных для BW).

 Аннотации ObjectModel используются для описания структурных и транзакционных свойств

бизнес-модели. Например, если значения в каком-то поле должны выбираться только из
списка, описываемого в другом ракурсе. Ещё один пример – это аннотация
@ObjectModel.dataCategory. Если упомянутая выше аннотация @Analytics.dataCategory:
#DIMENSION указывала на то, что ракурс содержит основные данные из справочника, то
@ObjectModel.dataCategory сообщает, что ракурс содержит зависящий от языка текст к
справочнику (значение #TEXT) или внешнюю иерархию (значение #HIERARCHY).
 Помимо аннотаций, определяющих свойства ракурса в целом, существуют и аннотации,
определяющие семантику отдельных полей ракурса. Такие аннотации всегда вставляются в
текст описания ракурса непосредственно перед названием соответствующего поля (когда 
идёт перечисление полей  в операторе SELECT). Аннотации полей используются для
корректной обработки данных движками. Некоторые примеры аннотаций полей:
o @Semnatics.unitOfMeasure: true – Поле содержит указание единицы измерения (в
связке с другим числовым полем-показателем)
o @Semnatics.currencyCode: true – Поле содержит указание валюты (в связке с другим
числовым полем-показателем)
o @Semantics.quantity.unitOfMeasure: <UOMField> - Поле представляет собой
количество (числовой показатель). Единица измерения этого количества содержится в
 поле <UOMField>. Таким образом, поле, описываемое данной аннотацией, всегда
идёт в связке с полем, описанным аннотацией @Semnatics.unitOfMeasure
o @Semantics.amount.currencyCode: <CurrencyField> - Поле представляет собой
денежную сумму (числовой показатель). Валюта, в которой указана эта сумма,
содержится в поле <CurrencyField>. Таким образом, поле, описываемое данной
аннотацией, всегда идёт в связке с полем, описанным аннотацией
@Semnatics.currencyCode
o @DefaultAggregation: #SUM, #MAX, etc.– Аннотация указывает способ агрегации
описываемого числового поля.
o @Semantics.text: true - Аннотация указывает, что описываемое поле содержит текст,
то есть объект, выводимый на экран для улучшения восприятия информации
человеком. Данный объект не является предметом аналитической обработки.
 Аннотации авторизаций (полномочий на доступ к данным). Пример:
@AccessControl.authorizationCheck: #NOT_REQUIRED или #CHECK. Значение #CHECK
указывает, что необходима проверка полномочий с помощью средств DCL. В
демонстрационных примерах ниже будет использоваться настройка #NOT_REQUIRED,
означающая отключённую проверку полномочий.

Некоторые другие аннотации будут описаны при построении демонстрационных примеров, так как
там можно более наглядно пояснить предназначение этих аннотаций. Общее число аннотаций,
доступных в синтаксисе CDS, очень велико. Полный их перечень может меняться в зависимости от
версии используемой ABAP-системы. Однако большинство аннотаций доступны во всех версиях.
Полный справочник доступных аннотаций на примере SAP Netweaver 7.5 SPS10 можно найти по
ссылке.

4.    ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ.

БАЗОВЫЕ РАКУРСЫ
4.1. Таблицы демонстрационной модели
Как уже говорилось в п. 2.4, основой для построения демо-примеров служит традиционная схема из
нескольких таблиц, содержащих условную информацию о бронировании авиаперевозок. А именно,
будут использованы следующие таблицы:

 SCARR – Основные данные авиакомпаний

 SAPLANE – Основные данные моделей воздушных судов
 SAIRPORT – Основные данные аэропортов
 SPFLI – Расписание авиарейсов
 SFLIGHT – Список авиарейсов

4.2. Создание базового ракурса

4.2.1 Создание DDL Source с помощью мастера

Простейшим примером для начала послужит создание базового ракурса, описывающего основные
данные авиакомпаний. Он будет основан на таблице SCARR. Как можно видеть в транзакции SE12,
таблица содержит двухсимвольные коды авиакомпаний, их текстовые названия, коды валют,
используемых компаниями по умолчанию, и адреса их веб-сайтов (см. Рис.59).
Рис.59. Содержимое таблицы SCARR

Чтобы создать CDS-ракурс, необходимо открыть ADT (в среде Eclipse или в SAP HANA Studio) и
соединиться с BackEnd-системой, раскрыв папку ABAP-проекта (см. Рис.54).

Затем необходимо выбрать пакет разработки, в котором будет создан ракурс. Это может быть пакет,
ранее внесённый в список избранных для удобства. Либо можно раскрыть полный список
доступных пакетов System Library.

Правой кнопкой вызвать контекстное меню выбранного пакета. Выбрать команду New->Other
ABAP Repository Object (см. Рис.60).

Рис.60. Начало создания DDL-источника: команда меню

В открывшемся окне найти папку Core Data Services и выбрать в ней объект типа Data Definition
(см. Рис.61).
Рис.61. Выбор типа создаваемого объекта

Нажать кнопку «Next». В следующем окне можно выбрать пакет разработки, в котором будет
создан ракурс (по умолчанию там указан пакет, на котором мы выше вызывали контекстное меню),
указать техническое имя ракурса и его текстовое название (см. Рис.62).

Рис.62. Мастер создания DDL Source: указание имени объекта

В рассматриваемой демонстрационной VDM соблюдается следующее соглашение о

наименованиях:

 Технические имена интерфейсных ракурсов (Interface) начинаются с префикса

ZI_
 Технические имена ракурсов потребления (Consumption) начинаются с префикса
ZC_

Укажем значения как на Рис.63.

Рис.63. Техническое имя и название создаваемого ракурса

Затем снова нажимаем «Next». В следующем окне предлагаются опции, позволяющие включить
создаваемый ракурс в ранее созданный транспортный запрос, либо создать новый запрос (см.
Рис.64).

Рис.64. Мастер создания DDL Source: выбор транспортного запроса

В нашем примере все эти опции неактивны, так как работа идёт в пакете $TMP, объекты из
которого никуда не переносятся. Снова нажимаем «Next». Следующее окно предложит
использовать при создании ракурса один из предустановленных шаблонов (см. Рис.65).
Рис.65. Мастер создания DDL Source:выбор шаблонного кода

Вверху слева указан список шаблонов. При выборе любого шаблона вверху справа появится его
краткое описание. А в нижней части окна можно видеть тот код, который по умолчанию будет
вписан из шаблона в создаваемый DDL Source. Для начального примера достаточно использовать
простейший шаблон Define View и нажать «Finish». В результате будет создан ракурс с выбранным
техническим именем, откроется окно для редактирования кода этого ракурса и в это окно будут
вписаны строки из выбранного шаблона (см. Рис.66).

Рис.66. Создание DDL Source: код, скопированный из шаблона

4.2.2 Доработка шаблонного кода: заголовок и

аннотации
Слева от закрывающей фигурной скобки на  Рис.66 видна пиктограмма (красный кружок с белым
крестом), говорящая о наличии синтаксических ошибок. На данном этапе это естественно, так как
код из шаблона ещё нужно отредактировать под наши нужды.

После оператора define view следует имя ZI_AIRLINE. По терминологии, описанной в разделе 1.1,
это техническое имя для CDS View, который будет создан при активации данного DDL Source. По
умолчанию это имя совпадает с именем самого DDL Source.

Вместо текста data_source_name необходимо указать имя таблицы, из которой ракурс будет
получать данные. Для этого можно воспользоваться такой удобной функцией редактора в ADT, как
Code Completion. Выделяем текст data_source_name и нажимаем сочетание клавиш CTRL+SPACE.
Система, анализируя код, сама «понимает», что в данном месте текста нужно указать имя таблицы.
И предлагает выбор из списка доступных таблиц (см. Рис.67).

Рис.67. Использование Code Completion для выбора исходной таблицы базового ракурса

Разумеется, весь список таблиц слишком велик. Чтобы сократить поиск, можно начать набор имени
нужной таблицы. При каждом изменении набранного текста список в Code Completion будет
обновляться, в нём останутся только те названия, которые содержат набранный нами набор
символов. Например, если набрать «scar», то останутся только две таблицы (см. Рис.68).

Рис.68. Результаты контекстного поиска в Code Completion

Остаётся выбрать из этого списка таблицу scarr и нажать сочетание клавиш SHIFT+ENTER , чтобы
вписать название в DDL-код. Разумеется, в данном примере можно было сразу вписать это название
таблицы, не прибегая к Code Completion. Но важно знать о такой функции, так как в дальнейшем ей
удобно пользоваться, особенно при заполнении аннотаций, которых много и их трудно запомнить.

Теперь посмотрим на аннотации, которые были автоматически добавлены в начало DDL-кода из

шаблона. В первую очередь необходимо вместо текста sql_view_name в аннотации
@AbapCatalog.sqlViewName указать техническое имя ракурса, под которым он будет виден в
ABAP-словаре. По терминологии, описанной в разделе 1.1, это техническое имя для SQL View,
который будет создан при активации данного DDL Source. Длина имени в ABAP-словаре должна
быть не более 16 символов. Поэтому, если возможно, будем использовать для SQL View то же имя,
что и в DDL Source, но без символов подчёркивания. Результат показан на Рис.69.

Рис.69. Аннотация указывает имя для SQL View

После того, как источник данных указан, можно обратить внимание на левую нижнюю часть
рабочего окна (под списком Project Explorer). Это так называемый Outline (см. Рис.70).

Рис.70. Окно Outline

Данный инструмент анализирует код текущего DDL Source и в удобной графической форме
отображает все его элементы: источники данных, взаимосвязи с другими ракурсами и таблицами
(ассоциации) и прочие элементы. На данный момент отображается только одна таблица-источник.
Однако при работе со сложными ракурсами, где много кода, использование Outline удобно для того,
чтобы увидеть общий обзор устройства ракурса. А также для навигации по коду. Например, если
выполнить двойной щелчок по источнику scarr в окне Outline, то курсор автоматически
переместится в соответствующее место кода и выделит источник (см. Рис.71).

Рис.71. Результат навигации по коду из Outline

Ещё одна удобная опция, привычная для многих программистов – это нумерация строк в редакторе
кода. Если она выключена, то нужно в любом месте редактора вызвать контекстное меню правой
кнопкой мыши. И выбрать команду Preferences. В открывшемся окне включить следующую галку
«Show line numbers» (см. Рис.72).
Рис.72. Опция нумерации строк в редакторе DDL-кода

4.2.3 Доработка шаблонного кода: список

полей ракурса
Теперь нужно перечислить поля, которые войдут в состав ракурса. Они указываются через запятую
в блоке между фигурными скобками. В нашем случае шаблон оставил для этого удобную пустую
шестую строчку (см. Рис.73).

Рис.73. Фигурные скобки указывают место для списка полей в коде ракурса

Устанавливаем курсор в начало этой строки и вновь вызываем Code Completion нажатием
CTRL+SPACE. В этот раз система «видит», что мы описываем выборку из таблицы scarr, причём по
синтаксису в этом месте должен быть список полей. Именно его нам и предлагают (см. Рис.74).

Рис.74. Использование Code Completion для заполнения списка полей в ракурсе

Выбираем поле carrid и нажимаем SHIFT+ENTER. Поле будет вставлено в DDL-код.

Распространённый приём в SQL – использование псевдонимов (aliases) для выбираемых полей. При
определении CDS-ракурсов этот приём становится ещё более значимым. Как уже много раз
говорилось, одна из задач VDM – это представить данные пользователю в семантически
обогащённой и понятной форме. Псевдонимы очень полезны при решении такой задачи. Ведь
буквосочетание carrid ничего не говорит конечному пользователю. А название «Airline» выглядит
значительно яснее. Поэтому, добавив поле scarr.carrid, присваиваем ему псевдоним так же, как
обычно в SQL (см. Рис.75).

Рис.75. Использование псевдонима для «переименования» исходного поля

Затем через запятую включаем в выборку ещё два поля: валюту авиакомпании и её web-адрес (см.
Рис.76).

Рис.76. Полный список полей ракурса ZI_AIRLINE

4.2.4 Активация DDL Source.

Предварительный просмотр данных
На данном этапе DDL Source уже содержит код, который можно сохранить, проверить на
корректность и активировать. Соответствующие кнопки предусмотрены в верхней части рабочего
окна (см. Рис.77).

Рис.77. Кнопки сохранения, проверки синтаксиса и активации объекта

При активации в нижней части окна на закладке Problems появится предупреждение (см. Рис.78).

Рис.78. Пример информационных сообщений, возникающих при активации

Предупреждение говорит о том, что к созданному DDL Source не настроены полномочия для
доступа. Но сейчас речь идёт лишь о создании простейшего примера. Поэтому для устранения
проблемы достаточно будет указать, что проверка полномочий не требуется. Необходимую
аннотацию мы уже рассматривали ранее. Её нужно добавить в самое начало кода, например – во
вторую строку  (см. Рис.79).

Рис.79. Исключение созданного ракурса из проверок полномочий

Теперь активация кода проходит без дополнительных сообщений. При описании следующих
примеров, как правило, про активацию завершённого кода специально упоминать не будем.
Созданный DDLSource теперь отображается в Project Explorer (см. Рис.80).

Рис.80. Отображение созданного источника в Project Explorer

Через контекстное меню в окне редактора кода можно выбрать команду Open With->Data Preview
(см. Рис.81).

Рис.81. Вызов предварительного просмотра данных  CDS-ракурса

Такой просмотр позволит проконтролировать отображение данных с учётом всех указанных

аннотаций и псевдонимов полей (см. Рис.82).
Рис.82. Предварительный просмотр данных CDS-ракурса в ADT

В то же время, можно проконтролировать как данный ракурс виден на стороне ABAP-словаря. Для
этого в транзакции SE11 или SE12 нужно ввести техническое имя ракурса, указанное в аннотации
@AbapCatalog.sqlViewName (см. Рис.83).

Рис.83. Предварительный просмотр данных CDS-ракурса в SAP GUI

 После нажатия кнопки «Display» система в строке состояния выдаст вполне ясное предупреждение
(см. Рис.84).

Рис.84. Предупреждение о неполной совместимости SAP GUI и CDS-ракурсов

Eсли щёлкнуть по этому сообщению, то появится окно с подробностями, поясняющими

использование DDL в ADT. Пропустив предупреждение, увидим метаданные ракурса (см. Рис.85).
Рис.85. Описание CDS-ракурса в стандартном ABAP-инструментарии

Поле Short Description заполнено в соответствии с аннотацией «@EndUserText.label: ‘Airline’»

Имя DDL Source, код которого мы написали только что в ADT, указано в поле «DDL Source».
Технические имена полей приведены в соответствии с теми псевдонимами, какие записаны в DDL.
Но приведены к заглавным буквам, так как ABAP-словарь поддерживает только их. В то же время
элементы данных, типы данных и словесные описания полей в Short Description автоматически
подтянулись из соответствующих полей таблицы SCARR.

Здесь же есть удобная возможность увидеть SQL-код, автоматически созданный при генерации
данного ракурса. Для просмотра нужно перейти в меню Extras -> CREATE Statement (см. Рис.86).

Рис.86. Вызов просмотра SQL-кода CDS-ракурса

SQL-код будет выведен во всплывающем окне, как на Рис.87

Рис.87. Просмотр SQL-кода ракурса ZI_AIRLINE

4.2.5 Доработка шаблонного кода:

завершающие шаги
Вернёмся к редактированию DDL. Прежде всего, необходимо добавить аннотацию, указывающую
место данного ракурса в VDM. Поскольку этот ракурс является базовым, то добавляем аннотацию
VDM с типом #BASIC (см. Рис.88).

Рис.88. Уровень ракурса в иерархии VDM указан аннотацией @VDM.viewType

При написании аннотаций также можно использовать Code Completion. Сначала при выборе
аннотации, как на Рис.89

Рис.89. Использование Code Completion для указания аннотаций

Затем – при выборе значения выбранной аннотации (см. Рис.90).

Рис.90. Использование Code Completion для выбора значений аннотации

Следующая аннотация, которую следует указать – это аналитическая категория данных. В нашем
случае описан справочник, поэтому нужно указать категорию #DIMENSION (см. Рис.91).

Рис.91. Использование аннотации @Analytics.dataCategory

Однако, если теперь попытаться активировать DDL-код, то появится сообщение об ошибке (см.
Рис.92).

Рис.92. Пример ошибки при активации DDL Source

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

1. Перед каждым полем, которое входит в состав первичного ключа, вписать слово key
2. Если полей первичного ключа несколько, то необходимо выделить одно из них: то, которое
наиболее полно выражает специфику описываемого справочника. Такое поле называется
representative key. Его необходимо указать в общих (не семантических) аннотациях ракурса
через следующий синтаксис: @ObjectModel.representativeKey: ‘<Name key field>’

Например, в стандартной модели данных справочник основных счетов всегда идёт со ссылкой на
план счетов. То есть первичный ключ в таком справочнике состоит из двух полей: счёт и план
счетов. Но как правило, план счетов – это константа в рамках компании. И настоящим
информативным полем, наиболее полно отражающим специфику справочника, является счёт. Он в
этом примере и является репрезентативным ключом.

Для ракурса ZI_AIRLINE ключевое поле только одно – код авиакомпании (см. Рис.93).

Рис.93. Указание ключевого поля в CDS-ракурсе

Хотя указание репрезентативного ключа для одного ключевого поля необязательно, но в
дальнейшем он может нам пригодиться при создании так называемых ассоциаций. Поэтому укажем
так, как показано на Рис.94.

Рис.94. Указание поля репрезентативного ключа

Также для удобства возможного дальнейшего использования добавим аннотацию экстракции

данных (см. Рис.95).

Рис.95. Аннотация dataExtraction позволит извлекать данные из ракурса для BW

В заголовке DDL Source есть ещё одна не рассмотренная ранее аннотация:

@AbapCatalog.compiler.compareFilter: true

Эта аннотация будет описана ниже, после знакомства с понятиями «ассоциация» и «Path
Expression». На данном этапе в ней нет необходимости, эту строчку удаляем.

Затем добавляем две семантических аннотации к полям валюты и количества. Как уже говорилось,
семантические аннотации должны быть указаны внутри фигурных скобок (где идёт перечисление
полей) и должны быть вписаны непосредственно перед соответствующими полями. Результат
показан на Рис.96

Рис.96. Семантические аннотации для отдельных полей ракурса

Наличие семантических аннотаций отразится на пиктограммах этих полей в Outline (см. Рис.97).

Рис.97. Окно Outline графически отображает семантику, добавленную аннотациями

Итоговый код ракурса приведён на Рис.98.

Рис.98. Окончательный код ракурса ZI_AIRLINE

4.3. Дополнительные базовые ракурсы демонстрационной

модели
Для дальнейшего использования в демонстрационных примерах нам потребуются ещё два базовых
ракурса, описывающих справочник аэропортов и справочник типов воздушных судов.

Справочник аэропортов назовём ZI_AIRPORT. Он строится на основе таблицы SAIRPORT. Способ

построения ракурса остаётся прежним, поэтому приводим только итоговый код на Рис.99.

Рис.99. Код ракурса ZI_AIRPORT

Здесь использована ранее не упоминавшаяся аннотация @ObjectModel.text.element. Эта аннотация

является семантической, то есть описывает поле, указанное сразу после неё. Она указывает на
другое поле, которое является не зависящим от языка текстом для текущего поля. В данном случае
указано, что AirportName – это не зависящий от языка текст для поля Airport.

Подчеркнём, что здесь используется именно независящий от языка текст. Если же

требуется описать тексты, зависящие от языка, то для этого создаётся отдельный ракурс
с аннотацией @ObjectModel.dataCategory: #TEXT. Такое различие объясняется тем, что
 для зависящих от языка текстов в состав первичного ключа ракурса необходимо
дополнительно включить поле «язык»

Справочник типов воздушных судов назовём ZI_AIRCRAFTTYPE. В его основе – таблица

SAPLANE. Код соответствующего DDL Source приведён на Рис.100.

Рис.100. Код ракурса ZI_AIRCRAFTTYPE

4.4. Демонстрационная модель: ракурс использования

Для иллюстрации создания Fiori-приложений в дальнейшем нам потребуется простейший пример
ракурса использования. По соглашению о наименованиях, имена ракурсов использования в наших
примерах должны начинаться с префикса ZC_. Создадим новый ракурс ZC_AIRLINEQUERY. Как
говорилось в разделе 1, ракурсы использования строятся на основе предварительно подготовленных
интерфейсных ракурсов. Для данного примера будет задействован ракурс ZI_AIRLINE. Ничего
нового DDL-код ракурса не содержит, поэтому просто приведём его на Рис.101.

Рис.101. Код ракурса ZC_AIRLINEQUERY

Единственной особенностью, отличающей этот ракурс от ранее созданных, является тип ракурса
(Consumption), указанный аннотацией в строке 5.

4.5. Общие рекомендации и требования к написанию DDL

Source
Есть несколько рекомендаций и ограничений, касающихся правил наименования как DDL-
источника, так и генерируемых из него SQL View и CDS View.

DDL Source

A. Максимальная длина – 30 символов

B. Имя должно быть уникальным в пользовательском пространстве имён (т.е. среди всех имён
DDL-источников)
C. Используемые буквы – только заглавные
D. View

 Максимальная длина – 30 символов

 Имя должно быть уникальным в пользовательском пространстве имён
 Имя должно быть уникальным в ABAP-словаре (т.к. соответствует глобальному типу данных
в ABAP)
 Имя не чувствительно к регистру используемых букв
 Рекомендуется, чтобы имя CDS View совпадало с именем DDL Source

SQL View

 Максимальная длина – 16 символов, как у объекта ABAP-словаря

 Имя должно быть уникальным в пользовательском пространстве имён
 Имя должно быть уникальным в ABAP-словаре
 Имя не чувствительно к регистру (при активации DDL Source имя автоматически будет
переведено в верхний регистр)
 Имя должно отличаться от имени CDS View

Приведём также несколько общих требований к синтаксису DDL-кода:

 Ключевые слова (операторы). Должны быть набраны либо полностью в верхнем регистре,
либо полностью в нижнем, либо с заглавной буквы. Например: SELECT, select, Select.
Недопустимо использование смешанного регистра: SeLect, seleCT.
 Имена. Не чувствительны к регистру. Максимальная длина – 30 символов.
 Литералы. Числовые литералы – всегда в полной нотации, десятичный знак – точка.
Допустимо: 1 или 2.0 или 0.5  Недопустимо: .5 или 1,3. Символьные литералы набираются в
окружении апострофов: ‘LH’ или ‘0001’.
 Комментарии. Двойной слэш // обозначает, что с этого места и до конца строки следует
комментарий. Если необходимо в явном виде обозначить начало и окончание комментария
(если он вставлен в середине строки или занимает несколько строк), то используются
символы /* и */.

Практика освоения ABAP CDS для непрограммистов. Часть 4

Виталий Васильев
Прочитать позже
1218

Часть 1  Часть 2  Часть 3
Продолжение статьи.
5. АССОЦИАЦИИ, PATH EXPRESSIONS И ИХ ИСПОЛЬЗОВАНИЕ В ДЕМОНСТРАЦИОННОЙ
МОДЕЛИ

5.1. Основная идея

5.2. Простейший пример

5.3. Path Expressions

5.4. Синтаксические правила ассоциаций, сравнение с JOIN, кардинальность

5.4.1 Синтаксические правила описания ассоциаций

5.4.2 Различие между ассоциацией и оператором JOIN

5.4.3 Кардинальность ассоциаций

5.5. Аннотация @AbapCatalog.compiler.compareFilter

5.6. Развитие демонстрационной модели с помощью ассоциаций и Foreign Keys

5. АССОЦИАЦИИ, PATH EXPRESSIONS И

ИХ ИСПОЛЬЗОВАНИЕ В
ДЕМОНСТРАЦИОННОЙ МОДЕЛИ
5.1. Основная идея
Ассоциации – это элементы VDM, которые позволяют моделировать взаимосвязи между
входящими в модель сущностями (таблицами и ракурсами). Примером такой связи между двумя
таблицами является соединение их данных по общим полям, обозначаемое в SQL как операция join.
Например, в SAP ERP для различных документов (FI-проводки, поставки, заказы) данные
заголовков и данные позиций документов хранятся в отдельных таблицах. Чтобы получить полную
информацию о документе, необходимо выполнить join между таблицей заголовков и таблицей
позиций по полю «номер документа».

Идея создания ассоциаций в VDM заключалась в том, чтобы не просто отразить такие взаимосвязи,
но и сделать их частью модели данных, вписать их в метаданные CDS-ракурсов и тем самым
обеспечить их повторное использование. Ассоциация описывается в каком-то CDS-ракурсе один
раз, и там ей может быть присвоен псевдоним (alias). А все последующие сущности, использующие
этот ракурс, могут просто ссылаться на ассоциацию по присвоенному псевдониму. Как говорилось,
VDM строится иерархически, снизу вверх, в несколько уровней. Таким же образом «вырастают»
один из другого и CDS-ракурсы: базовые, композитные, ракурсы использования. В этом смысле
соотношения между ракурсами можно представить себе как древовидный граф. Тогда ассоциации –
это рёбра графа, так как они отражают взаимосвязи между вершинами. Приложение-потребитель
имеет дело с ракурсами использования, то есть  с самой «вершиной» такого дерева. От вершины
древовидного графа можно спуститься, переходя от одной вершины к другой по связующим их
рёбрам, до самых нижних вершин. Таким же образом и повторное использование ассоциаций
позволяет получать информацию с самого нижнего уровня VDM без повторного явного
«прописывания» всех полей на каждом уровне модели. Такое повторное прописывание хорошо
знакомо тем, кто имеет опыт создания HANA Calculation Vews. Подчас такая работа становится
утомительной и рутинной. А изменение HANA-модели на нижнем уровне требует тщательного
контроля всех вышележащих уровней, так как целостность модели нарушается. Использование
ассоциаций в VDM значительно упрощает эти аспекты моделирования. И в этом существенное
отличие и преимущество ассоциаций по сравнению с обычными операциями join. Хотя и эти
последние тоже могут использоваться в DDL.

5.2. Простейший пример

Продолжим создание демонстрационной модели. На простейшем примере легче всего
проиллюстрировать синтаксис создания ассоциаций.

В предыдущих разделах создан ракурс ZI_AIRLINE, представляющий собой основные данные из

справочника авиакомпаний, таблицы SCARR. Как ракурс-справочник он имеет категорию данных
#DIMENSION. Но та же таблица, помимо основных данных, содержит и тексты – названия
авиакомпаний. Определим интерфейсный ракурс ZI_AIRLINETEXT, как показано на Рис.102.

Рис.102. Код ракурса ZI_AIRLINETEXT

Большинство использованных аннотаций уже описаны ранее. Как отмечалось, аннотация

@ObjectModel.dataCategory: #TEXT используется при создании ракурсов, содержащих зависящие от
языка тексты. Для таких ракурсов в число ключевых полей добавляется явно описанное поле
«язык». Здесь это поле указано в строке 11 с соответствующей аннотацией в строке 10. Но
поскольку в таблице SCARR такого поля нет, то строки 10-11 закомментированы. Они включены в
данный пример только для иллюстрации возможности создания текстов, зависящих от языка. Также
можно отметить, что аннотация @EndUserText.label: 'Airline Name' использована дважды. На уровне
DDL-источника в целом (строка 3) она задаёт словесное название ракурса. А перед полем carrname
(строка 13) эта же аннотация указывает, что при просмотре данных ракурса это поле будет видно
под заголовком «Airline Name».

Итак, у нас есть ракурсы ZI_AIRLINE и ZI_AIRLINETEXT. Чтобы максимально упростить первый
пример ассоциации, оба ракурса используют только одну таблицу SCARR и имеют одинаковые
ключевые поля Airline, идущие из исходного поля carrid. Ракурс ZI_AIRLINE  содержит основные
данные, поэтому при создании ассоциации он является источником (source entity). А ракурс
ZI_AIRLINETEXT  присоединяется к источнику через ассоциацию, то есть является целью
ассоциации (target entity). Ассоциация описывается после названия источника данных и перед
открывающей фигурной скобкой с перечислением полей (см. Рис.103).

Рис.103. Определение ассоциации ракурсов ZI_AIRLINE и ZI_AIRLINETEXT

Здесь в квадратных скобках указана так называемая кардинальность ассоциации, то есть возможное
количество записей в target entity, соответствующих одной записи в source entity. Подробнее о
кардинальности сказано далее.

В качестве псевдонима (alias) для присоединяемой ассоциации указано имя _Text. Начинать
псевдоним ассоциации с нижнего подчёркивания – это рекомендуемая практика. Она позволяет
избежать путаницы (случайного совпадения) между названиями полей и названиями ассоциаций.

В строке 10 вместо имени source entity использовано служебное слово $projection. Это также
стандартный элемент DDL-синтаксиса. Его назначение описано далее.

Слева от строки 9 видна пиктограмма – желтый треугольник с восклицательным знаком. Это

предупреждение. Его текст всплывает, если подвести указатель мыши к пиктограмме (см. Рис.104).

Рис.104. Просмотр сообщения с предупреждением в коде DDL Source

Здесь подразумевается, что ассоциация не используется в числе полей, выбираемых оператором

SELECT и перечисленных внутри фигурных скобок. Далее этот список полей будем называть
SELECT-лист. Чтобы устранить данное предупреждение, можно просто включить в  SELECT-лист
всю ассоциацию целиком (в строке 17). См. Рис.105.

Рис.105. Публикация ассоциации для возможности её повторного использования

Уже было отмечено, что ассоциации позволяют передавать данные по иерархии ракурсов VDM
«снизу вверх» без детального прописывания и перечисления отдельных полей. И данный пример
иллюстрирует эту возможность. Вместо всех полей, входящих в ракурс ZI_AIRLINETEXT, указан
только псевдоним соответствующей ассоциации. Теперь все ракурсы, которые будут использовать
ZI_AIRLINE, смогут также задействовать и поля из ZI_AIRLINETEXT, ссылаясь на них по
псевдониму ассоциации. В следующем разделе это будет более детально проиллюстрировано при
разборе понятия Path Expressions.

Отметим, как созданная ассоциация отразилась в Outline (см. Рис.106).

Рис.106. Графическое отражение ассоциаций в Outline

Также Outline позволяет определить список других ракурсов, использующих текущий ракурс.
Чтобы узнать это, нужно в Outline правой кнопкой мыши вызвать контекстное меню на
техническом имени ракурса. И выбрать команду «Get Where-used List». На примере
ZI_AIRLINETEXT это показывает Рис.107

Рис.107. Поиск ракурсов, использующих текущий ракурс

В результате в нижней части окна SAP HANA Studio на закладке Search появится список ракурсов,
использующих текущий ракурс. И будет указано, каким именно способом используется текущий
ракурс. Например – является целью ассоциации, или является источником, из которого выбираются
поля в SELECT-лист. В нашем примере будет показано, что ракурс ZI_AIRLINE использует
ZI_AIRLINETEXT в качестве target entity для ассоциации (см. Рис.108).

Рис.108. Результат поиска по Where-Used List

5.3. Path Expressions

В описанном выше примере определена ассоциация _Text. И она включена в SELECT-лист.

Создавая иерархическую VDM, можно продолжать последовательное определение ассоциаций на

каждом новом вышестоящем уровне. Представим себе такую картину:
 1. В ракурсе VIEW1 определена ассоциация _Assoc1. В составе таблицы, присоединённой к
VIEW1 через эту ассоциацию, есть ряд полей, например – поле element. Ассоциация _Assoc1
включена в SELECT-лист полей ракурса.
2. Определён ракурс VIEW2, к которому с помощью ассоциации _Assoc2 присоединён ракурс
VIEW1. При этом ассоциация _Assoc2 также опубликована в SELECT-листе ракурса VIEW2
3. Определен ракурс VIEW3, к которому с помощью ассоциации _Assoc3 присоединён ракурс
VIEW2. Ассоциация _Assoc3 опубликована в SELECT-листе ракурса VIEW3.

Теперь перед нами стоит задача: получить в ракурсе VIEW3 значение поля element и вписать его
отдельно в SELECT-лист ракурса. Это можно сделать с помощью следующего
выражения:_Assoc3._Assoc2._Assoc1.element

Использованный в этом примере приём DDL-синтаксиса, перечисляющий цепочку

последовательных ассоциаций, называется Path Expression. В примере длина цепочки составила три
ассоциации. На практике, разумеется, их может быть как больше, так и меньше. Простейшим
примером для Path Expression является использованное ранее в демонстрационном примере
включение одиночной ассоциации _Text в SELECT-лист ракурса ZI_AIRLINE.

Цепочка Path Expression может оканчиваться как отдельным полем (как в приведённом примере),
так и ассоциацией. При этом действуют следующие правила:

 Если окончанием цепочки является поле, то это должно быть поле из target entity в
последней ассоциации цепочки.
 Если окончанием цепочки является ассоциация, то её роль определяется тем местом в DDL-
источнике, где использована цепочка. При использовании цепочки в SELECT-листе
конечная ассоциация становится элементом этого листа. Она будет доступна для
использования в последующих CDS-ракурсах. Именно это происходит с ассоциацией _Text в
SELECT-листе ракурса ZI_AIRLINE.
 Если окончанием цепочки является ассоциация, а при этом сама цепочка перечислена после
оператора FROM, то такая ассоциация считается источником (target или source).
 DDL-синтаксис, определяющий ракурсы, использует OpenSQL. Поэтому в DDL Source,
помимо оператора FROM или SELECT-листа могут использоваться и традиционные SQL-
конструкции с операторами WHERE или HAVING. По самому смыслу таких операторов, в
них должны быть описаны только ограничения на отдельные поля. Поэтому использовать
Path Expression после WHERE или HAVING можно только при условии, что цепочка
заканчивается отдельным полем.

В демонстрационном примере использован простейший случай Path Expression с одной ассоциацией

_Text. Теперь приведём пример из официальной документации SAP, демонстрирующий
значительно более широкие и гибкие возможности применения ассоциаций и Path Expressions.
Вначале определим ракурс sales_order с ассоциацией _note_header:

@AbapCatalog.sqlViewName: 'SALES_ORDER_VW' 
define view sales_order as 
  select from snwd_so 
         association [0..1] to snwd_text_key as _note_header 
           on $projection.note_guid = _note_header.node_key 
  { * }

Использование символа * в последней строке означает, что в SELECT-лист вошли все поля обеих
таблиц, включённых в ассоциацию.
Следующий ракурс присоединяет sales_order к таблице snwd_bpa:

@AbapCatalog.sqlViewName: 'BPA_VW' 
define view business_partner as 
  select from snwd_bpa 
         association [0..*] to sales_order as _sales_order 
           on $projection.node_key = _sales_order.buyer_guid 

  { * }

Наконец, третий ракурс использует эти две ассоциации, а также определяет ещё одну:

@AbapCatalog.sqlViewName: 'SALESO_INV_VW' 
define view invoice as 
  select from 
         business_partner._sales_order[ 
           lifecycle_status <> 'C' and lifecycle_status <> 'X'] 
           as bpa_so
         association [0..1] to snwd_so_inv_head as _invoice_header 
           on $projection.node_key = _invoice_header.so_guid 
        { key bpa_so.node_key,
              bpa_so.so_id, 
              bpa_so.note_guid,
              bpa_so.lifecycle_status, 
              _invoice_header.dunning_level, 
              bpa_so._note_header } 
          where _invoice_header.dunning_level > '0'

В этом ракурсе использованы следующие приёмы:

1. Ассоциация _sales_order вызвана через ракурс business_partner с помощью Path Expression

2. Ассоциация _sales_order вызвана с добавлением к ней дополнительных условий фильтрации
по полю lifecycle_status
3. Для полученного в результате пп.1-2 источника назначен псевдоним bpa_so
4. Определена новая ассоциация _invoice_header
5. SELECT-лист содержит поле bpa_so.node_key, входящее в условие «ON» ассоциации
_invoice_header. Также в лист включено поле bpa_so.note_guid, входящее в условие «ON»
ассоциации _note_header. Прямое перечисление ON-полей в SELECT-листе является
необходимым условием при использовании ассоциаций (см. следующий раздел).
6. Ассоциация _invoice_header не опубликована в SELECT-листе полностью, то есть не может
быть использована в последующих ракурсах. Из этой ассоциации взято только поле
dunning_level
7. В операторе WHERE использован Path Expression с ассоциацией _invoice_header. Как сказано
выше, в таком случае Path Expression обязан заканчиваться отдельным полем, на которое и
действует условие WHERE.

5.4. Синтаксические правила ассоциаций, сравнение с JOIN,

кардинальность
5.4.1 Синтаксические правила описания
ассоциаций
Теперь можно более строго описать правила, по которым должны быть описаны ассоциации.
Определение ассоциации содержит: источник (source entity), цель (target entity), кардинальность,
псевдоним ассоциации и условие ассоциации (ON condition).

 Источником и целью могут быть таблица базы данных, определённая в ABAP-словаре, или
другой CDS-ракурс
 В процессе активации CDS-ракурса, использующего path expression, соответствующие
ассоциации компилируется в операцию join (присоединение) между источником и целью.
При этом ON-condition из ассоциации переходит в ON-condition присоединения. Вид 
присоединения зависит от того в каком месте DDL-источника упомянут path expression: если
после оператора FROM, то будет inner join; в остальных случаях – left outer join (в котором,
разумеется,  source entity расположен слева). Вид присоединения может быть переопределён,
если указать его явно. Например, если в SELECT-листе перечисляется поле assocfield из
ассоциации _assoc, то синтаксис _assoc.assocfield  приведёт к генерации left outer join.
Переопределить это в Inner join можно синтаксисом _assoc[inner].assocfield
 Поля из source entity, включённые в ON-condition, необходимо упоминать с использованием
в качестве префикса служебного слова $projection, а не с собственным именем source entity.
Необходимость использования специального служебного слова вызвана тем, что
определение ассоциации происходит до перечисления в SELECT-листе всех полей,
выбираемых в состав текущего CDS-ракурса. Но при этом определение ассоциации
использует поля SELECT-листа. Такое «опережающее» указание полей оформляется через
ссылку на SELECT-лист с помощью слова $projection.
 Все поля из source entity, включённые в ON-condition, необходимо в явном виде перечислить
в SELECT-листе. Это обеспечивает возможность построения упомянутой выше операции
join в момент компиляции DDL-кода.
 Поля из target entity, включённые в ON-condition, необходимо упомянуть с именем
ассоциации в качестве префикса.
 Использование псевдонима (alias) для присоединяемой ассоциации не является
обязательным, хотя и настоятельно рекомендуется для удобства дальнейшего понимания
кода и использования ассоциации в path expression. Если псевдоним не задан, то система по
умолчанию использует вместо него имя target entity.

5.4.2 Различие между ассоциацией и

оператором JOIN
При первом знакомстве с синтаксисом определения ассоциаций возникает естественный вопрос: в
чём отличие ассоциаций от привычных по синтаксису SQL операций join? В чём смысл
придумывать ещё одно аналогичное понятие? Можно указать следующие отличия ассоциаций от
операций join:

 Синтаксис ассоциаций упрощает чтение и понимание логики определения CDS-ракурса

 Ассоциации допускают повторное использование в виде path expressions, что невозможно в
конструкциях, которые построены на операторах JOIN.
  Если ассоциация определена, но не использована в path expression, то при активации такого
CDS-ракурса не генерируется операция join. Таким образом, генерируемый SQL-код
получается более гибким и оптимальным.

5.4.3 Кардинальность ассоциаций

В приведённых ранее примерах ассоциаций использовалось понятие «кардинальность».
Кардинальность – это вытекающее из модели данных возможное количество записей в target entity,
которые могут соответствовать одной записи из source entity. Кардинальность – это только
предварительная оценка соотношения между source и target, она не проверяется в момент
исполнения кода. Синтаксис ассоциаций предполагает указывать кардинальность в квадратных
скобках. Внутри скобок через две точки указываются минимальная и максимальная оценки для
кардинальности: [min..max]. В качестве значений параметров min и max могут служить: число 0,
любое натуральное число, символ *. При этом:

 Символ * означает любое (неограниченно большое) число

 В качестве значения max не может быть указан 0
 В качестве значения min не может быть указан символ *
 Значение min можно не указывать (в этом случае оно по умолчанию будет взято равным 0)
 Если кардинальность не указана, она по умолчанию считается равной [0..1]

5.5. Аннотация @AbapCatalog.compiler.compareFilter

Данная аннотация очень часто встречается в примерах CDS-ракурсов. Фактически, она по
умолчанию входит в список аннотаций, с которых начинаются все DDL-определения ракурсов.
Однако описанию назначения аннотации почти не уделяется внимания. И даже в официальной
документации SAP пояснения даны довольно невнятно.

DDL-определение ракурса может несколько раз использовать одну и ту же ассоциацию, ссылаясь на

неё с дополнительными условиями фильтрации. Выше приведён пример такой фильтрации при
использовании ассоциации _sales_order с фильтром по полю lifecycle_status. Аннотация
@AbapCatalog.compiler.compareFilter влияет на то, каким образом такие условия фильтрации
преобразуются в SQL-код при компиляции DDL-определения. Если указать аннотацию
@AbapCatalog.compiler.compareFilter: true, то все условия фильтрации будут сравниваться. И для
всех совпадающих условий ассоциации будут объединены в одну операцию join. Если же
аннотацию не задавать, то каждая ассоциация порождает отдельный join при компиляции DDL в
SQL. И это происходит независимо от того, использованы ли в нескольких ассоциациях одинаковые
фильтры или нет.

На словах указанные правила звучат сложно иабстрактно, поэтому проще будет проиллюстрировать
их примерами. Возьмем описанный выше ракурс ZI_AIRLINE и создадим его копию с техническим
именем ZI_ASSOC_TEST. Код нового ракурса модифицируем таким образом, чтобы в нём дважды
вызывалась одна и та же ассоциация _Text с одинаковым фильтром по коду авиакомпании (см.
Рис.109).
Рис.109. DDL Source для тестирования аннотации compareFilter

Здесь ассоциация использована в строках 17 и 18, причём оба раза установлен фильтр на код
авиакомпании ‘AA’. Также в строке 17 для поля _Text.Airline создан псевдоним, так как поле Airline
уже есть в строке 12.

Аннотации @AbapCatalog.compiler.compareFilter в ZI_ASSOC_TEST нет. Посмотрим, как двойной

вызов ассоциации скомпилировался в SQL-код. Как это можно сделать – уже показывалось ранее.
Полученный SQL-код показан на Рис.110.

Рис.110. Пример SQL-кода при отсутствии аннотации compareFilter

Как было сказано ранее, без аннотации @AbapCatalog.compiler.compareFilter каждая ассоциация

превращается в отдельный join. В нашем примере строка 17 из DDL-кода превратилась в left outer
join с текстовым ракурсом ZI_AIRLINETEXT под псевдонимом A0. А строка 18 превратилась в
отдельный left outer join с тем же ракурсом, но под псевдонимом A1.
Теперь изменим DDL-код ракурса ZI_ASSOC_TEST, добавив аннотацию
@AbapCatalog.compiler.compareFilter: true. Результат показан на Рис.111.

Рис.111. DDL Source с добавленной аннотацией compareFilter

Здесь включённая аннотация «заставляет» компилятор сравнивать оба условия фильтрации в

строках 18 и 19. И поскольку эти условия совпадают, то оба вызова ассоциации _Text
компилируются в один left outer join. Полученный SQL-код показан на Рис.112.

Рис.112. Пример SQL-кода при включённой аннотации compareFilter

Очевидно, что полученный код лучше, чем первый вариант без использования аннотации. Второй
вариант кода не только легче читать и понимать, но он также и более оптимален при исполнении.

Таким образом, при использовании ассоциаций и path expressions рекомендуется всегда указывать
аннотацию @AbapCatalog.compiler.compareFilter: true

5.6. Развитие демонстрационной модели с помощью

ассоциаций и Foreign Keys
Используя ранее созданные базовые ракурсы проиллюстрируем, как с помощью ассоциаций можно
создать достаточно сложный элемент VDM. Основой нового ракурса станут данные из таблицы
SPFLI. Эта таблица содержит информацию о расписании авиарейсов. В новом ракурсе мы увидим
некоторые возможности семантического обогащения данных из ERP-таблиц, имеющиеся в арсенале
CDS.

Создадим новый DDL Source с техническим именем ZI_FLIGHTCONNECTION. В начале ракурса

указываем несколько уже знакомых типовых аннотаций: имя ракурса в ABAP-словаре, словесное
название ракурса, категорию данных, и т.д. (см. Рис.113).
Рис.113. Аннотации в заголовке ракурса ZI_FLIGHTCONNECTION

Как уже говорилось, основой нового ракурса становится таблица SPFLI (см. Рис.114).

Рис.114. Указание исходной таблицы ракурса ZI_FLIGHTCONNECTION

В фигурных скобках перечислим поля этой таблицы, которые войдут в SELECT-лист. Ключевые
поля – те же два, что и в исходной таблице. И сразу укажем семантически понятные названия этих
полей вместо технических имён (см. Рис.115).

Рис.115. SELECT-лист ракурса ZI_FLIGHTCONNECTION

В SELECT-листе есть такие поля как CARRID (код авиакомпании), AIRPFROM (аэропорт вылета),
AIRPTO (аэропорт назначения). Ранее мы уже создали базовые ракурсы ZI_AIRLINE (справочник
авиакомпаний) и ZI_AIRPORT (справочник аэропортов). Поэтому здесь у нас появляется
возможность семантически обогатить данные таблицы SPFLI с помощью дополнительных сведений
из этих справочников. При этом справочник ZI_AIRPORT потребуется дважды: как для аэропорта
вылета, так и для аэропорта назначения. Все эти взаимосвязи определяются с помощью ассоциаций
между соответствующими полями SELECT-листа и репрезентативными ключами справочников
(см. Рис.116).

Рис.116. Семантическое обогащение ракурса ZI_FLIGHTCONNECTION с помощью ассоциаций

Ключ нашего ракурса состоит из двух полей. При этом поле Airline имеет ассоциацию с другим
ракурсом, содержащим детальную информацию об авиакомпаниях. А вот поле FlightConnection
никаких дополнительных уточнений не имеет, информация о рейсах даётся именно в текущем CDS-
ракурсе. То есть как раз это поле является наиболее информативно значимым ключевым полем.
Поэтому, а также для возможности дальнейшего использования в ассоциациях, сразу указываем
репрезентативный ключ (см. Рис.117).

Рис.117. Указание репрезентативного ключа ракурса ZI_FLIGHTCONNECTION

Теперь в конец SELECT-листа нужно добавить перечисление трёх созданных ассоциаций, чтобы
они в дальнейшем могли быть использованы в path expressions (см. Рис.118).

Рис.118. Публикация ассоциаций в SELECT-листе

В описании таблицы SPFLI можно видеть, что поле DISTANCE – это числовая величина, для
которой требуется обязательно указывать единицу измерения. Причём в данном случае единица
измерения содержится в той же таблице, в поле DISTID (см. Рис.119).

Рис.119. Связь между числовым полем таблицы и единицей измерения в ABAP-словаре

Необходимо ту же самую информацию указать и в коде ракурса. Для этого используются уже
описанные ранее семантические аннотации (см. Рис.120).

Рис.120. Связь между числовым полем таблицы и единицей измерения в DDL Source
Если теперь активировать созданный ракурс, то около четвёртой строки появится пиктограмма
информационного сообщения (см. Рис.121).

Рис.121.Информационное сообщение в коде DDL Source

Увидеть текст сообщения можно, если навести курсор мыши на пиктограмму. Либо можно
прочитать этот текст в нижней части окна SAP HANA Studio, на закладке Problems (см. Рис.122).

Рис.122. Просмотр информационного сообщения из DDL Source

На самом деле это тот же момент, который уже обсуждался при выборе поля, являющегося
репрезентативным ключом. Таким полем является FlightConnection. А второе ключевое поле
ракурса – это как раз Airline. Поскольку оно не является репрезентативным, то рекомендуется его
детализацию представить в другом ракурсе через ассоциацию. И такая ассоциация _Airline у нас
уже есть. Поэтому нужно просто «сказать системе», что именно _Airline и детализирует данные по
ключевому полю Airline. Такое указание делается с помощью семантической аннотации
@ObjectModel.foreignKey.association (см. Рис.123).

Рис.123. Использование аннотации @ObjectModel.foreignKey.association

Таким же образом можно дать и уточнения для имеющихся ассоциаций аэропортов вылета и
прибытия.

Аннотация @ObjectModel.foreignKey.association является семантической, то есть применяется к

определённому полю из SELECT-листа. Назначение аннотации -  указать на связь этого поля с
другим CDS-ракурсом, который содержит список значений (справочник) этого поля. Сама связь
определяется через ассоциацию, имя которой и указывается после данной аннотации. Внешние
ключи (Foreign Keys) позволяют при создании Fiori-приложений на основе ракурса использовать
ассоциированные ракурсы как средства контекстного поиска в соответствующих полях. То есть
средства, аналогичные поиску по кнопке F4, привычному для всех пользователей в ABAP-
транзакциях.

Окончательный код ракурса ZI_FLIGHTCONNECTION приведён на Рис.124.

Рис.124. Код ракурса ZI_FLIGHTCONNECTION

В заключение данного раздела подчеркнём, что ракурс ZI_FLIGHTCONNECTION имеет тип

#BASIC, так как его SELECT-лист основан на таблице БД. А поскольку эта таблица является
описанием основных данных для перечня авиарейсов, то ракурс имеет категорию данных
#DIMENSION, несмотря на наличие агрегируемого числового поля Distance.

Практика освоения ABAP CDS для непрограммистов. Часть 5

Виталий Васильев
Прочитать позже
707

Часть 1  Часть 2  Часть 3  Часть 4
Заключение.
6. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ: БАЗОВЫЙ И КОМПОЗИТНЫЙ КУБЫ

6.1. Базовый куб

6.2. Композитный куб

6.2.1 Основные элементы кода

6.2.2 Расширение SELECT-листа с помощью Path Expressions

6.2.3 Семантическое обогащение ракурса с использование ассоциаций

6.2.4 Тестирование данных композитного ракурса

7. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ: РАКУРС ИСПОЛЬЗОВАНИЯ

7.1 Создание аналитического ракурса

7.2 Указание строк и столбцов отчёта. Создание фильтров для селекционного экрана. Создание
расчётного показателя

7.3 Тестирование аналитического ракурса

8. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ: ИТОГ

6. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ:
БАЗОВЫЙ И КОМПОЗИТНЫЙ КУБЫ
6.1. Базовый куб
Продолжим построение демонстрационного примера. Теперь нам требуется создать ракурс
ZI_FLIGHT, использующий не основные, а транзакционные данные о конкретных авиарейсах, их
датах, количествах и суммах произведённых бронирований. Эти данные содержатся в таблице
SFLIGHT. Данные требуется обогатить информацией из основных данных: авиакомпании, типы
воздушных судов, авиарейсы. Ракурс, в котором таблица транзакционных данных обогащается
присоединением ряда справочников должен относиться уже к категории данных #CUBE. И это
несмотря на то, что в качестве таблицы фактов используется таблица БД, а не другой ракурс
категории #FACT. Кроме того, новый ракурс уже не будет использован как справочник в
последующих ракурсах нашей модели. Итак, категория данных для нового ракурса – это #CUBE.
Тем не менее, ракурс основан на таблице БД, поэтому он должен быть определён как базовый.
Учитывая всё сказанное, создадим новый ракурс, указав в его заголовке набор аннотаций как на
Рис.125.
Рис.125. Аннотации в заголовке ракурса ZI_FLIGHT

Аннотация @AbapCatalog.compiler.compareFilter здесь не используется, так как не предполагается

наличия фильтров.

Указываем, что источником данных для ракурса является таблица SFLIGHT (см. Рис.126).

Рис.126. Указание исходной таблицы ракурса ZI_FLIGHT

Добавляем поля из этой таблицы в SELECT-лист. Сразу присваиваем этим полям семантически
удобные имена. И указываем ключевые поля, соответствующие ключу таблицы SFLIGHT (см.
Рис.127).

Рис.127. SELECT-лист ракурса ZI_FLIGHT

Чтобы обогатить транзакционные данные с помощью основных, используем ранее созданные

ракурсы категории #DIMENSION. Добавим их с помощью ассоциаций к полям AirLine,
FlightConnection и AircraftType (см. Рис.128).

Рис.128. Семантическое обогащение ракурса ZI_FLIGHT с помощью ассоциаций

Отметим, что ассоциация с ZI_FLIGHTCONNECTION идёт сразу по двум полям, так как в этом
ракурсе два ключевых поля.
Не забываем сразу же включить эти ассоциации в SELECT-лист (см. Рис.129).

Рис.129. Публикация ассоциаций в SELECT-листе ракурса ZI_FLIGHT

Указывать репрезентативный ключ не требуется, так как мы работаем уже не с основными

данными.

Всё что остаётся теперь – это добавить семантические аннотации к полям SELECT-листа. Все эти
аннотации уже знакомы и разбирались ранее: это указание на способ агрегации и на единицы
измерения числовых полей, на поля, являющиеся единицами измерения. Поля, соответствующие
денежным суммам, измеряются в валюте суммы. А поля, подсчитывающие количество мест в
самолёте, не имеют никаких единиц измерения. Также мы снова используем аннотации
@ObjectModel.foreignKey.association для «прикрепления» основных данных как средств поиска к
полям SELECT-листа. Итоговый код ракурса ZI_FLIGHT показан на Рис.130.
Рис.130. Код ракурса ZI_FLIGHT

6.2. Композитный куб

6.2.1 Основные элементы кода

Теперь в нашей демонстрационной модели завершено создание ракурсов, формирующих базовый
слой, то есть использующих напрямую данные из таблиц БД. Сформированы ракурсы с основными
данными из справочников. Сформирован базовый куб с транзакционными данными. Следующим
этапом развития модели является построение композитных ракурсов.

Как уже говорилось, уровень композитных ракурсовнужен для адаптации базовых ракурсов под
специфические области данных, для организации взаимного сочетания базовых ракурсов. Поэтому
слой композитных ракурсов образует промежуток между базовыми ракурсами в основании VDM и
ракурсами использования «на вершине» VDM. Базовые ракурсы строятся таким образом, чтобы
исключить или хотя бы минимизировать избыточность данных. Ракурсы использования, напротив,
должны представить максимально широкий набор данных, так как этот набор будет источником
информации для приложений-потребителей. Таким образом, прослойка из композитных ракурсов
должна осуществить это преобразование и составить из нескольких базовых ракурсов максимально
расширенный набор данных.

В нашем примере исключение избыточности выражается в том, что ракурсы

ZI_FLIGHTCONNECTION и ZI_FLIGHT имеют полностью различные поля в SELECT-листах (за
исключением пары ключевых полей AirLine и FlightConnection). Теперь требуется построить
композитный ракурс, представляющий все возможные поля. Поскольку он будет содержать в своей
основе транзакционные данные, то это должен быть ракурс категории #CUBE. Техническое имя
нового DDL-источника будет ZI_FLIGHTBYAIRPORT. Исходя из сказанного, в заголовке нового
ракурса потребуются следующие аннотации, показанные на Рис.131.

Рис.131. Аннотации в заголовке ракурса ZI_FLIGHTBYAIRPORT

Аннотация @Analytics.dataExtraction.enabled в данном примере исключена, так как мы формируем

избыточный набор данных, а требования к экстракции, как правило, таковы, что избыточность и
дублирование должны быть исключены.

Источником данных будет ракурс, содержащий транзакционную информацию (см. Рис.132).

Рис.132. Указание источника данных ракурса ZI_FLIGHTBYAIRPORT

В данном ракурсе не потребуется определять какие-либо ассоциации, так как все необходимые
ассоциации уже были заданы в ракурсах базового уровня. И поскольку они были опубликованы там
в соответствующих SELECT-листах, то могут быть повторно использованы в новом ракурсе
благодаря функциональности path expressions.

Теперь можно упростить формирование SELECT-листа следующим образом. Необходимо

установить курсор на строку 9 и нажать CTRL+SPACE, вызвав Code Completion (см. Рис.133).
Рис.133. Быстрое заполнение SELECT-листа с помощью Code Completion

В открывшемся списке выбрать «Insert all elements». Таким образом, в SELECT-лист будут
автоматически добавлены все поля из ракурса ZI_FLIGHT. Причём уже с семантически понятными
именами, которые были в нём определены. Более того, будут автоматически опубликованы «по
наследству» и все ассоциации, ранее опубликованные в ZI_FLIGHT (см. Рис.134).

Рис.134. SELECT-лист, заполненный полями и ассоциациями, унаследованными от ракурса-

источника

6.2.2 Расширение SELECT-листа с помощью

Path Expressions
Мы исходим из требования предоставить для аналитических приложений максимально широкий
набор полей. Все аналитики, по которым можно будет детализировать данные в отчётах, нужно
объявить ключевыми полями. В этом есть аналогия с классическим понятием OLAP-куба, в
котором все аналитики таблицы фактов являются ключевыми полями. А согласно требованиям
синтаксиса CDS, все ключевые поля должны быть перечислены подряд в начале SELECT-листа.
Поэтому числовое поле FlightPrice перемещаем в списке ниже. А все аналитики прописываем как
ключевые поля (см. Рис.135).
Рис.135. SELECT-лист, скорректированный с учётом аналитических требований

Добавим также в список доступных аналитик поля AirportFrom и AirportTo. Этих полей нет в
ZI_FLIGHT. Но они есть в ассоциации _FlightConnection, опубликованной в ZI_FLIGHT. Поэтому
мы добавим эти поля, воспользовавшись возможностями path expressions. Под новые поля добавим
две пустых строки в SELECT-лист после поля FlightDate. Вызовем список Code Completion в первой
добавленной строке и начнём набор символов _Fl…  Появится имя нужной ассоциации (см.
Рис.136).

Рис.136. Создание Path Expression: поиск ассоциации с помощью Code Completion

Выберем это имя. Затем нужно набрать точку, после которой снова вызвать Code Completion.
Теперь уже появится список полей из SELECT-листа ассоциации _FlightConnection. В нём
выбираем нужное поле (см. Рис.137).

Рис.137. Создание Path Expression:включение в SELECT-лист поля из выбранной ассоциации с

помощью Code Completion
В начале списка Code Completion перечислены все ассоциации, которые опубликованы в
_FlightConnection. Поскольку эта ассоциация определена в ZI_FLIGHT, то смотрим код этого
ракурса и видим, что под именем _FlightConnection «скрывается» ракурс
ZI_FLIGHTCONNECTION. Поэтому здесь в начале списка Code Completion перечислены те три
ассоциации, которые есть в ZI_FLIGHTCONNECTION. Нужно учесть это и не ошибиться: добавить
не ассоциацию _AirportFrom, а именно поле AirportFrom из списка полей в _FlightConnection. Это
поле выделено на Рис.137. Аналогично добавляется поле AirportTo. После добавленных полей
нужно поставить запятые, как разделители в SELECT-листе.

Теперь в коде появляется сообщение об ошибке (см. Рис.138).

Рис.138. Ошибка в порядке ключевых полей ракурса ZI_FLIGHTBYAIRPORT

Это то условие синтаксиса CDS, о котором уже говорилось: все ключевые поля должны быть
перечислены подряд и идти в начале SELECT-листа. А наши два новых поля разрывают
последовательность ранее указанных ключевых полей. Но поскольку новые поля добавлены тоже
как будущие аналитики в отчётах, то и они должны быть объявлены ключевыми. Что сразу
устраняет ошибку (см. Рис.139).

Рис.139. Оформление списка ключевых полей ракурса ZI_FLIGHTBYAIRPORT

6.2.3 Семантическое обогащение ракурса с

использование ассоциаций
Теперь можно начать семантическое обогащение ракурса ZI_FLIGHTBYAIRPORT, добавляя
семантические аннотации к его полям. А также добавляя аннотацию
@ObjectModel.foreignKey.association ко всем возможным аналитикам (а в нашем примере
ассоциации с основными данными созданы для всех аналитик, кроме FlightDate и Currency). Все эти
аннотации уже известны и пояснений не требуют (см. Рис.140). Можно только заметить, что для
полей с денежными суммами уже не используется аннотация @Semantics.amount.currencyCode, так
как эта информация есть в исходном ракурсе ZI_FLIGHT
Рис.140. Семантическое обогащение SELECT-листа с помощью аннотаций

Дополнительно добавим аннотации с новыми названиями полей для аэропортов отправления и

прибытия (см. Рис.141).

Рис.141. Указание новых названий для пунктов отправления и назнапчения

Это полезно, чтобы избежать путаницы с аналогичными полями в ракурсе

ZI_FLIGHTCONNECTION.

Теперь при проверке и активации появляются новые ошибки (см. Рис.142).

Рис.142. Ошибки, связанные с использованием «не своих» ассоциаций

И действительно: указанные ассоциации недоступны напрямую в ракурсе ZI_FLIGHT, по которому

сформирован наш SELECT-лист. Но эти две ассоциации определены в ракурсе
ZI_FLIGHTCONNECTION, доступном из ZI_FLIGHT через ассоциацию _FlightConnection. Чтобы
устранить данную ошибку, достаточно в явном виде опубликовать нужные ассоциации в нашем
SELECT-листе. Возможности path expressions делают это элементарным (см. Рис.143).

Рис.143. Повторное использование (публикация) ассоциаций через Path Expressions

Нужно отметить, что таким способом мы не только устранили ошибку. Но и опубликовали

ассоциации _AirportFrom и _AirportTo для дальнейшего использования напрямую из ракурса
ZI_FLIGHTBYAIRPORT. То есть теперь, если мы в каком-то новом ракурсе будем формировать
SELECT-лист из ZI_FLIGHTBYAIRPORT, то эти  две ассоциации будут доступны напрямую, без
добавления промежуточного path expression (такого как _FlightConnection). Пример показан на
Рис.144

Рис.144. Возможность прямого использования повторно опубликованных ассоциаций

При этом никакого нового определения ассоциаций не требуется, все определения наследуются из
ранее сделанных.

На этом подготовка кода для ракурса ZI_FLIGHTBYAIRPORT завершена, его можно сохранить и
активировать.

6.2.4 Тестирование данных композитного

ракурса
Построенный композитный куб нельзя протестировать с помощью обычных аналитических
программ, формирующих отчёты для пользователей. Это объясняется тем, что этим программам в
качестве источника данных требуется аналитический запрос (см. описание аннотации
@Analytics.query). Однако, данный композитный ракурс можно протестировать в SAP GUI с
помощью транзакции RSRTS_ODP_DIS. На стартовом экране транзакции указываем для параметра
ODP Context значение «ABAP Core Data Services». В поле ODP Name вставляем SQL-имя
тестируемого ракурса. То есть то имя, которое задано аннотацией @AbapCatalog.sqlViewName (см.
Рис.145).

Рис.145. Запуск транзакции RSRTS_ODP_DIS

После этого выполнение транзакции покажет описание ракурса, которое может быть полезно для
разработчика аналитических отчётов. Например, для полей ракурса с помощью привычных для SAP
BW пиктограмм описывается возможность использования соответствующих справочников с
атрибутами, текстами, иерархиями (см. Рис.146).

Рис.146. Просмотр структуры и аналитических свойств ракурса в транзакции RSRTS_ODP_DIS

Нужно отметить, что к именам аналитических объектов здесь добавлен префикс 2C. Это
стандартный префикс, предусмотренный в SAP при работе с CDS-аналитикой.

Развернув это описание детальнее, разработчик может уяснить для себя используемые типы
данных, названия полей и так далее. На примере поля AircraftType это показывает Рис.147.
Рис.147. Подробный просмотр свойств поля CDS-ракурса в транзакции RSRTS_ODP_DIS

Здесь пиктограммой показано, что данная аналитика содержит основные данные. Также указано,
какой CDS-ракурс реализует эти основные данные: это ракурс, у которого имя SQL View -
ZIAIRCRAFTT. Указано краткое описание этого ракурса, чтобы разработчик мог понимать, какие
атрибуты справочника AircraftType есть в его распоряжении.

Если нажать кнопку , то пользователь попадёт в интерфейс, предоставляющий

базовые возможности аналитической функциональности: добавлять/убирать детализацию по
имеющимся аналитикам, накладывать фильтры. По умолчанию данные выводятся максимально
агрегированными, без детализации по каким-либо аналитикам (см. Рис.148).

Рис.148. Интерфейс для OLAP-тестирования CDS-куба

Поэтом, например, в столбцах Airfare и Booking Total вместо сумм стоят символы *. Это
объясняется тем, что в исходных данных есть суммы в различных валютах. И просто так
складывать такие суммы будет, разумеется, некорректно. Чтобы увидеть эти подробности,
необходимо детализировать данные по валютам. Сделать это возможно, например, нажав на
пиктограмму «детализировать по строкам» рядом с аналитикой валют (см. Рис.149).

Рис.149. Включение детализации по строкам для аналитики Airline Currency

В результате отчёт будет развёрнут по различным валютам, и теперь уже для каждой валюты будут
указаны соответствующие суммы (см. Рис.150).

Рис.150. Просмотр данных из SQL View ZIFLIGHTA в детализации по валютам авиакомпаний

Этот тестовый интерфейс аналитического запроса является типичным для BW-консультанта,

поэтому дополнительных пояснений здесь приводить не будем. Интерфейс позволяет провести
предварительный тест композитного ракурса, убедиться, что заданные аналитики доступны для
работы, а числовые показатели отражаются корректно. То есть композитный ракурс пригоден для
того, чтобы на его основе создавать ракурсы использования, которые будут поставлять данные
аналитическим приложениям-потребителям.

7. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ:
РАКУРС ИСПОЛЬЗОВАНИЯ
7.1 Создание аналитического ракурса
Продолжим построение демонстрационного примера. Ранее с помощью ассоциаций был определён
ракурс ZI_FLIGHTBYAIRPORT. Это композитный ракурс, имеющий категорию данных #CUBE. На
основе этого ракурса теперь создадим аналитический отчёт (Query). Как указывалось ранее,
аналитический отчёт – это ракурс специального вида. Во-первых, он должен быть определён как
ракурс использования. Во-вторых, для этого ракурса не указывается никакая категория данных. В-
третьих, в заголовке ракурса требуется указать аннотацию @Analytics.query: true. Техническим
именем ракурса будет ZC_FLIGHTBYAIRPORTQUERY.

Также предусмотрим возможность публикации ракурса как OData-сервиса. Для этого используется
аннотация @OData.publish: true. При наличии OData-сервиса можно использовать данные CDS-
ракурса в работе Fiori-приложений. В следующих частях данной публикации будут рассмотрены
примеры таких приложений.

Учитывая сказанное, в заголовке ракурса нужно использовать следующие аннотации (см. Рис.151).

Рис.151. Аннотации в заголовке ракурса ZC_FLIGHTBYAIRPORTQUERY

Новых ассоциаций в этом ракурсе определять не будем, так как все необходимые ассоциации уже
определены в нижележащих (по иерархии VDM) ракурсах и опубликованы в  используемом здесь
как источник ракурсе ZI_FLIGHTBYAIRPORT. Указание ракурса-источника выполняется точно так
же, как в предыдущих примерах. Для заполнения SELECT-листа снова удобно будет
воспользоваться опцией «Insert all elements», рассмотренной ранее. Вновь в конец SELECT-листа
будут добавлены все ассоциации, опубликованные в источнике (см. Рис.152).

Рис.152. Ассоциации из ракурса-источника автоматически включены в SELECT-лист

Но в данном случае мы формируем ракурс использования, то есть «вершину» нашей VDM. Поэтому
здесь перечисление ассоциаций нужно удалить: они не нужны, так как не будет последующих
вышестоящих ракурсов. Также можно исключить те поля, которые не потребуются нам в
создаваемом отчёте. Например – CurrentBookingsTotalAmount.

Далее, как обычно, переходим к заполнению семантических аннотаций по полям SELECT-листа.

Чтобы различить аэропорты вылета и прибытия, к этим полям допишем названия через аннотацию
@EndUserText.label. Важным новым элементом в аналитическом ракурсе являются аннотации,
которые укажут аналитическим приложениям-потребителям: какие из столбцов необходимо
детализировать по строкам, а какие – по столбцам. Это аннотации @AnalyticsDetails.query.axis со
значениями #ROWS и #COLUMNS соответственно. Выше, тестируя композитный ракурс, мы
видели, что по умолчанию все данные выводятся максимально агрегированно, одной строчкой.
Здесь с помощью указанных аннотаций мы можем заранее указать аналитическим приложениям те
развёртки, с которыми отчёт должен выводиться по умолчанию после запуска. Теперь SELECT-
лист аналитического ракурса имеет следующий вид, показанный на Рис.153. Ключевые поля для
аналитического ракурса не указываются, так как понятие ключа здесь нерелевантно.

Рис.153. Аналитические аннотации в SELECT-листе ракурса

7.2. Указание строк и столбцов отчёта. Создание фильтров
для селекционного экрана. Создание расчётного показателя
Отметим, что некоторые поля (например, AircraftType) не отмечены аннотацией
@AnalyticsDetails.query.axis. Такие поля остаются как так называемые «свободные». По умолчанию,
данные отчёта будут выведены без детализации по свободным аналитикам, агрегированно. И после
запуска отчёта пользователь сам будет решать: добавить ли эти поля в строки или в столбцы отчёта.

Также нужно учитывать, что для числовых полей способ агрегации (@DefaultAggregation) был
определён в предыдущих ракурсах. Поэтому здесь повторного определения не требуется.

Следующий важный новый пример аннотаций – это фильтры. Если использовать такие аннотации,
то при запуске аналитического ракурса пользователь сначала увидит селекционный экран. На этом
экране пользователь сможет указать критерии фильтрации при выборе данных в отчёт. Несколько
примеров аннотаций для фильтров:

 @Consumption.filter.selectionType  Определяет то, сколько значений можно указать для

фильтрации. Возможные варианты повторяют аналогичные настройки, привычные при
разработке отчётов в SAP BW: #HIERARCHY_NODE, #INTERVAL, #RANGE, #SINGLE
 @Consumption.filter.multipleSelections Определяет возможность многократного выбора.
Возможные значения – true или false.
 @Consumption.filter.mandatory Определяет: является ли обязательным заполнение данного
фильтра на селекционном экране. Возможные значения – true или false.

В нашем примере укажем, что на селекционном экране должны быть представлены фильтры по
аэропортам отправления и прибытия. Причём в качестве каждого из фильтров должно быть
выбрано ровно одно значение. И пользователь обязан сделать выбор по аэропорту отправления.
Отметим, что три приведённых примера аннотаций начинаются одинаково со слов
@Consumption.filter. В этом случае синтаксис CDS позволяет перечислить такие однотипные
аннотации не через несколько отдельных строк, а в одной строке. Перечисление однотипных
аннотаций обрамляется фигурными скобками. Пример такого синтаксиса – на Рис.154.

Рис.154. Аннотации, определяющие фильтры на селекционном экране отчёта. Используется

синтаксис, группирующий аннотации одного вида

Ещё один пример новых аннотаций – это создание вычисляемых полей (формул). Отметим, что
такие поля можно определить и на более низких уровнях иерархии VDM, например – в
композитных ракурсах. В нашем SELECT-листе есть поля MaximumNumberOfSeats (максимальная
вместимость самолёта) и NumberOfOccupiedSeats (количество мест, которые уже забронированы).
Разность двух этих чисел даст количество мест, свободных для бронирования. Вычислим эту
разность и добавим её в SELECT-лист. Новое поле назовём NumberOfAvailableSeats. Важной
особенностью такого определения является указание способа агрегации. Следует использовать
аннотацию @DefaultAggregation: #FORMULA. Остальные аннотации уже нам знакомы, в целом
определение нового поля показано на Рис.155.

Рис.155. Аннотации, определяющие расчётный показатель в отчёте

При использовании формул важно понимать: в какой момент выполняется этот расчёт. Мы создали
формулу на финальном этапе, в последнем ракурсе нашей VDM. Поэтому расчёт формулы будет
выполняться не отдельно для каждой строчки исходных данных, а уже по агрегированным данным,
пришедшим из композитного ракурса ZI_FLIGHTBYAIRPORT. В нашем примере это не имеет
существенного значения: неважно, будем ли мы считать сначала разность по каждой строчке, а
потом агрегируем все эти разности; либо сначала просуммируем для всех строчек значения
MaximumNumberOfSeats и значения NumberOfOccupiedSeats, а потом вычтем одну сумму из
другой. Но в других случаях способ расчёта формул может иметь существенное значение для
получения корректного результата. Примером могут служить формулы, рассчитывающие средние
значения. Там некорректно рассчитывать среднее отдельно по каждой строчке, а потом
суммировать. Корректным будет как раз расчёт среднего уже по агрегированным значениям.

Окончательный код ракурса приведён на Рис.156.

Рис.156. Код ракурса ZC_FLIGHTBYAIRPORTQUERY

7.3. Тестирование аналитического ракурса
Созданный аналитический ракурс может использоваться приложениями-потребителями так же, как
используются обычные BEx-запросы, создаваемые в SAP BW. Необходимо только правильно
указать техническое имя запроса. Нужно взять SQL-имя, заданное в аннотации ракурса, и добавить
к нему префикс 2C (аналогичная ситуация была и при тестировании композитного ракурса выше). В
нашем примере получится 2CZCFLIGHTAQ. Быстрый тест такого запроса можно (как и для отчётов
SAP BW) провести в транзакции RSRT (см. Рис.157).

Рис.157. Тестирование аналитического ракурса в транзакции RSRT

Обратим внимание, что если в показанной ситуации нажать клавишу ENTER, то к техническому
имени запроса подтянется ещё и имя источника данных (в терминологии BW это инфо-провайдер).
Для нашего ракурса источником является ZI_FLIGHTBYAIRPORT. Он имеет SQL-имя ZIFLIGHTA.
Результат показан на Рис.158.

Рис.158. Имя инфо-провайдера автоматически подтягивается к имени отчёта

После запуска транзакции появится селекционный экран отчёта. Его вид определён аннотациями в
нашем ракурсе (см. Рис.159).

Рис.159. Селекционный экран при тестировании аналитического ракурса в RSRT

Здесь поле аэропорта отправления выделено красной пиктограммой как обязательное для
заполнения. В качестве примера указан Нью-Йоркский аэропорт Кеннеди (техническое имя JFK).
Результат выполнения отчёта показан на Рис.160.

Рис.160. Данные аналитического ракурса при тестировании в RSRT

Развёртка аналитик по столбцам и строкам по умолчанию выведена в соответствии с аннотациями

@AnalyticsDetails.query.axis

Подробности работы с отчётом в транзакцииRSRT выходят за рамки нашей тематики и относятся к

компетенции консультантов SAP BW.

8. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ: ИТОГ

На этом построение демонстрационной модели завершено. В следующих частях данной публикации
планируется рассмотреть такие применения аналитических ракурсов и ракурсов использования, как
построение Fiori-приложений и визуализация с помощью программ линейки SAP BusinessObjects.

В заключение на Рис.161 приведём схематическое изображение всех ракурсов построенной

демонстрационной VDM. Стрелки отражают взаимосвязи между ракурсами: пунктирные стрелки
показывают присоединение через ассоциации, сплошные – получение данных из ракурса-
источника. Для базовых ракурсов также указаны таблицы-источники. Горизонтальные штриховые
линии разделяют ракурсы разных типов, ещё раз подчёркивая иерархическое строение VDM.
Рис.161. Иерархическая схема ракурсов демонстрационной VDM

Перевод картинки:

 Basic – Базовые ракурсы

 Composite – Композитные ракурсы
 Consumption – Ракурсы использования

Практика освоения ABAP CDS для непрограммистов. Часть 6

Часть 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_S4HANA17
09_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_C
onfigGuide_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-сервисов в системе Back-End

Нужно отметить, что S/4HANA может быть развёрнута в конфигурации Embedded Deployment,
когда компоненты Back-End и Front-End установлены вместе на одной системе. Тогда, разумеется, и
OData-сервис выполняется в той же системе. В таком случае следует выбрать для Alias значение
LOCAL.

Затем нужно заполнить поле Technical Service Name. Выше уже говорилось о том, как получается
его значение (см. Рис.9).

Рис.9. Параметры для поиска OData-сервиса, сгенерированного на основе CDS

После этого нажать кнопку . Если настройки коммуникации Back-End и Front-End

проведены правильно, то сервис появится в списке найденных (см. Рис.10).

Рис.10. Результаты поиска вновь активируемого OData-сервиса

Необходимо выделить строку с найденным сервисом и нажать . В появившемся

окне почти все параметры уже настроены по умолчанию (см. Рис.11).
Рис.11. Окно активации нового OData-сервиса

Единственное поле, которое требуется заполнить – это Package Assignment. Поскольку в нашем
случае речь идёт о демо-примере, то достаточно нажать , чтобы был указан локальный
пакет $TMP. После подтверждения введённой информации появится информационное сообщение о
том, что сервис успешно активирован (см. Рис.12).

Рис.12. Подтверждениеуспешной активации сервиса

Теперь сервис уже виден в списке активных, в основном окне транзакции

/IWFND/MAINT_SERVICE. Если сервисов много, то удобно воспользоваться кнопкой Filter, чтобы
ограничить просмотр только нужным сервисом. Например, фильтруя по тому же значению
Technical Service Name (см. Рис.13).
Рис.13. Активированный сервис на основном экране транзакции /IWFND/MAINT_SERVICE

Здесь можно проверить корректность работы сервиса. Для этого необходимо выделить его
техническое имя, как это показано на Рис.13. (Если выделить не Technical Service Name, а всю
строчку, то корректного результата получить не удастся). При этом в окне ICF Nodes должен
появиться узел с именем ODATA и зелёный «светофор». А в окне System Aliases появляется
псевдоним системы Back-End. Затем нужно нажать кнопку . Появится окно с
тестовой командой для проверки сервиса (см. Рис.14).

Рис.14. Окно тестирования OData-сервиса

Здесь нужно нажать . Если всё настроено правильно, должен появиться отклик «ОК»,
статус отклика – 200, а также xml-код с информацией о ракурсе (см. Рис.15).
Рис.15. Результат успешного тестирования OData-сервиса

Аналогичную процедуру следует проделать и в системе Back-End. Только в качестве System Alias
указывать уже значение LOCAL.

Если теперь снова открыть DDL-код ракурса ZC_AIRLINEQUERY, то предупреждения о

неактивном сервисе уже не будет. Вместо него рядом с аннотацией появится характерная
пиктограмма действующего сервиса. При наведении на неё курсора мыши, появится всплывающее
пояснение (см. Рис.16).

Рис.16. Индикация успешно активированного OData-сервиса в DDL-коде ракурса

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

В следующих примерах будет использован пользователь FIORI_ADM, который создан согласно
рекомендациям, данным в документе

https://support.sap.com/content/dam/SAAP/Sol_Pack/Library/Configuration/MAA_S4HANA1709_BB_C
onfigGuide_EN_XX.docx
Необходимо особо подчеркнуть, что для успешной работы доверенных RFC-соединений между
системами Front-End и Back-End необходимо, чтобы пользователь с именем FIORI_ADM был
создан в обеих системах. То же самое относится и к любым пользователям SAP Fiori.

Присвоим пользователю FIORI_ADM следующие роли в системе Front-End:

 SAP_BR_PURCHASING_MANAGER
 SAP_BR_ANALYTICS_SPECIALIST
 SAP_BR_EMPLOYEE
 Z_RDS_BCR
 Z_RT_ADMIN
 ZSAP_UI2_ADMIN

Здесь роли SAP_BR_*** - это стандартные бизнес-роли SAP. Присвоение этих ролей позволяет
пользователю видеть в Fiori Launchpad соответствующие группы плиток. Например, бизнес-роль
аналитика делает доступными такие приложения, как KPI Modeler и Query Browser.

Роли Z*** должны быть созданы в соответствии с теми указаниями, которые даны в упомянутой
документации SAP. Эти роли дают необходимые полномочия по созданию/изменению плиток.

Помимо этого, документ «MAA_S4HANA1709_BB_ConfigGuide_EN_XX» указывает, что для

корректной работы доверенных RFC-соединений необходимо использовать полномочия из объекта
S_ RFCACL. Для этого, например, можно создать отдельную роль Z_RFCACL с профилем
полномочий, показанным на Рис.17.

Рис.17. Профиль роли Z_RFCACL

Такую роль следует создать как в системе Front-End, так и в Back-End. И в обеих системах
присвоить роль пользователю FIORI_ADM. Далее предполагается, что все действия будет
выполнять пользователь FIORI_ADM.

С указанными полномочиями этот пользователь при запуске Fiori Launchpad будет в верхней части
страницы видеть список групп, доступных ему (см. Рис.18).
Рис.18. Выбор групп плиток, доступных пользователю по его полномочиям во Fiori Launchpad

Нажатие на название группы вызовет прокрутку страницы и пользователь увидит плитки этой
группы. Пример выбора группы KPI Design см. на Рис.19.

Рис.19. Плитки группы KPI Design

Наконец, в правом конце строки с заголовками групп есть выпадающий список всех доступных
групп. С его помощью также возможна быстрая навигация между группами плиток (см. Рис.20).
Рис.20. Быстрая навигация по группам плиток

В частности, здесь кроме групп из стандартной поставки SAP Fiori, доступна и созданная вручную
группа Z_RDS_BCG. Но в ней пока ещё нет ни одной плитки (см. Рис.21).

Рис.21. Созданная пользователем группа плиток изначально пуста

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

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

Launchpad Designer
Ракурс использования ZC_AIRLINEQUERY по сути является справочником авиакомпаний. Для
целей простейшей иллюстрации создадим плитку, которая показывает количество авиакомпаний в
справочнике.

Запускаем Fiori Launchpad Designer (ссылка для запуска указана выше). Первое действие – это
создать новую плитку. Создать её можно только в существующем каталоге. Поэтому в верхнем
левом углу следует выбрать «Catalogs», как показано на Рис. 22.
Рис.22. Список каталогов при работе в Fiori Launchpad Designer

В зависимости от полномочий пользователя, список доступных каталогов может быть очень велик.
Поэтому его удобно ограничить. Нам нужен ранее созданный каталог Z_RDS_BC. Достаточно в
поле поиска ввести начало этого имени и нажать на кнопку . Будут выбраны все каталоги по
частичному совпадению имён (см. Рис. 23).

Рис.23. Результат контекстного поиска каталогов

На Рис. 23 имя каталога выделено. При этом справа видно, что в каталоге пока ещё нет ни одной
плитки. Для создания новых плиток используется кнопка .  Если её нажать, открывается выбор
типов создаваемой плитки (см. Рис. 24).
Рис.24. Возможные типы плиток, создаваемых в Fiori Launchpad Designer

Вариант «App Launcher - Dynamic» создаёт плитку, которая отражает некое число, значение KPI.
Это число формируется в приложении, выполняемом системой Back-End. Число динамически
изменяется в зависимости от изменения тех данных, которые использует это приложение.

Вариант «App Launcher - Static» создаёт плитку со статической надписью. Но этот вариант, как и
предыдущий, при нажатии на плитку приводит к запуску Fiori-приложения, привязанного к этой
плитке.

Вариант «News» используется для создания плиток, отражающих текущую информацию из

привязанного потока новостей.

Для нашего примера используем вариант «App Launcher - Dynamic». Откроется окно с параметрами
настройки плитки (см. Рис. 25).

Рис.25. Окно создания плитки по варианту «App Launcher - Dynamic»

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

плитки
На Рис. 25 важнейшим является поле Service URL. Оно содержит ссылку, по которой считывается
динамическая информация, отражаемая на плитке. Для нашего примера такая информация – это
количество авиакомпаний в справочнике.
Проиллюстрируем способ получения этих данных через ракурс ZC_AIRLINEQUERY и OData-
сервис ZC_AIRLINEQUERY_CDS. Для этого вернёмся к ранее приведённому примеру, где работа
сервиса тестировалась в транзакции /IWFND/MAINT_SERVICE (см. Рис. 14 и 15). На Рис. 26 вновь
приведено xml-описание этого OData-сервиса. Примерно в середине данного кода выделено
техническое имя ракурса.

Рис.26. Имя исходного CDS-ракурса можно видеть в тесте OData-сервиса

Конечно, в нашем простом примере данное имя и так известно. Но в более сложных разработках его
можно узнать описанным здесь способом. Вообще говоря, это имя может содержать не только
заглавные, но и строчные буквы. Поэтому надёжнее всего скопировать это имя из xml, а не
набирать его вручную. И затем вставить скопированное имя в конец тестового URL (см. Рис. 27).

Рис.27. URL для просмотра данных ракурса ZC_AIRLINEQUERY

Теперь нажатие кнопки  выведет данные из ракурса ZC_AIRLINEQUERY в формате xml

(см. Рис. 28).
Рис.28. Просмотр данных из ZC_AIRLINEQUERY в xml-формате

На Рис. 28 можно видеть описание ракурса а также содержание первой записи – три поля,
описывающие авиакомпанию American Airlines.

Чтобы теперь получить метаданные о ракурсе ZC_AIRLINEQUERY, нужно добавить

соответствующую команду в конец тестового URL вместе со служебным символом $. В нашем
примере требуется подсчитать общее число записей в ракурсе, для чего используется служебное
слово count (см. Рис. 29).

Рис.29. Подсчёт числа строк в ZC_AIRLINEQUERY через OData-сервис

Итак, ракурс содержит 18 записей. А то, что получилось в поле тестового URL, как раз и нужно
добавить для плитки в Fiori Launchpad Designer. Копируется вся служебная строка, начиная с
первого символа / (см. Рис. 30).
Рис.30. Указание Service URL для данных, получаемых в плитке

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

плитки в группе
«Refresh Interval in Seconds» (см. Рис. 25) оставим с нулевым значением. Поскольку в нашем
примере количество записей не меняется, а потому нет смысла в периодическом обновлении
данных из Back-End.

В поле «Icon» можно из списка выбрать любую пиктограмму. Она будет отображаться на плитке.
Например, можно найти и выбрать пиктограмму с изображением самолёта. Затем требуется
отключить галку навигации по семантическому объекту (см. Рис. 31).

Рис.31. Плитка не предусматривает перехода к работе в приложении

Данная настройка в нашем примере не требуется, так как создаваемая плитка не будет
инициировать работу какого-либо Fiori-приложения.

На этом настройки плитки завершены. Остаётся нажать «Save» в нижнем правом углу окна
настроек. Теперь Fiori Launchpad Designer отобразит новую плитку, как показано на Рис. 32.

Рис.32. Плитка создана в Fiori Launchpad Designer

Можно заметить, что на Рис. 32 слева, рядом с именем каталога появилась цифра 1. Она отражает
число плиток в данном каталоге.
Теперь созданную плитку необходимо включить в группу Z_RDS_BCG. Тогда плитку смогут
видеть пользователи, имеющие полномочия на эту группу. Для добавления в группу необходимо в
окне Fiori Launchpad Designer нажать «Groups». И так же как с каталогами, можно воспользоваться
полем фильтрации, чтобы быстро найти нужную группу (см. Рис. 33).

Рис.33. Контекстный поиск группы при работе в Fiori Launchpad Designer

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

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

Из списка выбираем каталог Z_RDS_BC. Можно, например, нажать кнопку  в поле выбора
каталога. Откроется полный список доступных каталогов. В нём можно снова воспользоваться
поиском по частичному совпадению имени (см. Рис. 35).
Рис.35.Поиск каталога, из которого плитка будет добавлена к группе

В результате мы увидим все плитки выбранного каталога (см. Рис. 36).

Рис.36.Плитки, доступные в выбранном каталоге для добавления в группу

В нашем примере плитка всего одна. И под ней есть серый ярлычок со знаком +. Это значит, что
плитку можно добавить в текущую группу. Нажимаем на ярлычок. Его цвет меняется на зелёный, а
символ + заменяется на «галку». Это значит, что плитка успешно добавлена в группу. Возвращаясь
к просмотру группы, мы также видим, что плитка добавлена (см. Рис. 37).

Рис.37.Результат добавления плитки в группу

Остаётся заново запустить Fiori Launchpad. На Рис. 21 мы видели, что группа Z_RDS_BCG не
содержала плиток. Теперь же там появилась наша плитка. И она отражает информацию из системы
Back-End через ракурс ZC_AIRLINEQUERY и OData-сервис ZC_AIRLINEQUERY_CDS (см. Рис
38).

Рис.38.Вид готовой плитки на Fiori Launchpad

Часть 7. Продолжение.
Часть 1  Часть 2  Часть 3  Часть 4  Часть 5  Часть 6

Оглавление
2. СОЗДАНИЕ ПРИЛОЖЕНИЯ FIORI В СРЕДЕ WEB IDE

2.1 SAP WebIDE

2.1.1 Роль и место Web IDE в разработке приложений SAP UI5

2.1.2 Краткие сведения об установке и конфигурировании

2.2 Создание приложения из стандартного шаблона

2.2.1 Создание проекта, указание основных параметров

2.2.2 Подключение к данным из CDS через OData-сервис

2.2.3 Тестирование работоспособности

2.3 Публикация приложения на Front-End

2.4 Создание плитки из опубликованного приложения

2. СОЗДАНИЕ ПРИЛОЖЕНИЯ FIORI В

СРЕДЕ WEB IDE
2.1 SAP WebIDE
2.1.1 Роль и место Web IDE в разработке
приложений SAP UI5
Пример, разобранный в предыдущей главе, является максимально упрощённым. Его задача –
рассказать о терминах, с которыми приходится столкнуться при создании Fiori-плиток, описать
элементы архитектуры SAP Fiori, проиллюстрировать основные шаги, выполняемые при создании и
настройке плиток. Пример даже не задействует по существу созданный нами ракурс использования.
Вместо этого только считываются метаданные ракурса, а именно – количество записей. В данной
главе рассмотрим немного более сложный и содержательный пример. Построим SAPUI5-
приложение, а затем уже и плитку на его основе. Приложение будет в форме таблицы выводить
пользователю Fiori Launchpad на просмотр записи из того же CDS-ракурса.

Для разработки SAPUI5-приложений используется отдельный инструмент, который называется

SAP Web IDE. На Рис. 39 отражено взаимодействие Web IDE с ранее рассмотренными элементами
архитектуры SAP Fiori. Также этот рисунок показывает взаимодействие других инструментов
фронтэнда (SAP GUI, ABAP Development Tools) с системой S/4HANA при разработке Fiori-
приложений на основе CDS.

Рис.39. Роль различных пользовательских инструментов в создании приложений SAP UI5

Как видно из этой схемы, SAP Web IDE соединяется с системой Front-End и использует в своей
работе предварительно активированные OData-сервисы, поставляющие данные из CDS-ракурсов.
Затем готовые приложения публикуются в репозитарии системы Front-End. Из репозитария
приложения могут быть размещены на SAP Fiori Launchpad для конечных пользователей. На Рис.
40 изображена обобщённая последовательность действий и «распределение обязанностей» при
разработке SAPUI5-приложений.
Рис.40. Этапы создания Fiori-приложения, соответствующие им роли и инструменты

Использование среды разработки SAP Web IDE возможно в двух режимах: Trial или Production.
Режим Trial предполагает, что программа инсталлируется на компьютере пользователя и
используется локально для работ по разработке и тестированию, которые выполняет один
пользователь. Режим  Production нужен для разработок, которые будут использоваться в
продуктивных системах. Для этого режима требуется подключение к SAP Cloud Platform, доступное
на условиях платной подписки.

2.1.2 Краткие сведения об установке и

конфигурировании
Дистрибутивы обеих версий SAP Web IDE доступны для загрузки по ссылке
https://tools.hana.ondemand.com/#sapui5  Установка Trial-версии очень проста, её описание можно
найти в официальной документации SAP. Ключевым моментом для использования SAP Web IDE
является подключение к системе Front-End. Оно необходимо, чтобы создаваемое приложение могло
«видеть» активированные в этой системе OData-сервисы и использовать их для получения данных
из Back-End. Предположим, что в соответствии с инструкциями по установке SAP Web IDE
развёрнут в локальной папке C:\SAPWebIDE. В этом случае необходимо создать специальный файл
с параметрами подключения и поместить его в папку
C:\SAPWebIDE\eclipse\config_master\service.destinations\destinations. Файл должен иметь название из
трёх символов, совпадающее с SID-ом системы Front-End. Файл можно создать в обычном
текстовом редакторе (например, в стандартном Windows-приложении «Блокнот»). Но затем
проследить, чтобы у файла не было никакого расширения. Например, если SID подключаемой
системы имеет значение ABC, то так же должен называться и файл (а не ABC.txt, ABC.doc, ABC.rtf
и т.п.). Содержание файла должно быть следующим:

Description=<краткое текстовое описание Front-End-системы>

  Type=HTTP
   TrustAll=true
   Authentication=NoAuthentication
   Name=ABC
   ProxyType=Internet
   URL=<protocol>://<server>:<port>
   WebIDEUsage=odata_abap,odata_gen,ui5_execute_abap,dev_abap,bsp_execute_abap,odata_xs
   WebIDESystem=ABC
   WebIDEEnabled=true
   sap-client=<номер рабочего манданта Front-End-системы>

Здесь на место обозначений protocol, server и  port подставляются те же параметры соединения с

системой Front-End (или с SAP Web Dispatcher-ом), как и в предыдущей главе.

После установки SAP Web IDE и подготовки файла с параметрами подключения, необходимо из
папки C:\SAPWebIDE\eclipse запустить файл orion.exe. В результате появится DOS-окно, которое
через несколько секунд заполнится несколькими строчками технических сообщений (см. Рис. 41).

Рис.41. Запуск служб, обеспечивающих работу локально установленного Web IDE

После этого интерфейс SAP WebIDE доступен через браузер по ссылке

http://localhost:8080/webide/index.html  Стартовый экран изображён на Рис. 42.
Рис.42. Окно входа в локально установленный Web IDE

При первом подключении необходимо нажать «Create a new account» (см. Рис. 43). В появившемся
окне указать произвольно выбранные логин и пароль. Имеет смысл сделать их такими же, как
логин/пароль вашего пользователя в Front-End-системе. Также следует указать свой e-mail, после
чего нажать «Sign up».

Рис.43. Создание учётной записи для работы в Web IDE

В дальнейшем можно будет сразу входить в рабочую среду SAP WebIDE по этому логину/паролю,
нажимая на стартовой странице кнопку .

2.2 Создание приложения из стандартного

шаблона
2.2.1 Создание проекта, указание основных
параметров
В нашем простом примере можно использовать стандартные шаблоны Fiori-приложений. Для этого
перейти по команде меню File->New->Project from Template (см. Рис. 44).

Рис.44. Создание приложения на основе шаблона

Откроется окно мастера, с помощью которого за несколько последовательных шагов можно ввести
все необходимые параметры и создать приложение по одному из стандартных шаблонов (см. Рис.
45).

Рис.45. Первый шаг мастера приложений SAPUI5: выбор шаблона

Так как наша задача – обеспечить табличный просмотр данных из CDS-ракурса, то выбор варианта
List Report Application является очевидным. Важно обратить внимание на значение в поле SAPUI5
Version. По соображениям совместимости это значение не должно быть больше, чем версия
SAPUI5, используемая в системе Front-End. Узнать эту версию можно, открыв в браузере ссылку
<protocol>://<server>:<port>/sap/public/bc/ui5_ui5/  Как видно из Рис. 46, многие библиотеки в
SAPUI5 могут быть доступны в нескольких версиях. Достаточно ориентироваться на наименьшую
версию. И если необходимо, выбрать из списка в поле SAPUI5 Version номер версии пониже.
Рис.46. Версии UI5, доступные в системе Front-End

После этого нажать Next и перейти к следующему шагу мастера (см. Рис. 47).

Рис.47. Второй шаг мастера приложений SAPUI5:основные параметры приложения

В поле Project Name нужно ввести техническое имя будущего приложения. В поле Title – словесное
описание. Для нашего примера укажем «AirlineList» и «Airline List» соответственно. Снова
нажимаем Next.

2.2.2 Подключение к данным из CDS через

OData-сервис
Первое, что потребуется сделать на следующем шаге мастера – это указать тип источника, на
основе которого будет создано приложение. В нашем случае это OData-сервис из списка сервисов,
доступных в Front-End-системе (см. Рис. 48).

Рис.48. Выбор типа источника данных для приложения.

Затем нужно выбрать ту систему Front-End, с которой мы работаем. Выбрать систему можно из
раскрывающегося списка (см. Рис. 49).

Рис.49. Выбор системы Front-End

В этом списке будут видны системы, для которых правильно подготовлены и размещены файлы с
параметрами соединения (см. предыдущий раздел). В список выводятся текстовые описания систем,
которые указаны в разделе Description этих файлов. Как только будет выбрана конкретная система,
появится всплывающее окно (см. Рис. 50).

Рис.50. Ввод логина и пароля для подключения приложений SAPUI5 к системе Front-End

Упомянутая здесь ссылка на локальный компьютер (localhost) не должна вводить в заблуждение.

Необходимо указать логин и пароль пользователя в системе Front-End. Как и ранее, в нашем
примере используется пользователь FIORI_ADM. После ввода логина и пароля станет доступен
список всех OData-сервисов, опубликованных в системе Front-End (см. Рис. 51).
Рис.51. Третий шаг мастера приложений SAPUI5:подключение к OData-сервису

Поскольку сервисов может быть очень много, то удобно воспользоваться контекстным поиском,
вводя в поле Services часть названия нужного сервиса. Для нашего примера это сервис
ZC_AIRLINEQUERY_CDS (см. Рис. 52).

Рис.52. Контекстный поиск необходимого OData-сервиса

При необходимости можно иерархически развернуть данные о полях сервиса, используя значок >
слева от названия (см. Рис. 53).

Рис.53. Краткий обзор метаданных сервиса

Чтобы выбрать сервис для его дальнейшего использования, нужно нажать кнопку  слева от его
названия. Цвет стрелки на кнопке изменится с тёмного на светлый. Используя кнопку ,
можно увидеть дополнительные технические сведения о сервисе. В том числе, проверить его
текущий статус (см. Рис. 54).

Рис.54. Выбор OData-сервиса и просмотр его статуса

Выбрав сервис, снова нажимаем Next. Следующий шаг (Annotation Files) пропускаем и снова
нажимаем Next. Всё что остаётся сделать на следующем шаге (Template Customization) – это в поле
OData Collection выбрать из списка техническое имя CDS-ракурса. Список будет заполнен на
основании выбранного OData-сервиса. Поэтому в нашем примере выбор тривиален (см. Рис. 55).

Рис.55. Завершающий шаг мастера приложений SAPUI5: выбор CDS-ракурса, поставляющего

данные

2.2.3 Тестирование работоспособности

Для нашего простейшего примера больше никаких настроек не требуется. Поэтому можно
завершить работу нажатием кнопки Finish. Созданный проект отобразится в папке локальных
проектов Workspace (см. Рис. 56).

Рис.56. Созданное приложение в папке локальных проектов Web IDE

Приложение можно протестировать локально здесь же. Для этого нужно выделить его название и
перейти по командам меню Run->Run As->SAP Fiori Launchpad Sandbox. Возможно, что на этом
этапе появится сообщение о том, что ваш браузер блокирует всплывающие окна. В таком случае
нужно добавить адрес http://localhost:8080 в список исключений блокировщика. Затем снова
возникнет небольшое всплывающее окно, в котором потребуется ввести логин и пароль для
системы Front-End. После ввода этих данных запустится тестовая веб-страница с приложением.
Первоначально она может оказаться пустой (см. Рис. 57).

Рис.57. Исходный вид приложения Airline List

Чтобы заполнить таблицу приложения данными, нужно выбрать список столбцов, выводимых на
экран. А затем выбрать и заполнить условия фильтров для отбора данных. Список столбцов можно
сформировать, нажав кнопку  в правой части экрана. В нашем ракурсе всего три столбца,
выберем их все, пометив галочками, как на Рис. 58.

После этого заголовки столбцов станут видны:

Рис.58. Выбор столбцов CDS-ракурса, отображаемых в приложении

Теперь необходимо сформировать условия фильтрации. Для этого нажимаем кнопку «Адаптировать
фильтр» (см. правую область экрана на Рис. 57). Появится окно настройки фильтров (верхняя часть
Рис. 59). Переходим по ссылке «Прочие фильтры» и вновь выбираем все три поля (средняя часть
Рис. 59). После подтверждения этого выбора система предложит указать условия фильтрации для
выбора данных из CDS-ракурса (нижняя часть Рис. 59).
Рис.59. Последовательные шаги указания фильтра на данные в приложении

Здесь можно ничего не вводить, то есть выбрать все данные без дополнительной фильтрации. В
нашем примере это некритично, ведь из предыдущей главы уже известно, что ракурс содержит
всего 18 записей. Поэтому в окне адаптации фильтра сразу нажимаем «Применить». Получаем
строку с фильтрами и полный табличный просмотр данных из CDS-ракурса (см. Рис. 60).
Рис.60. Приложение Airline List в режиме тестирования

2.3 Публикация приложения на Front-End

Прежде чем опубликовать созданное приложение в репозитарии системы Front-End, необходимо
расширить полномочия пользователя FIORI_ADM, так как публикация приложений выполняется в
виде BSP-приложение на ABAP-сервере. Как для Front-End, так и для Back-End нужно добавить
полномочия, указанные на Рис. 61

Рис.61. Полномочия, требующиеся для публикации Fiori-приложений

Также необходимо в транзакции SICF проверить, что активен сервис /sap/bc/adt. При
необходимости – активировать его. Дополнительно потребуется активировать сервисы, отвечающие
за CHIPs (элемент технологии WebDynpro). Например, можно использовать фильтр по названиям
(см. Рис. 62).
Рис.62. Поиск необходимых сервисов в транзакции SICF

Выполнив эти настройки, можно вернуться к работе в SAP Web IDE . Нужно вызвать контекстное
меню нашего проекта и перейти по командам Deploy->Deploy to SAPUI5 ABAP Repository (см. Рис.
63).

Рис.63. Запуск мастера публикации приложений в SAP Web IDE

Откроется простой мастер. На его первом шаге достаточно выбрать Front-End-систему из списка и
оставить опцию «Deploy a new application» (см. Рис. 64).
Рис.64. Первый экран мастера публикации приложений в SAP Web IDE

На следующем шаге нужно ввести техническое имя создаваемого приложения, его текстовое
описание и пакет разработки. Техническое имя должно удовлетворять определённым
ограничениям, которые накладывает работа в ABAP-словаре. Увидеть эти требования можно, если
подвести указатель мыши к вопросительному знаку рядом с названием поля (см. Рис. 65).

Рис.65. Требования к техническому имени приложения SAPUI5

Для нашего примера укажем техническое имя ZAIRLINELIST, название Airline List и пакет $TMP.
Нужно отметить, что имя пакета невозможно ввести вручную, необходимо выбрать его из
имеющихся в репозитарии, выполнив поиск по кнопке Browse (см. Рис. 66).

Рис.66. Второй экран мастера публикации приложений в SAP Web IDE

На последнем шаге работы мастера публикации (Confirmation) остаётся только нажать кнопку
Finish. После этого стартует процесс публикации. В верхнем правом углу рабочего окна SAP Web
IDE выводятся информационные сообщения о том, что процесс идёт и что он завершился. Примеры
таких сообщений см. на Рис. 67.

Рис.67. Сообщения SAP Web IDE во время публикации Fiori-приложения в системе Front-End

Также успешный процесс публикации необходимо проверить, выполнив поиск сервиса в

транзакции SICF (система Front-End). Поиск выполняется по тому техническому имени, которое
было указано при публикации (см. Рис. 68).

Рис.68. Проверка корректности публикации приложения через транзакцию SICF

Здесь для дальнейшего нам потребуется имя сервиса в контексте SAPUI5. Для этого двойным
щелчком открываем просмотр сервиса из каталога ui5_ui5 (см. Рис. 69).
Рис.69. Полное имя сервиса опубликованного приложения

Полное имя сервиса – это его имя, плюс путь к сервису от default_host. В нашем примере получаем
/sap/bc/ui5_ui5/sap/zairlinelist/

2.4 Создание плитки из опубликованного

приложения
Первым этапом при создании плитки на основе приложения является создание семантического
объекта, операции над которым выполняет наше приложение (см. определения в предыдущей
главе). Это делается в транзакции /UI2/SEMOBJ (система Front-End). Семантические объекты – это
абстрактные сущности, поэтому данная транзакция представляет собой просто ракурс ведения
таблицы с описаниями объектов. Необходимо создать новую запись в этом ракурсе. Для простоты
используем те же техническое имя и описание, как и при публикации приложения (см. Рис. 70). 
При сохранении созданной записи может потребоваться указать транспортный запрос на перенос.

Рис.70. Семантический объект создан в транзакции/UI2/SEMOBJ

Далее так же, как было описано в предыдущей главе, нужно войти в SAP Fiori Launchpad Designer и
найти каталог Z_RDS_BC. Необходимо создать Target Mapping. То есть (см. предыдущую главу)
связать действие конечного пользователя (нажатие плитки) с выполнением конкретного
приложения, реализующего это действие. Для этого в выбранном каталоге нажимается кнопка
«Target Mapping» (см. Рис. 71).
Рис.71. Переход к списку созданных Target Mapping

Сейчас список настроек Target Mapping для нашего каталога пуст. В нижней части окна открываем
создание нового мэппинга (см. Рис. 72).

Рис.72. Вызов окна создания Target Mapping

Сначала нужно описать «намерение» пользователя (Intent). Как уже говорилось, намерение
описывается как семантический объект плюс то действие, которое пользователь намеревается
выполнить. Эти значения нужно выбрать из списков в соответствующих полях (см. Рис. 73).
Рис.73. Указание «намерения», которое должен выполнить данный Target Mapping

Следующий шаг – указать «цель» (Target) данного «намерения». То есть приложение, которое
должно «выполнить» это «намерение». Тип приложения для нашего примера выбираем из списка -
SAPUI5 Fiori App. Название по-прежнему будет Airline List. В поле URL указываем полное имя
сервиса из транзакции SICF (см. Рис. 69). Наконец, в поле ID  необходимо указать имя приложения.
Необходимо учесть, что это имя указывается так, как был назван проект в SAP WebIDE! В
итоге для нашего примера параметры будут такими, как показано на Рис. 74. В завершение
необходимо сохранить созданный Target Mapping (кнопка Save в нижнем правом углу).

Рис.74. Параметры «цели», выполняющей данные Target Mapping

Теперь на основе описанного мэппинга можно создавать плитку. Это делается так же, как описано в
предыдущей главе. Только в текущем примере нужно выбрать шаблон «Static», так как плитка
предназначена для вывода табличной информации и не содержит на себе динамически
обновляемых цифр. В окне создания плитки описываем то же самое «намерение», которое мы выше
привязали к Fiori-приложению через мэппинг (см. Рис. 75).

Рис.75. Указание «намерения» при создании плитки

Название и пиктограмму указываем произвольно (см. Рис. 76).

Рис.76. Выбор оформления плитки: название и пиктограмма

Остаётся сохранить созданную плитку. И добавить её в группу Z_RDS_BCG так же, как это было
описано в предыдущей главе. Теперь при запуске Fiori Launchpad пользователь FIORI_ADM видит
в группе Z_RDS_BCG уже две плитки (см. Рис. 77).

Рис.77. Приложение Airline List опубликовано как плитка в группе Z_RDS_BCG

При нажатии на плитку Airline List открывается такое же окно, как выше было при тестировании
приложения в SAP Web IDE. Поэтому в данном окне также требуется определить список
отображаемых столбцов и задать условия фильтрации. После этого пользователь увидит таблицу с
данными из CDS-ракурса, созданного в системеBack-End (см. Рис. 78).
Рис.78. Приложение Airline List запущено в Fiori Launchpad

Часть 8. Продолжение.
Часть 1  Часть 2  Часть 3  Часть 4  Часть 5  Часть 6  Часть 7

Оглавление
3. АНАЛИЗ ДАННЫХ В CDS С ПОМОЩЬЮ QUERY BROWSER

3.1. Query Browser: возможности и подготовка к запуску

3.2. Навигация в списке ракурсов

3.3. Селекционный экран ракурса: работа VDM в OData

3.4. Анализ данных с помощью Query Browser

3.4.1 Общие настройки отображения и фильтрации

3.4.2 Настройки отображения отдельных полей

3.4.3 Работа с диаграммами

3. АНАЛИЗ ДАННЫХ В CDS С ПОМОЩЬЮ

QUERY BROWSER
3.1. Query Browser: возможности и подготовка
к запуску
Browser – это приложение, входящее в стандартную поставку SAP Fiori. Оно даёт возможность
увидеть список всех аналитических CDS-ракурсов, доступных пользователю в рамках его
полномочий. Query Browser обладает следующими возможностями:

 Открыть ракурс для анализа данных. При этом используется встроенный в систему OLAP-клиент. С его
помощью возможен просмотр данных как в формате сводной таблицы, так и в виде диаграммы.
 Помещать отдельные ракурсы в список «Избранное». Это может быть удобно в тех случаях, когда
полный список доступных ракурсов слишком велик и требуется много времени на постоянный поиск
в нём.
 Добавлять к отдельным ракурсам произвольные тэги (пометки). Эти тэги можно затем видеть в
общем списке ракурсов рядом с их техническими именами.
 Фильтровать список ракурсов.
 Сортировать список ракурсов.
 Просмотреть технические детали выбранного ракурса: список его полей, их названия и ABAP-типы.
В приводимых далее примерах будет использоваться логин FIORI_ADM.  Основной перечень его
полномочий описан ранее. Но чтобы получить доступ к необходимым плиткам приложений на Fiori
Launchpad, дополнительно требуется в системе Front-End присвоить этому пользователю роли
SAP_BR_ANALYTICS_SPECIALIST и SAP_BR_EMPLOYEE.

Помимо этого, нужно самостоятельно или с помощью администраторов SAP BASIS активировать в
транзакции /IWFND/MAINT_SERVICE следующие OData-сервисы:

 RSAO_ODATA_SRV
 BSANLY_APF_RUNTIME_SRV
 VDM_CDSVIEW_BROWSER.

При активации выбрать Alias, указывающий на систему Back-End (как уже было показано на Рис.
8).

Наконец, необходимо проверить через транзакцию SICF, активированы ли следующие сервисы или
ветки в иерархии сервисов:

 /sap/bw/ina
 /sap/bw/Mime
 /sap/bc/ui5_ui5/sap/sbrt_appss1
 /sap/bc/ui5_ui5/ui2/tilechips
 /sap/bc/ui5_ui5/sap/viewbrowsers1
 /sap/bc/ui5_ui5/sap/cdsbrowsers1
 Сервисы по фильтру *sb_apps* в ветке /sap/bc/ui5_ui5/sap/

3.2. Навигация в списке ракурсов

 При наличии необходимых полномочий плитка Query Browser доступна в соответствующей группе
на Fiori Launchpad (см. Рис.79)

Рис.79. Плитка, запускающая Query Browser

Нажатие плитки «Query Browser» запускает стартовое окно этого приложения. В нём приводится
список всех аналитических CDS-ракурсов, доступных пользователю в соответствии с
присвоенными ему ролями (см. Рис. 80).
Рис.80. Список доступных ракурсов в Query Browser

Подчеркнём, что в этот список попадают не все CDS-ракурсы, а только аналитические. То есть
ракурсы использования, в заголовке которые указана аннотация @Analytics.query: true. Список
содержит как стандартные ракурсы из поставки S/4HANA, так и пользовательские ракурсы.

В зависимости от полномочий пользователя, список может быть очень большим. В приведённом

примере список содержит 430 ракурсов. Чтобы упростить навигацию в списке, вверху справа есть
строка поиска. Используем её, чтобы найти созданный ранее ракурс
ZC_FLIGHTBYAIRPORTQUERY. Поиск ведётся по частичному совпадению, поэтому достаточно
ввести в строку поиска, например, только буквы «ZC». Получаем результат, показанный на Рис. 81.

Рис.81. Результат контекстного поиска ракурса по техническому имени

Чтобы в дальнейшем не прибегать каждый раз к поискам, можно добавить этот ракурс в
«Избранное». Для этого слева от нужного ракурса нужно поставить галочку. И тогда в нижнем
правом углу приложения станет доступна кнопка с пиктограммой в форме звезды (см. Рис. 82).

Рис.82. Кнопки работы с выделенным ракурсом: добавить в избранное, создать тэг, открыть в
аналитическом приложении

Нажатие на эту кнопку добавляет ракурс в «Избранное». Теперь он и в списке также помечен
пиктограммой-звездой (см. Рис. 83).

Рис.83. Ракурс добавлен в «Избранное» для работы в Query Browser

Чтобы после запуска Query Browser увидеть избранные ракурсы, нужно слева над общим списком
выбрать опцию «Show Favorites». Это отфильтрует весь список по признаку «Избранное» (см. Рис.
84).

Рис.84. Просмотр списка «Избранное» в Query Browser

Аналогично можно добавить к ракурсу произвольную краткую текстовую пометку (тэг). Это
делается с помощью кнопки «Add Tags» (см. Рис. 82). В появившееся текстовое поле вводится
пометка, как показано на Рис. 85.

Рис.85. Добавление тэга к CDS-ракурсу в Query Browser

Сохранить или отменить введённый тэг можно кнопкой с многоточием. Можно таким образом
добавить сразу несколько тэгов. Информация о наличии тэгов и об их количестве будет отражена в
общем списке ракурсов (см. Рис. 86).
Рис.86. Отображение тэгов в списке ракурсов

Помимо поля поиска, вверху справа над списком ракурсов есть кнопка для сортировки и
фильтрации этого списка (см. Рис. 87).

Рис.87. Кнопка для фильтрации и сортировки списка ракурсов

Сортировка возможна по техническому имени ракурса или по компоненту приложений.

Фильтрация возможна также по компоненту. Но что гораздо интереснее – ещё можно фильтровать
по тэгам. Получается очень гибкая возможность настраиваемой пользователем фильтрации: с одной
стороны, можно приписать к ракурсу несколько тэгов. С другой стороны, можно и в условие
фильтра выбрать несколько тэгов.

Нажатие на техническое имя ракурса отображает более детальную информацию о нём: имена и
названия полей, их ABAP-типы данных (см. Рис. 88).

Рис.88.Обзор метаданных CDS-ракурса в Query Browser

Также выводятся сведения об аннотациях в заголовке ракурса (см. Рис. 89).

Рис.89.Обзор аннотаций CDS-ракурса в Query Browser

3.3. Селекционный экран ракурса: работа

VDM в OData
 Переход к аналитическому исследованию данных происходит по нажатию кнопки «Open for
Analysis» (см. Рис. 82). Приведённые рисунки подготовлены в системе S/4HANA 1709. В более
ранних версиях эта кнопка называлась «Open in Design Studio».

Ракурс ZC_FLIGHTBYAIRPORTQUERY имеет параметры: аэропорты вылета и назначения.

Поэтому перед просмотром данных в Query Browser выводится селекционный экран. Аэропорт
вылета был определён как обязательный для заполнения параметр (см. Рис. 90).

Рис.90. Селекционный экран в Query Browser определяется параметрами CDS-ракурса

Поля селекционного экрана имеют справа характерные пиктограммы для выбора значений из
списка: . Нажатие на эту пиктограмму в нашем примере выводит список кодов аэропортов и их
названий. В верхней части окна есть поле контекстного поиска. Например, если нам нужен
аэропорт Нью-Йорка (код JFK), то при наборе первых букв список автоматически фильтруется (см.
Рис. 91).
Рис.91. Контекстный поиск при выборе параметра селекционного экрана

Работа этого списка является хорошей иллюстрацией возможностей VDM. В самом деле: на Рис.88
мы видели, что поля AIRPORTFROM и AIRPORTTO имеют тип CHAR3. Откуда же система берёт
здесь полноценные названия и города? Для ответа вернёмся в ADT и откроем DDL-код ракурса
ZC_FLIGHTBYAIRPORTQUERY. В нём для поля AIRPORTFROM с помощью аннотаций
@Consumption.filter указано, что это должен быть обязательный для ввода параметр, содержащий
ровно одно значение (см. Рис. 92).

Рис.92. Семантические аннотации для параметра AirportFrom

Мы можем как бы «раскрутить назад» иерархию ракурсов VDM, чтобы найти первоисточник
данных для поля AIRPORTFROM. Источником данных ракурса ZC_FLIGHTBYAIRPORTQUERY
является интерфейсный ракурс ZI_FLIGHTBYAIRPORT. В его DDL-коде видим следующую
строчку:

a. ZI_FLIGHT._FlightConnection.AirportFrom

То есть поле AIRPORTFROM приходит из аннотации _FlightConnection, определённой в ракурсе

ZI_FLIGHT. Смотрим код этого ракурса и определение ассоциации (см. Рис. 93).

Рис.93. CDS-ракурс ZI_FLIGHT, определение ассоциации _FlightConnection

Таким образом, источник поля AIRPORTFROM нужно искать в ракурсе ZI_FLIGHTCONNECTION

(см. Рис. 94).
Рис.94. CDS-ракурс ZI_FLIGHTCONNECTION, поле AirportFrom

Как видим, поле AirportFrom заполняется из поля airpfrom стандартной таблицы SPFLI. Ключевым
моментом является использование для этого поля аннотации @ObjectModel.foreignKey.association.
Она указывает на ассоциацию _AirportFrom (а следовательно – на ракурс ZI_AIRPORT) как на
справочник значений для поля AirportFrom. Ранее, разбирая пример с созданием ракурса
ZI_FLIGHTCONNECTION, мы уже упоминали эту аннотацию. Она говорит системе о том, что если
поле AirportFrom нужно будет заполнить на селекционном экране приложения SAPUI5, то в
качестве справочника к полю выбора будут подтягиваться данные из ракурса ZI_AIRPORT.

Теперь посмотрим в DDL-код ракурса ZI_AIRPORT (см. Рис. 95).

Рис.95. CDS-ракурс ZI_AIRPORT. Аннотации, описывающие справочник названий аэропортов

Кратко напомним назначениеиспользованных здесь аннотаций:

 @ObjectModel.representativeKey указывает, что данный ракурс является справочником для значений

из поля Airport
 @ObjectModel.text.element: ['AirportName'] указывает на поле AirportName как на независимый от
языка текст к значениям поля Airport
 @Semantics.text указывает приложениям-потребителям, что поле AirportName не является
аналитикой, а представляет собой только текст, улучшающий визуализацию данных для
пользователей.

Именно эти аннотации позволяют системе выводить в список выбора на селекционном экране не
только трёхсимвольные ключевые значения из справочника аэропортов, но и текстовые пояснения к
ним. Важно подчеркнуть, что такая функциональность доступна только при использовании данных
из VDM через интерфейс OData Service. Например, если бы мы посмотрели Data Preview ракурса
ZC_FLIGHTBYAIRPORTQUERY непосредственно в ADT, то там не было бы никаких текстовых
названий для полей AIRPORTFROM и AIRPORTTO. Но поскольку приложение Query Browser
использует интерфейс OData Service, то здесь доступны все семантические возможности этих
аннотаций.

3.4. Анализ данных с помощью Query Browser

3.4.1 Общие настройки отображения и
фильтрации
 Продолжим работу с ракурсом ZC_FLIGHTBYAIRPORTQUERY. На селекционном экране в Query
Browser укажем аэропорт JFK как аэропорт вылета. Второй необязательный параметр заполнять не
будем (см. Рис. 96).

Рис.96. Заполненный селекционный экран ракурса в Query Browser

Данные, соответствующие заданным критериям выбора будут выведены по умолчанию в

табличном формате (см. Рис. 97).
Рис.97. Вывод данных аналитического ракурса в Query Browser

Развёртка по строкам и столбцам здесь определена тем, какие аннотации

@AnalyticsDetails.query.axis: #ROWS и @AnalyticsDetails.query.axis: #COLUMNS были указаны в
DDL-коде ракурса.

В верхней правой части экрана, над таблицей, видны элементы управления, позволяющие изменять
и настраивать визуализацию. Кнопки, выделенные красным на Рис.98, позволяют переключать
режимы визуализации. Слева направо это будут режимы: только диаграмма, диаграмма и под ней
сводная таблица, только сводная таблица. На Рис. 98 видно, что выбран режим таблицы. Правее
расположена кнопка-«шестерёнка», нажатие на которуювыводит для пользователя ряд
дополнительных настроек. Их выпадающий список также показан на Рис. 98. Наконец, самая правая
кнопка в этом ряду разворачивает визуализацию на всё окно браузера, скрывая всю «шапку»,
расположенную выше

Рис.98. Настройка визуализации данных в Query Browser

Если в списке, показанном на Рис.98, выбрать опцию «Show Prompts», то снова будет выведен
селекционный экран. Это позволит при необходимости изменить критерии выбора. Опцию «Chart
Settings» рассмотрим далее, она позволяет менять визуализацию диаграммы. Опция «Swap Axes»
позволяет за один клик транспонировать табличное отображение данных – то есть поменять
местами строки и столбцы. Иногда это бывает удобно для более наглядного представления
информации (см. Рис. 99).

Рис.99. Результат применения опции Swap Axes

Опция «Totals» позволяет включать/отключать отображение промежуточных итогов в таблице. А

также указывать расположение строчки с итогами – под или над группой строк (см. Рис. 100).
Рис.100. Настройка вывода итоговых строк и результат её действия

Наконец, опция «Information» выводит краткие сведения об аналитическом ракурсе, об

интерфейсном ракурсе, являющемся инфо-провайдером для аналитического. А также сведения об
используемых фильтрах (см. Рис. 101).
Рис.101. Общая информация о ракурсе в Query Browser

Кнопка «Filters» (см. Рис. 97, вверху справа) выводит список всех аналитик и числовых показателей
ракурса, позволяя задать дополнительную фильтрацию данных. В случае с числовыми
показателями (Measures) фильтрация будет означать: визуализируется  показатель или нет.
Например, можно посмотреть только данные по полётам за 19.04.2017 (см. Рис. 102). Чтобы
увидеть новые отфильтрованные данные, нужно нажать кнопку «Go».
Рис.102. Пример дополнительной фильтрации просматриваемых данных

Рядом с каждым фильтром здесь имеется галочка «Show on Filter Bar». Если не включать её, то мы
увидим  результат фильтрации, а справа от кнопки «Filters» будет показано количество наложенных
условий фильтрации. Если же эту галку включить, то после выполнения фильтрации можно будет
нажать кнопку «Show Filter Bar». И тогда будет показано – какое именно условие фильтрации
добавлено (см. Рис. 103). Здесь же критерий фильтрации можно изменить.
Рис.103. Вывод подробной информации о наложенных фильтрах

3.4.2 Настройки отображения отдельных полей

Дополнительные возможности табличной визуализации доступны через контекстные меню
аналитик и показателей. Например, если вызвать это меню правой кнопкой мыши на какой-либо
ячейке столбца «Arrival Airport», то будут доступны опции, показанные на Рис.104.

Рис.104. Контекстное меню отдельной аналитики в Query Browser

Здесь, как видим, можно настроить отображение аналитики (пункт «Display»): только ключ (то есть
трёхсимвольные значения), текст или ключ и текст вместе. Отображение текста для аэропортов
возможно в силу использованных в VDM аннотаций. Так же, как и на селекционном экране выше.
Возможна сортировка таблицы по значениям аналитики: как по ключу, так и по тексту (пункт
«Sort»). Если бы данная аналитика имела иерархии, определённые методами CDS, то показанная на
Рис.104 опция позволит организовать строки таблицы в соответствии с иерархией. Также в пункте
«Totals» доступны настройки вывода или подавления промежуточных итогов (относительно
группировки строк по одинаковым значениям данной аналитики). И подавление вывода строк с
нулевыми значениями числовых показателей. Отдельно на Рис. 104 выделена опция «Attributes».
Она предназначена для вывода в таблицу дополнительных атрибутов аналитики. Для аэропорта
таким дополнительным атрибутом является Time Zone. Доступность именно этого атрибута также
определяется аннотациями из VDM. А сам атрибут на нижнем уровне VDM заполняется в ракурсе
ZI_AIRPORT (см. Рис. 95). Атрибут отображается рядом со своей аналитикой (см. Рис. 105).

Рис.105. Отображение дополнительного атрибута рядом с аналитикой Arrival Airport

Контекстное меню числового показателя содержит две опции (см. рис. 106).
Рис.106. Контекстное меню числового показателя в Query Browser

Опция «Number format» даёт возможность регулировать точность отображения чисел (см. Рис. 107).

Рис.107. Настройка формата отображения числового показателя

Здесь с помощью списка Decimal Places можно изменить количество отображаемых знаков после
запятой. А коэффициент масштабирования (Scaling Factor) позволяет сделать более удобным и
наглядным просмотр больших чисел. Например, если показатель содержит крупные денежные
суммы, то можно установить коэффициент 1000. И тогда суммы будут показаны не в рублях, а в
тысячах рублей. Тем самым числа будут для пользователя выглядеть удобнее, чтобы можно было
бегло оценить их «на глаз».

Опция «Define Conditions» предоставляет очень интересную возможность фильтровать

отображаемые строки по условию. Например, для авиакомпании плохо, когда осталось много
непроданных мест в самолёте. С помощью «Define Conditions» можно определить условие, когда
количество таких мест от 20 и более. Тогда в таблице останутся только строки, удовлетворяющие
этому условию (см. Рис. 108). Как видно из этого рисунка, можно комбинировать и несколько
условий (через кнопку со знаком +). Результат применения условия можно сравнить с исходными
данными на Рис. 100.
Рис.108. Настройка условия и результат его применения к выводимым данным

3.4.3 Работа с диаграммами

Если открыть ракурс в Query Browser и сразу переключиться в режим диаграммы, то система
попытается нарисовать всю ту детализацию, которая предусмотрена по умолчанию. То есть
развёртка по многим аналитикам и вывод сразу всех числовых показателей. Содержательная работа
с таким графиком невозможна (см. Рис. 109).
Рис.109. Вид диаграммы по умолчанию: отражены все аналитики и числовые показатели

Поэтому прежде чем переходить к диаграммам, нужно выбрать только необходимые аналитики и
показатели. Сделать это можно в табличном режиме. Например, сравним количество
нераспроданных мест по авиакомпаниям. В табличном режиме можно убрать все остальные
аналитики из визуализации, используя классический приём drag-and-drop. То есть название
аналитики в разделах ROWS или COLUMNS зажимаем левой кнопкой мыши и перетаскиваем в
раздел DIMENSIONS. Во время перетаскивания курсор характерно изменяется на крестообразный.
В итоге останется только детализация данных по авиакомпаниям (см. Рис. 110).
Рис.110. Для работы с диаграммой оставляем только аналитику Airline

Оставить для работы только нужный показатель можно с помощью кнопки «Filters», о которой уже
говорилось. Выбор фильтра по показателям и результат его применения показаны на Рис. 111.

Рис.111. Работа с фильтром по числовым показателям

Теперь исходная большая сводная таблица приведена к удобному для графического анализа
агрегированному виду. И переключение в режим диаграммы даёт результат, который удобно
воспринимать, оценивать и анализировать (см. Рис. 112). На этом рисунке также видно, что при
наведении курсора на столбец появляется всплывающая подсказка: к какой авиакомпании этот
столбец относится и каково точное значение числового показателя.
Рис.112. Диаграмма, построенная по выбранным аналитикам и показателям

Возвращаясь к опции «Chart Settings» (см. Рис. 98). Наиболее интересной возможностью этого
пункта является выбор типа диаграммы. Например, можно изменить тип диаграммы со столбчатой
на круговую. Это наглядно покажет доли авиакомпаний в ассортименте нераспроданных билетов.
Помимо этого, пункт настройки диаграмм позволяет работать с масштабированием числовых осей
графика.

Часть 9. 
Часть 1  Часть 2  Часть 3  Часть 4  Часть 5  Часть 6  Часть 7  Часть 8

Оглавление
4. KPI MODELER

4.1. Основные этапы работы в KPI Modeler

4.2. Создание KPI

4.3. Создание оценки

4.4. Конфигурирование плитки

4.5. Создание аналитической диаграммы

4.6. Создание альтернативной аналитической диаграммы

4.7. Применение подготовленной KPI-плитки

4. KPI MODELER
4.1. Основные этапы работы в KPI Modeler
Одна из стандартных возможностей, имеющихся в арсенале инструментов Fiori Launchpad – это
создание плиток, визуализирующих уровень одного из ключевых показателей эффективности
бизнеса (KPI). Пользователи могут обычным путём разместить эту плитку на своей стартовой
странице и контролировать важный показатель, не переходя ни в какие дополнительные
приложения. В то же время, если плитка-индикатор (KPI-плитка) покажет неудовлетворительный
уровень показателя, есть возможность открыть отчёт для детального анализа ситуации.
Инструменты, позволяющие конструировать подобные плитки-индикаторы, собраны в группе KPI
Design и носят название KPI Modeler (см. Рис. 113).

Рис.113. Плитки, реализующие функциональность KPI Modeler

Создание KPI-плитки состоит из нескольких этапов. Можно проходить эти этапы не прерываясь,
последовательно, в итоге сразу получив готовую плитку (этот подход будет проиллюстрирован
примерами далее).  Но также можно и повторно использовать объекты, созданные на одном шаге,
чтобы создать несколько вариантов на следующем этапе. Для этого все этапы выведены
отдельными плитками в группе KPI Design. Перечислим эти этапы:

 Создание анализируемого показателя (KPI). На этом этапе нужно указать: какой массив данных будет
использоваться (имя CDS-ракурса и другие технические параметры доступа к данным), какой
числовой показатель из этого массива нужно отслеживать, какое «поведение» показателя считать
«правильным». Под «правильным поведением» понимается бизнес-интерпретация показателя.
Например, если мы отслеживаем сумму оборотов в сети магазинов, то с точки зрения бизнеса этот
показатель «чем больше, тем лучше». А если мы отслеживаем процент отходов сырья на
производстве, то наоборот – чем меньше, тем лучше.
 Следующий этап – создание так называемой оценки. Задача KPI-плитки – это отражение «хорошего»
или «плохого» уровня отслеживаемого показателя. И на этапе оценки нужно указать: какие
конкретно значения являются пороговыми для того, чтобы признать уровень показателя «хорошим»
или «плохим». Кроме того, слово «оценка» имеет здесь ещё один смысл. Нам нужно указать
значения параметров, фильтрующих данные из CDS. Параметры соответствуют тем, которые заданы
в CDS-ракурсе (например, аэропорты вылета и назначения в ракурсе ZC_FLIGHTBYAIRPORTQUERY).
Таким образом, определяется массив оцениваемых данных.
  Третий этап – конфигурирование KPI-плитки. Здесь можно выбрать один из предлагаемых
стандартом вариантов визуализации. И в зависимости от выбранного варианта заполнить ряд
соответствующих параметров.
 Создание детальных отчётов. На этом этапе создаются отчёты (в виде таблиц или диаграмм),
которые пользователь сможет увидеть, если нажмёт на KPI-плитку. Отчётов может быть несколько.
Их задача – используя тот же источник данных, что и плитка, показать пользователю детальный
анализ показателя, чтобы помочь установить причины его негативной динамики.
 На последнем этапе готовая KPI-плитка размещается на Fiori Launchpad. Здесь выполняются те же
действия, как и в примерах, рассмотренных ранее.

Для работы KPI Modeler необходимо выполнить несколько предварительных настроек в системе
Front-End. Во-первых, в транзакции SICF активировать сервис /sap/bc/ui5_ui5/sap/sb_apps_kpis1. Во-
вторых, в транзакции /IWFND/MAINT_SERVICE активировать OData-сервисы
SMART_BUSINESS_RUNTIME_SRV и SMART_BUSINESS_DESIGNTIME_SRV. Как и раньше,
эти сервисы должны использовать Alias, указывающий на систему Back-End. В-третьих,
необходимы те же настройки, которые описаны выше для Query Designer. И те же роли для
пользователя FIORI_ADM, под которым создаются все рассматриваемые здесь примеры.

В следующих разделах создание KPI-плитки будет проиллюстрировано практическим примером,

вновь использующим CDS-ракурс ZC_FLIGHTBYAIRPORTQUERY. В нём есть показатель
«Available Seats» - число нераспроданных мест на авиарейсах. Очевидно, что задача авиакомпаний –
минимизировать значение данного показателя.

4.2. Создание KPI

Итак, в соответствии с намеченным планом, первый этап работы – определить анализируемый
показатель. Это можно сделать, нажав плитку Create KPI (см. Рис. 113). Первый раздел данного
приложения – это общие параметры будущего KPI: его техническое имя, название, направление
«правильного поведения». В нашем примере заполним эти поля так, как показано на Рис. 114.

Рис.114. Параметры KPI

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

Кратко поясним порядок заполнения полей:

 В поле «CDS View» нужно указать имя CDS-ракурса: ZC_FLIGHTBYAIRPORTQUERY. Как обычно, здесь
есть удобная возможность выбора имени из списка, с контекстным поиском.
 Для нашего ракурса создан и активирован OData-сервис, поэтому заполнение следующего поля
«OData Service» становится элементарным: там список доступных сервисов содержит только то
значение, которое нужно.
 Затем также легко заполняется выбором единственной строчки списка и поле «Entity Set». Оно
указывает на тот массив данных, который нужно считывать через ранее выбранный OData-сервис.
Дело в том, что SAP Gateway имеет широкие возможности создания и конструирования сложных
OData-сервисов. В нашем примере сервис ZC_FLIGHTBYAIRPORTQUERY_CDS просто публикует для
приложений-потребителей данные из одного CDS-ракурса. Именно они и образуют единственный
массив данных, доступных через этот сервис. Но в более сложных разработках OData-сервис может
предоставлять доступ к нескольким массивам данных. И тогда список выбора в поле «Entity Set»
будет перечислять все эти массивы.
 Теперь, когда указан массив анализируемых данных, остаётся выбрать из списка в поле «Value
Measure» нужный показатель.

Определение KPI и его источника данных на этом завершено. Переходим к следующему этапу,
нажав кнопку «Activate and Add Evaluation» (см. Рис. 115). Назначение других кнопок,
расположенных рядом, представляется очевидным. При нажатии указанной кнопки появляется
окно, предлагающее поместить создаваемый объект в транспортный запрос. Для целей данного
примера можно указать в этом окне, что созданный KPI является локальным объектом.

4.3. Создание оценки

Приложение создания оценки тоже разделено на несколько групп полей. Первые две группы
описывают параметры и источник данных. Они уже заполнены автоматически теми значениями,
которые были указаны на Рис. 114-115. Обязательным полем здесь является название оценки (см.
Рис. 116).
Рис.116. Название и описание создаваемой оценки

Информацию об источнике данных оставим без изменения и перейдём к следующей группе полей,
определяющих фильтр для отбираемых из CDS-ракурса данных (см. Рис. 117).

Рис.117. Определение фильтра, отбирающего данные для оценки

Поскольку в DDL-коде ракурса только аэропорт вылета был указан как обязательный для
заполнения элемент селекционного экрана, то именно это поле и выведено на Рис. 117. Как и в
случае с Query Browser, выберем для примера фильтрацию по нью-йоркскому аэропорту JFK. Есть
также возможность добавить и необязательные фильтры по другим аналитикам ракурса, если
воспользоваться ссылкой «Optional Filters».

Наконец, в последней группе полей остаётся указать пороговые значения показателя, по которым
создаваемая оценка будет определять: является ли значение хорошим или критическим. На Рис. 114
уже показано, что оцениваемый KPI считается «тем лучше, чем меньше». Оценка работает по
принципу светофора, то есть должна иметь три уровня: хороший (зелёный), тревожный (жёлтый) и
критический (красный). Учитывая это, заполним параметры так, как показано на Рис. 118.
Рис.118. Определение пороговых значений для оценки KPI

Чтобы перейти к следующему этапу работы, нужно нажать кнопку «Activate and Configure Tile».

4.4. Конфигурирование плитки

Прежде всего, необходимо определить тип создаваемой KPI-плитки. На выбор разработчика
предлагается несколько вариантов. В верхней части окна представлены образцы, иллюстрирующие
внешний вид каждого из доступных вариантов (см. Рис. 119).

Рис.119. Возможные варианты KPI-плиток

Выбрать подходящий вариант можно, нажав на него левой кнопкой мыши. При этом состав полей с
настроечными параметрами, расположенных ниже, автоматически изменится в соответствии с
выбранным вариантом (см. Рис. 120). Также подходящий вариант можно выбрать из списка в поле
«Tile Format». Для нашего примера выбран формат Dual Tile. Это формат, предполагающий плитку
увеличенного, двойного размера. В ней как бы расположены рядом сразу две плитки. Слева – общая
оценка для KPI, в которой его числовая величина окрашена цветом в соответствии с пороговыми
значениями. Справа – более детализированный анализ значений KPI.

Первоначально поля «Title» и «Subtitle» заполнены названиями используемых KPI и оценки.

Исправим их, как показано на Рис. 120. Эти названия будут служить заголовком и подзаголовком
плитки, когда она появится на Fiori Launchpad. Любая плитка должна располагаться в каком-то из
каталогов. В поле «Catalog» нужно выбрать из списка каталог Z_RDS_BC (здесь снова удобно
воспользоваться контекстным поиском). Параметр «Cache Duration» определяет – как часто плитка
будет запрашивать обновлённые данные из системы Back-End.

Рис.120. Настроечные параметры для плитки типа Dual Tile

Как уже говорилось, левая часть двойной плитки показывает числовую величину KPI. Это указано в
параметре «Visualization Left», изменить который невозможно. А вот правая часть плитки может
быть настроена. Мы выберем для поля «Visualization Right» вариант Comparison Tile. Этот вариант
позволяет отразить несколько значений KPI в разрезе определённой аналитики. Например, мы
хотим сравнить число нераспроданных мест на рейсах различных авиакомпаний. Поэтому в поле
«Dimension» нужно выбрать из списка аналитику Airline. Теперь значение KPI по каждой
авиакомпании будет отображено в виде горизонтальной полоски (образец такого дизайна можно
видеть на Рис. 119). При этом длина полоски пропорциональна значению KPI. Размеры плитки
ограничены, поэтому дизайн позволяет отобразить только три таких полоски. Какие именно
авиакомпании окажутся видны на плитке, определит условие сортировки в поле «Sorting Order».
Сортировать можно как по числовым значениям KPI, так и по значениям аналитики, указанной в
поле «Dimension». В нашем примере анализируется показатель, значения которого желательно
минимизировать. Поэтому имеет смысл вывести на плитку те авиакомпании, у которых показатели
самые плохие (то есть большие). Для этого выбираем вариант сортировки Measure Descending.

Три полоски расположены друг под другом, чтобы значения показателей было удобно сравнивать.
В зависимости от значения показателя, часть полоски будет раскрашена в том цвете, который
указан в поле «Semantic Color», а часть останется светло-серой. Удобнее всего выбрать контрастный
красный цвет – то есть значение Critical.

Наконец, нужно определить реакцию KPI-плитки на нажатие. В нашем случае необходимо перейти
к аналитическому отчёту (либо диаграмме), детализирующему поведение отслеживаемого
показателя. Это делается заполнением группы параметров «Navigation» как показано на Рис. 121.

Рис.121. Параметры, определяющие переход от плитки к аналитическому отчёту

На этом настройка плитки завершена. Переходим к следующему этапу – настройка аналитического

отчёта. В нашем примере это будет диаграмма, позволяющая визуально сравнить долю
нераспроданных билетов в разрезе авиакомпаний и аэропортов назначения (при том, что аэропорт
вылета уже зафиксирован на Рис. 117).

4.5. Создание аналитической диаграммы

Чтобы от конфигурирования плитки перейти к созданию аналитической диаграммы, нужно в
нижней части страницы нажать кнопку «Save and Configure Drill-Down». Первоначально для плитки
не создано ещё ни одного аналитического отчёта, поэтому открывшееся окно будет пустым. Начать
нужно с нажатия кнопки Configure в нижней части окна. Появится список аналитик (Dimension) и
числовых показателей (Measure), которые доступны для использования в отчёте. Из аналитик
выберем Airline и Arrival Airport. Из показателей выберем Occupied econ. и Available Seats (см. Рис.
122). Такой выбор показателей объясняется тем, что в сумме они дают общее количество мест на
рейсах. Поэтому, оценив их в процентах от общего числа мест, мы всегда будем получать в сумме
100%. Это позволит визуально наглядно оценить соотношения этих показателей как в пределах
одного сочетания «Airline + Arrival Airport», так и в сравнении с другими сочетаниями.
Рис.122. Выбор аналитик и показателей для включения в аналитический отчёт/диаграмму

После выбора аналитик и показателей откроется окно настроек диаграммы. Сами настройки
расположены в левой части, а большую часть окна занимает шаблон, предварительный эскиз,
позволяющий оценить примерный внешний вид диаграммы, соответствующий сделанным
настройкам. В левой верхней части окна расположена область «Measures and Dimensions». В ней
перечислены те аналитики и показатели, которые мы выбрали на Рис. 122. Как и раньше, нас
интересуют в первую очередь «плохие» (то есть большие) значения показателя Available Seats.
Поэтому нужно нажать кнопку Settings (пиктограмма с шестерёнками) справа от этого показателя и
задать сортировку по убыванию (см. рис. 123).

Рис.123. Указание порядка сортировки столбцов в диаграмме

После подтверждения этой настройки внешний вид эскиза диаграммы сразу отразит сделанное
изменение. Также рядом с названием показателя Available Seats появится треугольник-стрелочка,
обозначающее направление сортировки.
Теперь нужно указать, что диаграмма должна сравнивать не абсолютные значения показателей, а их
доли. Для этого переходим в левой части окна к группе настроек «Visualization Type» и для
настройки «Scaling» выбираем значение «Percentage Values». Далее, в поле «View Title» вписываем
заголовок диаграммы. А в настройке «Data» вместо условных данных выбираем отображение
настоящих цифр – «Actual Backend Data» (см. Рис. 124).

Рис.124. Настройки визуализации диаграммы

Остаётся подтвердить сделанные настройки диаграммы нажатием кнопки ОК в нижней части

страницы. На этом все этапы создания и конфигурирования KPI-плитки пройдены. Остаётся только
разместить её на Fiori Launchpad. Но, как уже упоминалось, результаты каждого из этапов могут
быть использованы повторно. Например, после конфигурирования плитки мы создали для неё
аналитическую диаграмму. Можно использовать ту же плитку повторно, создав для неё и другие
диаграммы. Следующий раздел проиллюстрирует это.

4.6. Создание альтернативной аналитической

диаграммы
Для создания второй диаграммы, основанной на той же KPI-плитке, можно воспользоваться двумя
способами. Первый – выбрать инструмент KPI Workspace (см. Рис. 113). Он отображает все
настроенные в системе KPI. И позволяет последовательно выполнить навигацию по всем этапам: от
KPI к его оценке (или списку нескольких оценок), от оценки к плитке, от плитки к аналитическому
отчёту/диаграмме. На каждом из этапов можно вносить правки в соответствующий объект или
создавать новые объекты того же вида (настройки, плитки, диаграммы). Навигация в этом
инструменте достаточно проста и очевидна, поэтому здесь детально не рассматривается.

Второй вариант – сразу перейти к тому шагу, который нужно настроить. Это также делается одной
из плиток, изображённых на Рис. 113. В нашем примере нужно нажать плитку Configure Drill-Down.
Слева откроется список всех имеющихся в системе оценок. Рядом с каждой указано количество
аналитических отчётов, созданных для этой оценки. В списке доступен контекстный поиск. С его
помощью находим нашу оценку, название которой задано на Рис. 116. Результат показан на Рис.
125.

Рис.125. Выбор оценки для создания дополнительного аналитического отчёта

В нижней части страницы нужно нажать кнопку Configure. Над эскизом диаграммы отобразится
набор кнопок, позволяющих редактировать и удалять существующие диаграммы либо создавать
новые. В частности, создание новой диаграммы выполняется нажатием кнопки со знаком + (см.
рис. 126).
Рис.126. Создание дополнительной аналитической диаграммы/отчёта

При нажатии этой кнопки процесс снова начинается с выбора аналитик и показателей, как на Рис.
122. Поэтому без подробностей повторим все описанные настройки. Отличием этой диаграммы от
предыдущей будет то, что она сравнивает не процентные доли, а абсолютные значения показателей.
По умолчанию столбцы с абсолютными значениями расположены один рядом с другим. Но нам
нужно, чтобы оба показателя были отображены разными цветами в одном столбце (как это
показано на эскизе в Рис. 125). Чтобы добиться этого, нужно справа от настроек «Visualization
Type» нажать кнопку Settings (с пиктограммой шестерёнок). И в появившемся окне включить
галочку Enable Stacking (см. Рис. 127).

Рис.127. Дополнительная настройка столбчатой диаграммы

Также в настройке «Scaling» выбираем значение «Absolute Values». В качестве названия диаграммы
естественным будет указать «Departure/Destination (absolute)». Сделанные настройки
подтверждаются нажатием кнопки ОК.

4.7. Применение подготовленной KPI-плитки

Готовую плитку нужно разместить в одной из групп на Fiori Launchpad. Плитка уже была привязана
к каталогу (см. рис. 120). Поэтому остаётся разместить её в группе, например в группе
Z_RDS_BCG, как это было описано ранее.

Чтобы аналитические отчёты, выводящие детальную информацию для плитки, могли корректно
работать, нужно перед их первым запуском сбросить кэш соответствующего OData-сервиса. Для
этого запустить через SAP GUI транзакцию /N/IWFND/CACHE_CLEANUP. В поле Model Identifier
ввести имя OData-сервиса (для нашего примера это был ZC_FLIGHTBYAIRPORTQUERY_CDS). И
снять галочку «Cleanup Cache for all Models» (см. Рис. 128).
Рис.128. Очистка кэша для OData-сервиса

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

нижней части окна SAP GUI сообщением «Model Cache Cleanup finished successfully». Теперь
можно войти в Fiori Launchpad и увидеть размещённую там KPI-плитку (см. рис. 129).

Рис.129. KPI-плитка, размещённая на Fiori Launchpad

При нажатии на плитку открывается сконфигурированная нами аналитическая диаграмма (см. Рис.
130).

Рис.130. Аналитическая диаграмма, запущенная из KPI-плитки

В верхней части окна можно посмотреть зафиксированное в оценке значение фильтра по аэропорту
отправления. При желании можно добавить дополнительные фильтры по другим аналитикам.
Также вверху справа над диаграммой расположены кнопки различных настроек, в том числе
переключение от вида диаграммы к табличному представлению данных. Используя эти настройки,
конечный пользователь может сделать отображение диаграммы более удобным для своих целей,
или даже провести первичный анализ KPI. При этом не потребуется создавать дополнительные
объекты в системе или настраивать полномочия. Отчасти подобные настройки уже рассмотрены
ранее в разделах о Query Browser. В целом они достаточно просты и очевидны, поэтому здесь
подробно не рассматриваются.

В завершение остаётся отметить, что слева над диаграммой есть раскрывающийся список. Он
позволяет перейти к просмотру других диаграмм, созданных для этой плитки (если таковые есть). В
нашем примере этот список содержит две диаграммы, как показано на Рис. 131.

Рис.131. Выбор аналитической диаграммы

Об авторе

Васильев Виталий Вячеславович

Консультант-разработчик по функционалу SAP BW, BO, BI-IP. Опыт работы с SAP-продуктами с

2007 года.

Принимал участие в проектах реинжиниринга SAP-систем (на этапах от концепта до продуктивного

старта и последующей поддержки) в АО «МегаФон Ритейл» и ПАО «МегаФон». Занимался
администрированием и поддержкой BW-системы ТД «ЭРА» (сеть магазинов «Улыбка радуги»),
выполнил оптимизацию производительности системы. Выполнял разработки на проекте ООО
«Лента» (сеть гипермаркетов), занимался сопровождением процесса бюджетирования компании в
модуле SEM-BPS. Успешно осуществил настройку и продуктивный запуск BW в интеграции с
модулями MM, SD, PS на проекте ГК «МонАрх».