Часть 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). Аннотации полей используются для корректной обработки данных движками. Некоторые примеры аннотаций полей:
  • @Semnatics.unitOfMeasure: true – Поле содержит указание единицы измерения (в связке с другим числовым полем-показателем)
  • @Semnatics.currencyCode: true – Поле содержит указание валюты (в связке с другим числовым полем-показателем)
  • @Semantics.quantity.unitOfMeasure: <UOMField> - Поле представляет собой количество (числовой показатель). Единица измерения этого количества содержится в поле <UOMField>. Таким образом, поле, описываемое данной аннотацией, всегда идёт в связке с полем, описанным аннотацией @Semnatics.unitOfMeasure
  • @Semantics.amount.currencyCode: <CurrencyField> - Поле представляет собой денежную сумму (числовой показатель). Валюта, в которой указана эта сумма, содержится в поле <CurrencyField>. Таким образом, поле, описываемое данной аннотацией, всегда идёт в связке с полем, описанным аннотацией @Semnatics.currencyCode
  • @DefaultAggregation: #SUM, #MAX, etc.– Аннотация указывает способ агрегации описываемого числового поля.
  • @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.