Модель программирования на ABAP для SAP Fiori*

Стефан Хаас, Бинс Мэтью

В этой статье рассматривается модель программирования на ABAP для SAP Fiori, доступная с версии SAP S/4HANA 1610, SPS 03 или SAP NetWeaver Application Server для ABAP 7.52, SP 02. Это стандартная модель разработки для новых приложений SAP S/4HANA. Она отражает базовую архитектуру SAP S/4HANA, описанную в главе 1 книги «ABAP Development for SAP S/4HANA. ABAP Programming Model for SAP Fiori» (Издательство SAP PRESS, 2019).

* ABAP Development for SAP S/4HANA. ABAP Programming Model for SAP Fiori. Стефан Хаас, Бинс Мэтью. Издательство SAP PRESS. Глава 3. 2019, с. 95-117.

ПВ общем, данная модель поддерживает разработку оптимизированных для SAP HANA сервисов OData для приложений SAP Fiori на основе ракурсов Core Data Services (CDS) и охватывает сценарии для аналитических и транзакционных приложений, а также для приложений поиска. При разработке приложений с использованием модели программирования различаются два основных сценария: приложения только для чтения и транзакционные приложения. Приложения только для чтения требуют наличия базовой модели данных CDS и специфичной для приложения аналитики или аннотаций для поиска. Модель данных CDS и её аннотации выводятся в виде сервиса OData с использованием технологии Service Adaptation Description Language (SADL).

Транзакционные приложения в дополнение к приложениям только для чтения требуют создания бизнес-объекта Business Object Processing Framework (BOPF) для выполнения операций создания, обновления и удаления, а также реализации дополнительной бизнес-логики посредством действий, проверок и выбора BOPF. Далее рассмотрим различные технологии, связанные с моделью программирования на ABAP.

1. Core Data Services

Core Data Services (CDS) — это основа для всех видов приложений SAP S/4HANA. Их развёртывание выполняется поверх прежних или новых таблиц SAP ERP. Они позволяют разрабатывать семантически насыщенные модели данных с передачей кода в базу данных SAP HANA. Они разрабатываются в стеке ABAP и поэтому используют стандартные средства управления жизненным циклом для объектов разработки ABAP. Например, они переносятся между системами с помощью стандартной транспортной системы переносов ABAP (CTS).

При активации ракурса CDS создаются два объекта: соответствующий ракурс словаря данных (DDIC) в ABAP-словаре (@AbapCatalog.sqlViewName) и ракурс SAP HANA в базе данных. Переносится только определение ракурса CDS. Для него существует запись в репозитарии объектов R3TR DDLS .

Для включения различных сценариев приложений ракурсы CDS, определяемые с использованием языка определения данных (DDL) для CDS, можно расширить посредством аннотаций различных видов.

  • Аналитические аннотации
    Для использования ракурса CDS в качестве куба данных или запроса в сценариях аналитических приложений посредством аналитического механизма требуется наличие аннотаций @Analytics.
  • Аннотации для UI
    Аннотации для ракурсов CDS можно определит с помощью аннотаций интерфейса пользователя (@UI). Это позволяет указать, где будут размещаться определенные сущности, поля и данные в приложении шаблона элементов SAP Fiori, что существенно сокращает требуемый код фронтэнда JavaScript SAPUI5. Аннотации интерфейса пользователя можно перенести в файл расширения метаданных с типом репозитария объектов R3TR DDLX, чтобы не загромождать ракурс CDS аннотациями интерфейса пользователя.
  • Аннотации для поиска
    Ракурсы CDS можно сконфигурировать для сценариев поиска с помощью аннотаций @Search, например, в качестве модели корпоративного поиска (ESH) для поиска на панели запуска SAP Fiori или встроенных в приложения SAP Fiori функций поиска, определив объем текстового поиска в SAP HANA и степень соответствия.
  • Транзакционные аннотации
    Для активации возможностей транзакционной обработки (создание, запись, удаление) в дополнение к функциям поиска или аналитики можно создать объект BOPF для сущности CDS посредством транзакционных аннотаций @ObjectModel.

На рис. 1 представлен обзор потока разработки модели программирования на ABAP с используемыми объектами. Как видим, CDS находится в центре потока разработки и, например, базиса сервиса OData, который, в свою очередь, используется приложением SAP Fiori или бизнес-объектом BOPF для транзакционной обработки.

Рисунок 1

Рис. 1. Обзор потока разработки модели программирования на ABAP и его объекты

2. SAP Gateway

SAP Gateway играет огромную роль в предоставлении удобного доступа, базирующего на не ABAP коде, к бизнес-данным, которые хранятся в бэкэнд-системах SAP NetWeaver. Доступ к бизнес-данным предоставляется с помощью сервисов OData на базе REST с использованием HTTP в качестве основного протокола передачи данных.

Что касается SAP NetWeaver версии 7.40, компонент программного обеспечения SAP_GWFND устанавливается в рамках стандарта SAP NetWeaver и включает в себя полный объем функциональности для активации хаба и бэкэнда. Вообще, с точки зрения архитектуры, существует два подхода к развёртыванию: встроенное развёртывание и развёртывание через хаб. Развёртывание через хаб далее подразделяется на разработку в хабе и разработку в бэкэнд-системе. Стандартная настройка локальной системы SAP S/4HANA показана на рис. 2. Обычно разработка выполняется в бэкэнд-системе ABAP, а хаб-система используется для обработки дополнительной нагрузки по клиентским запросам OData к компоненту SAP Gateway. Для такой настройки требуется дополнительна система SAP NetWeaver, функционирующая как хаб-система или фронтэнд-сервер SAP Gateway, а также доверительное RFC-соединение между хабом и бэкэнд-системой для передачи запросов из фронтэнда в бэкэнд-систему, которая содержит бизнес-логику и данные. Для передачи данных из фронтэнда в бэкэнд используется функциональный модуль с RFC /IWBEP/FM_MGW_HANDLE_REQUEST.

Рисунок 2

Рис. 2. Общий обзор стандартной настройки системы SAP S/4HANA с SAP Gateway в качестве отельной хаб-системы

Приложение SAP Fiori, выполняемое в браузере, отправляет запросы OData HTTP GET, POST, DELETE или PUT в систему SAP Gateway, которая выводит все зарегистрированные и активированные сервисы OData. SAP Gateway передаёт входящие запросы OData в бэкэнд по доверительному RFC-соединению. Во время выполнения OData в бэкэнде выбор фактических данных делегируется на уровень структуры SADL. Если запрос является доступным только для чтения запросом GET, SADL делегирует запрос механизму обработки очереди, который создаёт SQL-инструкцию SELECT для выбора данных запрошенной сущности OData из таблиц базы данных через соответствующий ракурс CDS. Если доступ предполагает возможность записи, например, POST для создания или PUT для обновления, запрос будет делегирован для выполнения в транзакционный BOPF-объект с обработкой обновлений базы данных согласно предоставленным транзакционным аннотациям из ракурса CDS.

3. OData

OData — это протокол данных на базе REST для переноса бизнес-данных и метаданных между бэкэнд-системой ABAP и клиентскими приложениями с помощью хаб-системы SAP Gateway. В SAP S/4HANA клиентскими приложениями сервисов OData обычно являются приложения SAP Fiori SAPUI5, выполняемые в локальных браузерах на устройствах конечных пользователей, например, на настольных ПК или планшетах. Вместе с SAP Gateway OData предоставляет доступ к бизнес-данным в бэкэнд-системе SAP простым и удобным способом посредством протокола передачи данных HTTP.

3.1. Обзор

Сервис OData организует данные в форме сущностей с набором свойств, объединённых взаимосвязями. Эти элементы напоминают элементы моделей данных CDS, поэтому модели данных CDS являются идеальным средством вывода сервисов OData.

Чтобы понять структуру сервиса OData, посмотрите на сервисный документ и документ метаданных сервиса. Сервисный документ содержит список сущностей или ресурсов, к которым можно обращаться посредством данного сервиса или запрашивать посредством /sap/ opu/odata/sap//. Кроме того, определить, позволяет ли сервис создавать, изменять или удалять сущности, можно по атрибутам sap:creatable, sap:updatable и sap:deletable тега , который также содержит относительную ссылку на набор сущностей через его атрибут href (см. рис. 3).

Рисунок 3

Рис. 3. Сервисный документ для простого документа закупки и сервис OData для позиции документа закупки

Cервисный документ метаданных содержит намного более подробные данные, чем сервисный документ, и отражает все метаданные сервиса. Для его запроса используется опция $metadata: /sap/opu/odata/sap/<OData_service_name>/$metadata. С её помощью можно просмотреть все сущности сервиса вместе с их свойствами и связями.

OData использует команды REST HTTP POST, GET, PUT и DELETE для создания, считывания, обновления и удаления сущностей (CRUD). OData также определяет простой, но мощный язык запросов для ограничения набора результатов, предоставляемого SAP Gateway. В табл. 1 представлены самые распространённые опции запроса OData.

Таблица 1

Табл. 1. Самые важные опции запроса OData

3.2. Создание сервиса OData

Как вы уже знаете, данные можно напрямую выбрать из ракурса CDS с помощью Open SQL на ABAP, как при выборе данных из таблицы обычной базы данных. Однако для приложения SAP Fiori требуется представление данных с помощью сервиса OData и протокола передачи данных HTTP.

В настоящее время модель данных CDS можно вывести как сервис OData тремя разными способами: автоматическое представление, ссылочный источник данных (RDS) или источник данных с мэппингом (MDS).

Автоматическое представление

Самым простым, но при этом накладывающим наибольшие ограничения способом вывода модели CDS в виде сервиса OData является использование аннотации заголовка @OData.publish:true (листинг 1).

    @AbapCatalog.sqlViewName: ‘SQL_VIEW_NAME’
    …
    @OData.publish: true
    define view CDS_VIEW_NAME as select from …
    

Листинг 1. Аннотация заголовка @OData.publish:true для вывода простой и непротиворечивой модели данных CDS в виде сервиса OData

При активации ракурса в инструментах разработки на ABAP в Eclipse в системе создаются несколько объектов (рис. 4):

  • Фактический объект активации сервиса Business Suite SAP Gateway с именем <VIEW_NAME>_CDS (тип объекта: R3TR IWSV)
  • Модель SAP Gateway с именем <CDS_VIEW_NAME>_MDL (тип объекта: R3TR IWMO)
  • Модель аннотации с именем <CDS_VIEW_NAME>_CDS_VAN (тип объекта: R3TR IWVB)
  • По умолчанию созданный сервис OData деактивирован. Его необходимо активировать вручную с помощью транзакции /IWFND/MAINT_SERVICE в хаб-системе SAP Gateway.
Рисунок 4

Рис. 4. Компоненты и операции для вывода модели данных CDS в виде сервиса OData с помощью автоматического представления

Автоматическое представление для создания сервиса OData используется только для простых непротиворечивых моделей CDS, которые состоят из корневого узла и связанных ракурсов первого уровня. Добавить к сервису дополнительные несвязанные или не относящиеся к первому уровню ракурсы CDS в виде сущностей OData невозможно. Например, если определена непротиворечивая модель корневого ракурса документа закупки с привязкой к нижестоящему ракурсу позиции документа закупки, а ракурс позиции, в свою очередь, привязан к ракурсу материалов, сущность материала не может являться частью сервиса, поскольку это привязка не первого уровня для корневого узла (рис. 5). При необходимости можно использовать другой подход.

Рисунок 5

Рис. 5. Объем создания сервиса OData методом автоматического представления

 

Ссылочный источник данных

Для комплексных моделей ракурсов CDS, которые требуется представить как сущности OData в общем сервисе OData, следует выбрать ссылочный источник данных (RDS). Модель CDS можно рассматривать как комплексную, если для нее определены привязки нескольких уровней или корневые ракурсы. Однако для применения RDS требуется создать проект построителя сервиса SAP Gateway. Для этого необходимо выполнить следующие шаги:

1. Откройте транзакцию SEGW.

2. Нажмите кнопку Создать проект на панели инструментов (рис. 6).

Рисунок 6

Рис. 6. Создание нового проекта построителя сервисов SAP Gateway

3. В появившемся диалоговом окне Создание проекта (рис. 7) введите имя и описание проекта SAP Gateway, который создаётся как переносимая запись репозитария ABAP (R3TR IWPR Z_PURCHASING_DEMO). В этой записи IWPR означает Активация бизнес-процесса шлюза: проект построителя сервиса. Нажмите Дальше.

Рисунок 7

Рис. 7. Построитель сервисов SAP Gateway: создание диалога проекта

После создания проекта можно приступить к созданию сервиса OData. Сначала необходимо создать модель данных. Для сценария RDS модель данных создаётся со ссылкой на модель CDS. Поэтому выберите Ссылка • Источник данных в контекстном меню папки Модель данных (рис. 8).

Рисунок 8

Рис. 8. Создание модели данных с помощью ссылки на источник данных CDS

Откроется Мастер ссылочного источника данных (рис. 9). Необходимо указать ракурс CDS, который требуется вывести как сущность OData в сервисе OData (обычно корневой ракурс или один из корневых ракурсов модели CDS).

Рисунок 9

Рис. 9. Ввод корневого ракурса CDS для ссылочной модели CDS

В следующем шаге мастера (рис. 10) можно выбрать связанные ракурсы для выбранного ранее ракурса CDS, и включить их в определение модели сервиса OData.

Рисунок 10

Рис. 10. Выбор связей корневого ракурса CDS

После завершения работы с мастером появится новая папка с именем Папка ссылок на источники данных. Если открыть подпапку Представление через SADL и выбрать узел Представление сущностей CDS, появятся выбранные ранее сущности CDS, которые будут представлены как сущности OData (рис. 11).

Рисунок 11

Рис. 11. Выведенные сущности CDS в проекте построителя сервиса

Добавить любые дополнительные сущности CDS можно также с помощью кнопки Добавить сущность CDS. Это делает сценарий RDS намного более гибким, чем автоматическое представление. Наконец, сервис OData можно создать с помощью кнопки Создать динамические объекты на панели инструментов, которая автоматически создаёт динамические объекты сервиса и регистрирует их в бэкэнд-системе.

При первом создании сервиса появится диалоговое окно Модель и определение сервиса, в котором можно изменить имена объектов по умолчанию (рис. 12). Как видим, сценарий RDS также позволяет создавать класс провайдера модели (MPC) и класс провайдера данных (DPC) с соответствующими подклассами расширения с суффиксами MPC_EXT и DPC_EXT. MPC обеспечивает динамическое представление ссылочной модели данных CDS в виде документа метаданных сервиса. DPC предоставляет фактические данные сущности путём делегирования входящих запросов общему механизму SADL, который прозрачно выбирает данные из ракурсов CDS и выполняет их мэппинг с сущностями OData.

Рисунок 12

Рис. 12. Диалоговое окно Модель и определение сервиса

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

 

Источник данных с мэппингом

Сценарий для источника данных с мэппингом (MDS) используется только в том случае, если невозможно применить предыдущие сценарии, например, если сервис содержит сущности OData, отличные от CDS. Для создания сервиса OData с помощью сценария MDS требуется выполнить намного больше операций вручную, чем в сценарии RDS и автоматического представления. Как и в сценарии RDS здесь необходимо создать проект построителя сервиса SAP Gateway. Для этого выполняется транзакция SEGW. Далее необходимо определить модель данных. Это выполняется вручную или (для ракурсов CDS) путём импорта имени ракурса ABAP SQL ракурса CDS в виде структуры DDIC. Для этого выберите Импорт • Структура DDIC в контекстном меню папки Модель данных (рис. 13). Далее в папке Реализация сервиса выберите сущность и нажмите Мэппинг с источником данных.

Рисунок 13

Рис. 13. Мэппинг сущности OData с источником данных

Выберите ракурс CDS, с которым требуется выполнить мэппинг сущности OData (рис. 14). Такой мэппинг позволит выбрать данные на основе модели с помощью механизма SADL, и вам не придётся создавать код для методов CRUD сущности OData вручную.

Рисунок 14

Рис. 14. Мэппинг сущности OData и бизнес-сущности CDS

Наконец, необходимо вручную выполнить мэппинг сущности OData по полям сущности CDS путём перетаскивания этих полей с панели Модель SADL в правой части экрана на экран таблицы мэппинга в центре (Рис. 15).

Рисунок 15

Рис. 15. Мэппинг полей сущности CDS с полями сущности OData

Помимо сущностей источника данных с мэппингом вы также можете создать сущности и реализовать их методы CRUD в классе DPC_EXT из первого создания сервиса. Как видим, в сценарии MDS выполняется больше операций вручную, чем в описанных ранее, но при этом обеспечивается более высокая степень гибкости при создании сервиса. Этот сценарий поддерживает доступ к общим данным моделей CDS SADL и реализацию сущностей OData вручную на основе ABAP.

 

Активация сервиса в хаб-системе SAP Gateway

Для всех сценариев мы пропустили шаг активации сервиса в каталоге сервисов хаб-системы SAP Gateway. Рассмотрим этот шаг. Транзакция /IWFND/MAINT_SERVICE используется для ведения всех зарегистрированных сервисов, а также для регистрации и активации новых сервисов. Это центральная точка входа для работы с сервисами OData. Для добавления нового сервиса нажмите кнопку Добавить сервис (Рис. 161). Откроется другое приложение для добавления незарегистрированных бэкэнд-сервисов в каталоге сервисов системы SAP Gateway 2. Чтобы найти определенный сервис в бэкэнд-системе, необходимо предоставить псевдоним бэкэнд-системы, в которой был создан сервис, а также техническое имя сервиса, например, <CDS_VIEW_NAME>_CDS в случае автоматического представления. Наконец, можно добавить сервис в каталог сервисов, выбрав соответствующую строку и нажав кнопку Добавить выбранные сервисы

Рисунок 16

Рис. 16. Добавление нового сервиса OData в каталог сервисов

 

4. Service Adaptation Description Language (SADL)

Одной из базовых технологий в модели программирования на ABAP для SAP Fiori является Service Adaptation Description Language (SADL). В данном контексте эта технология предоставляет две основные функции:

  • Во время проектирования SADL поддерживает создание сервиса OData на основе модели данных CDS.
  • Во время выполнения входящие запросы для сущностей OData делегируются в адаптер SADL с динамическим созданием SQL-инструкций SELECT для выбора бизнес-данных через ракурсы CDS или последующего делегирования запросов в транзакционную среду выполнения BOPF, если требуется доступ с правом записи.

Таким образом, SADL поддерживает два этапа разработки сервиса OData из трех:

  • Определение модели данных (поддерживается SADL).
  • Реализация сервиса (поддерживается SADL).
  • Ведение сервиса.

4.1. Этап определения модели данных

Целью этого этапа разработки сервиса OData является предоставление потенциальным клиентам сервиса информации о структуре сервиса, например, организации его сущностей, их взаимосвязях и поддерживаемых операциях. Эта информация предоставляет в виде документа метаданных сервиса в формате XML. На этапе определения модели данных SADL создаёт мэппинг сущностей CDS в модели данных сущности OData (EDM) и заполняет MPC в реализации OData информацией из структуры модели CDS. Дополнительно выполняется мэппинг типов данных в полях CDS с элементарными типами данных EDM, например, мэппинг встроенного типа данных ABAP-словаря DATS с типом данных EDM.DateTime. Кроме того, если для сущностей CDS активирована транзакционная обработка посредством создания бизнес-объекта BOPF, действия BOPF появятся как операции импорта функции OData в документе метаданных сервиса. В табл. 2 представлен обзор мэппинга объектов CDS и OData, выполняемый SADL.

Таблица 2

Табл. 2. Сопоставление концепций моделей данных CDS и OData EDM

На рис. 17 показано, как выглядит документ метаданных сервиса в простом сценарии, описанном в главе 1 книги «ABAP Development for SAP S/4HANA. ABAP Programming Model for SAP Fiori». Как вы помните, ракурс CDS для документа закупки (Z_PurchasingDocumentDDL) был привязан к ракурсу позиций документа закупки (Z_PurchasingDocumentItemDDL). Теперь оба ракурса отображаются как типы сущностей OData в документе метаданных сервиса OData вместе с информацией о связях между этими двумя сущностями и их кардинальности. Поддерживаемые сущностью операции определяются атрибутами sap:creatable, sap:updatable и sap:deletable элемента EntitySet. В следующем примере сервис не поддерживает доступ с правом записи, поскольку мы не активировали транзакционную среду выполнения для модели CDS посредством создания бизнес-объекта BOPF. Поэтому сервис поддерживает только доступ для чтения через HTTP-запросы сущности GET. Как было сказано выше, файл метаданных сервиса OData можно запросить по пути $metadata, /sap/opu/ odata/sap/<OData_service_name>/$metadata.

Рисунок 17

Рис. 17. XML-документ метаданных сервиса в простом сценарии CDS из главы 1 с выводом в виде сервиса OData

4.2. Этап внедрения сервиса

На предыдущем этапе определения модели данных SADL выполняет мэппинг модели данных CDS с EDM OData и создаёт статическое определение сервиса. Во время выполнения SADL также обеспечивает обработку выполняемых клиентами запросов OData. Среда выполнения OData делегирует запросы OData общему механизму обработки запросов SADL, который создает SQL-инструкцию SELECTS в ракурсах CDS на основе параметров запроса ($select, $top, $filter и т.д.) и запрошенной сущности OData.

Входящий запрос OData для базовой сущности ракурса стандартного заказа на поставку представлен в листинге 2.

        GET I_PurchaseOrderEntity?$select= PurchaseOrder,PurchaseOrderType,PurchasingOrganization,PurchasingGroup,Purchas eOrderDate&$top=10&$orderby=PurchaseOrderDate asc&$filter=
        ( PurchaseOrderDate ge datetime'2018-01-
        01T00:00:00' and PurchaseOrderDate le datetime'2018-12-31T00:00:00')
                

Листинг 2. Запрос OData GET для сущности OData I_PurchaseOrderEntity

Далее структура SADL прозрачно преобразует этот запрос в SQL-инструкцию SELECT в ракурсе CDS I_PurchaseOrder (листинге 3).

       SELECT
PurchaseOrder, PurchaseOrderType, PurchasingOrganization, PurchasingGroup, PurchaseOrderDate
FROM
I_PurchaseOrder WHERE
PurchaseOrderDate GE '20180601'
AND PurchaseOrderDate LE '20180601' ORDERBY
PurchaseOrderDate ASCENDING UP TO 10 ROWS
            

Листинг 3. Сгенерированная SQL-инструкция SELECT для запроса OData GET

При сравнении запроса OData и сгенерированной SQL-инструкции запросы OData можно передать в реляционную базу данных, поскольку OData уже напоминает SQL, а для всех параметров OData можно выполнить мэппинг с определенным компонентом SQL-инструкции SELECT. Это свойство делает OData идеальным вариантом для представления бизнес-сущностей по HTTP, поскольку простое преобразование HTTP-запросов в SQL-инструкции SELECT реализует парадигму SAP HANA «код-данные» без ненужной обработки данных на сервере ABAP. В табл. 3 представлен мэппинг между параметрами OData и компонентами запроса SQL.

Таблица 3

Табл. 3. Мэппинг между параметрами OData и соответствующими компонентами SQL-инструкции SELECT

 

5. Структура обработки бизнес-объектов

Структура обработки бизнес-объектов (BOPF) — это структура ABAP, которая представляет собой транзакционную среду выполнения приложения в модели программирования на ABAP для SAP Fiori. Если приложению требуются действия с записью (CUD), на основе модели данных CDS необходимо создать бизнес-объект BOPF, который будет отвечать за транзакционный компонент приложения. В настоящее время поддерживаются четыре транзакционных сценария, описанные в следующих подразделах.

5.1. Приложение только для чтения с быстрыми действиями

В данном случае активировать полный доступ с правом создания, записи и удаления не требуется. Необходимо только быстрое действие, например, для изменения статуса бизнес-объекта. Бизнес-объект BOPF для данного сценария можно создать путём определения аннотаций для корневого ракурса модели CDS на уровне заголовка, см. листинг 4.

        @ObjectModel: {
                transactionalProcessingEnabled: true,
                compositionRoot: true,
                writeActivePersistence: '<SQL View>',
                createEnabled: false,
                updateEnabled: false,
                deleteEnabled: false
                    }
            

Листинг 4. Необходимые аннотации для создания бизнес-объекта BOPF с целью реализации быстрых действий

(Повторная) активация ракурса приведёт к созданию бизнес-объекта BOPF, что позволит реализовать быстрые действия на ABAP для соответствующего узла BOPF. Мы также должны обеспечить активное хранение с помощью аннотации writeActivePersistence. Однако в данном случае мы запрещаем стандартный доступ (CUD), он будет разрешён только для мэппинга полей между CDS и BOPF.

Примечание.

При выводе ракурса CDS как сервиса OData с помощью автоматического представления или сценария RDS технология SADL учитывает аннотации CDS createEnabled, updateEnabled и deleteEnabled и выполняет их мэппинг с атрибутами набора сущностей OData. Например, если ракурс CDS не предоставляет доступ к правом записи или вообще не имеет связанного бизнес-объекта BOPF, соответствующий набор сущностей OData будет иметь те же атрибуты sap:creatable= ”false”, sap:updatable=”false” и sap:deletable=”false”.

5.2. Новое приложение без черновика

Если также требуется разрешить стандартный общий доступ с правами на CUD, необходимо установить для аннотаций createEnabled, updateEnabled и deleteEnabled значение true (листинг 5). Кроме того, необходимо предоставить таблицу базы данных, в которую данные должны будут сохраняться с помощью аннотации writeActivePersistence.

         @ObjectModel: {
                transactionalProcessingEnabled: true,
                compositionRoot: true,
                writeActivePersistence: '<ActivePersistenceName>',
                createEnabled: true,
                updateEnabled: true,
                deleteEnabled: true
                }
            

Листинг 5. необходимые аннотации для полной поддержки CUD BOPF

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

5.3. Приложение с черновиком

В этом сценарии данные не записываются немедленно в стандартные активные таблицы базы данных, а хранятся в черновой таблице. Этот сценарий очень хорошо подходит для прежних приложений, которые уже состоят из таблиц базы данных и кода CUD на ABAP с комплексной бизнес-логикой. Можно активировать старые таблицы базы данных для доступа с правом чтения, оптимизированного для SAP HANA, реализовав ракурсы CDS поверх таблиц базы данных и по-прежнему использовать прежний ABAP-код при активации черновика. В этом контексте активация означает перенос данных из промежуточной черновой таблицы в актуальную таблицу. Для этого корневой узел бизнес-объекта BOPF предоставляет адаптер (/bobf/if_frw_draft~copy_draft_to_active_entity), который внедряется разработчиком и выполняет мэппинг черного представления данных с прежней сигнатурой кода на ABAP для записи данных в прежние таблицы базы данных. Необходимые аннотации для создания черновой версии инфраструктуры показаны в листинге 6.

            @ObjectModel: {
                    transactionalProcessingEnabled: true,
                    compositionRoot: true,
                    draftEnabled: true;
                    writeDraftPersistence: '<DraftPersistenceName>',
                    createEnabled: true,
                    updateEnabled: true, deleteEnabled: true
                    }
            

Листинг 6. Необходимые аннотации для создания черновой версии инфраструктуры BOPF для прежнего приложения с существующим хранилищем

5.4. Новое приложение с черновиком

В этом сценарии предоставляются новые таблицы для черновых и активных сущностей (листинг 7). Как и в предыдущем сценарии данные сохраняются в промежуточных черновых таблицах и записываются в активное хранилище только при явной активации сущности. Однако в этом сценарии BOPF будет полностью отвечать за транзакционную обработку. Расширить обработку данных мы можем только путём добавления действий, проверок или выбора BOPF для соответствующих узлов объекта BOPF. Этот сценарий подходит только для новых приложений. Если прежние таблицы и код ABAP CUD будут использоваться повторно, данный сценарий не является целесообразным вариантом.

            @ObjectModel: {
                        transactionalProcessingEnabled: true,
                        compositionRoot: true,
                        draftEnabled: true;
                        writeDraftPersistence: '<DraftPersistenceName>',
                        writeActivePersistence: '<ActivePersistenceName>',
                        createEnabled: true,
                        updateEnabled: true,
                        deleteEnabled: true
                        }
            

Листинг 7. Необходимые аннотации для создания черновой версии инфраструктуры BOPF для нового положения

6. SAP Fiori

Открытый доступ к бизнес-данным бэкэнда через OData и SAP Gateway позволяет использовать для просмотра и обработки бизнес-данных современные технологии интерфейса пользователя, отличные от ABAP. Поэтому интерфейс пользователя приложений, разработанный с использованием модели программирования на ABAP для SAP Fiori полностью основан на системе SAPUI5, которая реализует дизайн SAP Fiori. Компонент пользовательского интерфейса в приложениях обычно реализуется с помощью облачной среды SAP Web IDE на базе приложений с элементами SAP Fiori или произвольных приложений. Приложения с элементами SAP Fiori, например, шаблоны для отчёта на основе списка и страницы объектов, а также компоновочные планы применяют форматы на базе метаданных сервиса OData и аннотации для интерфейса пользователя, определенные в ракурсах CDS или соответствующих расширениях метаданных. Поэтому шаблоны с элементами SAP Fiori до минимума сокращают объем работы с кодом SAPUI5 JavaScript для фронтэнда и значительно увеличивают производительность разработчика благодаря гибкости в использовании предварительно определенных точек расширения во фронтэнде.

Дополнительно прозрачным для разработчика образом приложения с элементами SAP Fiori реализуют необходимую обработку запросов CRUD для приложений с правами только для чтения, с черновиком или без черновика в зависимости от того, какой сценарий BOPF был проаннотирован, сгенерирован и реализован в бэкэнде. В отличие от элементов SAP Fiori произвольные приложения обеспечивают для фронтэнд-разработчика полный гибкость при проектировании интерфейса пользователя и разработке логики, но требуют больших трудозатрат на этапе разработки. Формат и средства управления интерфейса пользователя должны объявляться разработчиком вручную. Также потребуется реализовать необходимую логику JavaScript SAPUI5. Поэтому использовать сложные сценарии BOPF с черновиком при работе с произвольными приложениями не рекомендуется, поскольку в этом случае становится слишком сложно обеспечить эффективное взаимодействие необходимых запросов. Более того, при разработке произвольных приложений существует риск нарушения принципов проектирования SAP Fiori. Следовательно, использовать произвольные приложения следует только в том случае, когда требуемый дизайн интерфейса пользователя невозможно реализовать посредством одного из компоновочных планов с элементами SAP Fiori.

7. Заключение

В этой статье обзорно рассматривается модель программирования на ABAP для SAP Fiori и связанные технологии. Сначала мы рассмотрели CDS — центральный элемент разработки любого приложения для SAP S/4HANA. Это основа для всех видов приложений. CDS конфигурируются для разных видов приложений с помощью специфичных для домена пользовательских интерфейсов, аналитики, аннотаций поиска и транзакционных аннотаций. Далее мы изучили технологии SAP Gateway и OData, которые обеспечивают удобный сетевой доступ к бизнес-данным, хранящимся в бэкэнд-системах SAP NetWeaver. После этого мы уделили внимание технологии SADL и поддержке доступа к сущностям CDS для чтения и выполнения транзакций на основе моделей через OData. BOPF представляет собой транзакционную среду выполнения модели программирования на ABAP для SAP Fiori и позволяет выполнять операции CUD на ABAP для моделей данных на основе ракурсов CDS. Эта технология предоставляет несколько сценариев для разных требований к приложениям, которые мы кратко перечислили и описали.