Core Data Services for ABAP

Renzo Colle, Ralf Dentzer, Jan Hrastnik

Погрузитесь в моделирование данных с помощью этого всеобъемлющего руководства по основным службам данных ABAP (CDS). Получите навыки, необходимые для создания моделей данных с подробной информацией о синтаксисе CDS, его ключевых компонентах и возможностях. Пройдите пошаговое руководство по моделированию данных приложений в SAP S/4HANA и разработке аналитических и транзакционных моделей приложений.

---

*Оригинал (англ.): Core Data Services for ABAP. Ренцо Колле, Ральф Дентцер, Ян Храстник. Издательство SAP PRESS. Глава 9. 2019, с. 325–385.

Корректура: Олег Точенюк.

Моделирование транзакционных приложений в CDS // SAP Professional Journal Россия, январь–февраль, №1 (78), стр. 110–156. @ 2020, Ренцо Колле, Ральф Дентцер, Ян Храстник.

Эта глава посвящена использованию моделей Core Data Services (CDS) для транзакционных приложений. Это приложения, которые не только считывают данные, но и изменяют их.

Модели CDS не только используются для моделирования и чтения данных, но и формируют базу для моделирования транзакционных аспектов, определяя, таким образом, дополнительные объекты и поведение приложений, которые изменяют данные. В целом, данные можно создавать, изменять или удалять посредством прямого ввода пользователем через пользовательский интерфейс (UI) или машинные интерфейсы, например, через средства связи между приложениями (application-to-application, A2A).

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

В данной главе показано, как определить транзакционное приложение. Соответствующие особенности, которые необходимо учесть, описаны в Разделе 9.1. В Разделе 9.2 также показано, как работает транзакционная инфраструктура в SAP S/4HANA, как определить модели транзакционных объектов и реализовать их бизнес-логику (см. статью «Транзакционные приложения и инфраструктура в SAP S/4HANA» в этом номере SAP Professional Journal Россия, — №1, 2020). В эту бизнес-логику входят блокировки, полномочия и проверки данных, а также динамический контроль свойств, действия и вычисляемые поля (Раздел 9.3. — см. статью «Модели транзакционных объектов в SAP S/4HANA» в этом номере журнала).

Далее мы будем использовать эти приложения в различных сценариях с применением моделей транзакционных сервисов (Раздел 9.4. — см. статью «Модели транзакционных сервисов в SAP S/4HANA» в этом номере журнала).

Транзакционные приложения и инфраструктура в SAP S/4HANA*

Показано, как определить транзакционное приложение. Описаны соответствующие особенности, которые необходимо учесть, описаны. Показано, как работает транзакционная инфраструктура в SAP S/4HANA, как определить модели транзакционных объектов и реализовать их бизнес-логику.

---

*Оригинал (англ.): Core Data Services for ABAP. Ренцо Колле, Ральф Дентцер, Ян Храстник. Издательство SAP PRESS. Разделы 9.1, 9.2. 2019, с. 325–330.

Корректура: Олег Точенюк.

Транзакционные приложения и инфраструктура в SAP S/4HANA // SAP Professional Journal Россия, январь–февраль, №1 (78), стр. 111–156. @ 2020, Ренцо Колле, Ральф Дентцер, Ян Храстник.

Транзакционные приложения (раздел 9.1)

Из предыдущих глав вы узнали, как используются ракурсы CDS при моделировании доступа для чтения. Вопрос в том, можно ли, а если да, то как, использовать эту семантически обогащённую модель для создания сценариев доступа с правом записи. Особенно при работе с этими моделями через интерфейсы на базе архитектуры REST (передача состояния представления) в сети Интернет становится очевидным, что операции чтения и записи в идеальном сценарии должны выполняться на базе одной модели. В этом разделе представлены основные сведения и специфичные аспекты транзакционных приложений.

Бизнес-объекты

Бизнес-объекты логически объединяют несколько сущностей (entity). В качестве примера бизнес-объекта мы уже рассматривали заказ клиента, который состоит, помимо прочего, из данных заголовка, данных позиций и графика поставок. Между ними установлены композиционные взаимосвязи, поэтому экзистенциально они не зависят от соответствующей родительской сущности. Несмотря на то, что для чтения бизнес-объекты играют второстепенную роль, они формируют контекст, который очень важен при записи. Обычно несколько сущностей одного бизнес-объекта обрабатываются и записываются вместе. Другие упоминаемые или привязанные сущности часто только считываются или имеют собственную реализацию для доступа с правом записи.

Полномочия и блокировка

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

Бизнес-логика

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

Действия

Для изменения данных и бизнес-объектов можно использовать элементарные операции: создание, изменение или удаление (вместе с чтением они называются операциями управления данными (CRUD)). Однако бизнес-логика часто выводится в более комплексных операциях, которые содержат несколько изменений, обеспечивая непротиворечивость обработки операций. Операции такого типа вызываются в следующих действиях. Действия помогают снять с конечного пользователя или потребителя ответственность за бизнес-логику или непротиворечивость множественных изменений. Они обеспечивают повышенное удобство при считывании повторяющихся изменений. Если требуется, действия также могут явно контролировать расширенные полномочия. Рассмотрим это в Раздел 9.3.6 на примере.

Трудности при работе с CDS и SAP S/4HANA

В контексте CDS ABAP и предлагаемых функциях произошли дополнительные изменения. Во-первых, в настоящее время CDS ABAP предлагает только определения данных, например, ракурсы CDS и таблицы CDS для моделирования данных. По определению эти сущности поддерживают только доступ для чтения. Таким образом, с чисто технической точки зрения соответствующие операции SQL для изменения данных должны выполняться непосредственно через таблицы базы данных или внутри этих таблиц. Инфраструктура может автоматически делегировать доступ с правом записи моделям CDS только в том случае, если модели CDS представляют собой простую проекцию таких таблиц базы данных. При использовании более комплексной логики SQL в моделях или ракурсе CDS создание, запись или поиск данных и базы данных для записи больше не являются простой задачей, а иногда вообще невозможны. По сути, в модели виртуальных данных (VDM) SAP S/4HANA, которая выводится как семантически обогащённая модель, структура данных коренным образом упрощена во многих аспектах в отношении существующих таблиц базы данных и модели хранения, поэтому объединения, соединения и другие функции также применяются для определения моделей CDS VDM.

Транзакционная инфраструктура в SAP S/4HANA (раздел 9.2)

Сервер приложений или база данных

На этом этапе может возникнуть вопрос, на каком уровне должна быть реализована и интегрирована бизнес-логика. В среде ABAP ответ достаточно однозначен: бизнес-логика (в том понимании, в котором мы говорим о ней здесь) выполняется на сервере приложений и реализуется в ABAP. Это обусловлено масштабируемостью серверов приложений и подробной бизнес-логикой SAP S/4HANA, которая, разумеется, должна быть понятной и применяемой. Такой подход не противоречит цели перевода логики с обработкой большого объёма данных в базу данных. В оптимальном варианте базу данных SAP HANA следует использовать, разумеется, для всех операций чтения с мэппингом трансформаций, насколько возможно, посредством SQL при чтении данных. Этот подход разумным образом также можно применять в транзакционной логике.

Эффективное использование базы данных SAP HANA

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

CDS и BOPF

Платформа ABAP позволяет использовать модели CDS в качестве базы для моделирования транзакционных приложений. В этом контексте необходимо учитывать все требования, определённые в предыдущем разделе для транзакционных приложений или соответствующей инфраструктуры. Для этого в транзакционную среду выполнения интегрирована структура обработки бизнес-объектов (Business Object Processing Framework; BOPF), которая является частью платформы ABAP и учитывает все эти аспекты. На момент написания этой книги (весна 2019 года) это единственный способ интеграции транзакционной логики в CDS, который поддерживается платформой ABAP для внедрения приложения на базе CDS. Интеграция других транзакционных структур или реализаций за пределами BOPF в настоящее время не поддерживается, но планируется в будущих версиях (а именно, модель программирования ABAP RESTful).

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

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

Дополнительные ресурсы

Для получения дополнительной информации о BOPF см. статью BOPF: разработка бизнес-объектов (BOPF: Business Object Development) Джеймса Вуда (James Wood) и Джозефа Руперта (Joseph Rupert), издательство SAP PRESS, sap-press.com/ 4300, а также руководство «Начало работы со структурой обработки бизнес-объектов» (Getting Started with Business Object Processing Framework) в сообществе SAP Developers Network (SDN) по адресу http://s-prs.co/ v482207 и соответствующую документацию к платформе ABAP по адресу http://s-prs.co/v482208.

В примерах мы постоянно используем редактор BOPF в Eclipse, поскольку недоступные для BOPF на базе CDS функции здесь даже не предлагаются. Большая часть транзакционных расширений пока не интегрирована в синтаксис CDS, но управляется с помощью аннотаций. В этой главе указаны все аннотации, влияющие на модель BOPF, с описанием результатов такого влияния.

Главное правило заключается в том, что моделирование данных или объектов для бизнес-объекта и его свойств выполняется посредством CDS. Изменить эту информацию в модели BOPF, созданной на их основе, невозможно. Моделирование поведения, т. е. определение бизнес-логики (средства выбора и вычисления данных, а также проверки непротиворечивости и действия), выполняется в модели BOPF.

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

Первичный ключ и модель данных BOPF

Для операций изменения вызывается инфраструктура BOPF для релевантного бизнес-объекта BOPF. Всем пользователям, знакомым с BOPF, известно, что эта структура создана на основе технического ключа типа RAW16 (глобальный уникальный идентификатор [GUID]) в среде выполнения. Однако базовая модель CDS может не иметь такого ключа. Обычно она содержит семантические ключи. По этой причине во время выполнения создаётся временный технический ключ, для которого выполняется мэппинг по фактическому семантическому ключу связанных сущностей. На данный момент платформа ABAP не предоставляет общий интерфейс доступа к определённому таким образом бизнес-объекту. Поэтому пользователь интерфейсов BOPF (уровня сервисов BOPF) также должен получить доступ и выполнить преобразование ключа из семантического ключа сущности и временного технического ключа BOPF.

SADL и OData

Мы будем рассматривать работу с приложениями через веб-стандарты REST и OData, поскольку платформа ABAP уже предоставляет реальную сквозную поддержку этих стандартов. Например, в данном случае инфраструктура обрабатывает не только указанные выше ключи, но и обеспечивает маршрутизацию обращений с правом чтения и записи. Все нетранзакционные запросы на чтение и аналитические запросы делегируются напрямую базе данных SAP HANA через интерфейс Open SQL. Транзакционные запросы на чтение и запись данных передаются в транзакционную среду выполнения (BOPF) и транзакционный буфер сервера приложений. Таким образом, сочетается оптимальное использование базы данных SAP HANA с обработкой всех постоянных данных при всех преимуществах транзакционной среды выполнения на сервере приложений ABAP и возможности применения существующей бизнес-логики.

Для перевода запросов GET OData в запросы SQL используется инфраструктура Service Adaptation Definition Language (SADL) на платформе ABAP. Инфраструктура SADL разработана для чтения и обработки данных на базе моделей.

Дополнительные ресурсы

Для получения дополнительной информации о SADL посетите портал SAP Help Portal по адресу https:// help.sap.com и введите в строке поиска Consuming Business Entities with SADL (http://s-prs.co/v482202).

Схематичное представление инфраструктуры ABAP для транзакционных приложений с наиболее важными динамическими компонентами показано на Рис. 9.1.

Рис. 9.1. Инфраструктура ABAP для транзакционных приложений

Модели транзакционных объектов в SAP S/4HANA*

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

---

*Оригинал (англ.): Core Data Services for ABAP. Ренцо Колле, Ральф Дентцер, Ян Храстник. Издательство SAP PRESS. Раздел 9.3. 2019, с. 331–370.

Корректура: Олег Точенюк.

Модели транзакционных объектов в SAP S/4HANA // SAP Professional Journal Россия, январь–февраль, №1 (78), стр. 115–156. @ 2020, Ренцо Колле, Ральф Дентцер, Ян Храстник.

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

Определение моделей объектов (раздел 9.3.1)

Композиционная структура

Как было сказано выше, бизнес-объекты определяются как древовидные или композиционные структуры сущностей. Для описания бизнес-объектов в сети сущностей и привязок CDS помечается корень композиционного дерева, а релевантные привязки (association) определяются как композиции. Чтобы пометить корень, используйте следующую аннотацию для соответствующего ракурса CDS:

@AbapCatalog.sqlViewName: 'ZISALESORDERTP'

@AbapCatalog.compiler.compareFilter: true

@AccessControl.authorizationCheck: #CHECK

@EndUserText.label: 'Sales Order'

@ObjectModel.modelCategory: #BUSINESS_OBJECT

@ObjectModel.compositionRoot: true

define view ZI_SalesOrderTP

as selectfrom ZI_SalesOrder

association [0..*] to ZI_SalesOrderItemTP as _SalesOrderItem

on $projection.SalesOrder = _SalesOrderItem.SalesOrder

{

key SalesOrder,

SalesOrderType,

SalesOrganization,

DistributionChannel,

OrganizationDivision,

DeliveryStatus,

DeletionIndicator,

CreatedByUser,

CreationDateTime,

LastChangedByUser,

LastChangeDateTime,

@ObjectModel.association.type: [#TO_COMPOSITION_CHILD]

_SalesOrderItem

}

Листинг. 9.1. Ракурс CDS для заказа клиента

@ObjectModel.compositionRoot: true

Композиционные привязки к подсущностям помечаются следующей аннотацией:

@ObjectModel.association.type: #TO_COMPOSITION_CHILD

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

@ObjectModel.association.type: #TO_COMPOSITION_PARENT

@ObjectModel.association.type: #TO_COMPOSITION_ROOT

Чтобы явно пометить бизнес-объект как таковой, используйте следующую аннотацию для корневой сущности, представляющей бизнес-объект:

@ObjectModel.modelCategory: #BUSINESS_OBJECT

Эта аннотация не является релевантной во время выполнения и имеет значение только для семантической категоризации в контексте VDM.

Уровень транзакционных ракурсов

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

Бизнес-объект и корневая сущность

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

Пример: бизнес-объект

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

Определите заголовок заказа клиента, как показано в Листинге 9.1. Здесь уже имеется дочерняя привязка к позиции заказа клиента, определённой в Листинге 9.2. Новые аннотации выделяются соответствующим образом.

@AbapCatalog.sqlViewName: 'ZISALESORDERITTP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales OrderItem'
define view ZI_SalesOrderItemTP
as selectfrom ZI_SalesOrderItem
association [1..1] to ZI_SalesOrderTP as _SalesOrder
on $projection.SalesOrder = _SalesOrder.SalesOrder
association [0..*] to ZI_SalesOrderScheduleLineTP
as _SalesOrderScheduleLine
on $projection.SalesOrder =
_SalesOrderScheduleLine.SalesOrder
and $projection.SalesOrderItem =
_SalesOrderScheduleLine.SalesOrderItem
{
key SalesOrder,
key SalesOrderItem,
Product,
OrderQuantity,
OrderQuantityUnit,
NetAmount,
TransactionCurrency,
CreatedByUser,
CreationDateTime,
LastChangedByUser,
LastChangeDateTime,
@ObjectModel.association.type: [#TO_COMPOSITION_PARENT,
#TO_COMPOSITION_ROOT]
_SalesOrder,
@ObjectModel.association.type: [#TO_COMPOSITION_CHILD]
_SalesOrderScheduleLine
}

Листинг. 9.2. Ракурс CDS для позиции заказа клиента

В Листинге 9.2 представлена позиция заказа клиента с привязками к заголовку заказа клиента и графику поставок, определённому в Листинге 9.3.

@AbapCatalog.sqlViewName: 'ZISALESORDERSLTP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales OrderScheduleLine'
define view ZI_SalesOrderScheduleLineTP
as selectfrom ZI_SalesOrderScheduleLine
association [1..1] to ZI_SalesOrderTP as _SalesOrder
on $projection.SalesOrder = _SalesOrder.SalesOrder
association [1..1] to ZI_SalesOrderItemTP as _SalesOrderItem
on $projection.SalesOrder = _SalesOrderItem.SalesOrder
and $projection.SalesOrderItem =
_SalesOrderItem.SalesOrderItem
{
key SalesOrder,
key SalesOrderItem,
key SalesOrderScheduleLine,
DeliveryDate,
OrderQuantity,
OrderQuantityUnit,
CreatedByUser,
CreationDateTime,
LastChangedByUser,
LastChangeDateTime,
@ObjectModel.association.type: [#TO_COMPOSITION_ROOT]
_SalesOrder,
@ObjectModel.association.type: [#TO_COMPOSITION_PARENT]
_SalesOrderItem
}

Листинг. 9.3. Ракурс CDS для графика поставки по заказу клиента

В Листинге 9.3 показан график поставок по заказу клиента с привязками к заголовку заказа клиента в качестве корневой сущности и к позициям заказа клиента в качестве родительской сущности.

Активация ракурса CDS

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

Определение моделей транзакционных объектов (раздел 9.3.2)

Модель транзакционных объектов

Теперь рассмотрим, как можно определить модель транзакционных объектов для модели данных бизнес-объекта. Поскольку с точки зрения сущностей и привязок модель уже полностью определена, достаточно пометить корневую сущность, чтобы разрешить использование транзакционной среды выполнения для бизнес-объекта. Для этого применяется аннотация @ObjectModel.transactionalProcessingEnabled:true в корневой сущности бизнес-объекта.

Однако, как было сказано выше, при работе с ракурсами CDS встречаются объекты базы данных, которые изначально разрешают только доступ к данным в режиме чтения. Теоретически в простых случаях можно установить доступ с записью в корректные таблицы согласно определению ракурса с учётом аспектов создания ракурса и присвоения ему псевдонима. Однако в инфраструктуре всегда должно присутствовать явное указание таблицы базы данных, в которую выполняется запись. Эту таблицу необходимо указать для каждой сущности с помощью аннотации @ObjectModel.writeActivePersistence:’<имя таблицы базы данных>’. Указанная таблица базы данных должна иметь такую же структуру, как и ракурс CDS, или быть совместимой с ним. Также требуются соответствующие имена полей (в верхнем регистре согласно ABAP).

Пример: добавление аннотаций

В нашем примере модель расширяется новыми аннотациями с соответствующим выделением для заголовка заказа клиента в Листинге 9.4.

@AbapCatalog.sqlViewName: 'ZISALESORDERTP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales Order'
@ObjectModel.modelCategory: #BUSINESS_OBJECT
@ObjectModel.compositionRoot: true
@ObjectModel.transactionalProcessingEnabled: true
@ObjectModel.writeActivePersistence: 'ZSALESORDER'
define view ZI_SalesOrderTP
…

Листинг. 9.4. Ракурс CDS для заказа клиента с транзакционными аннотациями

В Листинге 9.5 представлены аннотации для позиции заказа клиента.

@AbapCatalog.sqlViewName: 'ZISALESORDERITTP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales OrderItem'
@ObjectModel.writeActivePersistence: 'ZSALESORDERITEM'
define view ZI_SalesOrderItemTP
…

Листинг. 9.5. Ракурс CDS для позиции заказа клиента с транзакционными аннотациями

В Листинге 9.6 представлены соответствующие аннотации для графика поставки по заказу клиента.

@AbapCatalog.sqlViewName: 'ZISALESORDERSLTP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales OrderScheduleLine'
@ObjectModel.writeActivePersistence: 'ZSALESORDERSLINE'
define view ZI_SalesOrderScheduleLineTP
…

Листинг. 9.6. Ракурс CDS для графика поставки по заказу клиента с транзакционными аннотациями

Модель BOPF

Если вы добавили эти аннотации, при активации корневого ракурса CDS автоматически создаётся бизнес-объект BOPF. В результате активируется транзакционная среда выполнения. Если установить курсор на пиктограмме слева от аннотации, появится информация о созданном объекте (см. Рис. 9.2). Для прямого перехода к бизнес-объекту BOPF используйте отображаемую здесь ссылку «Бизнес-объект» (Business Object).

Рис. 9.2. Бизнес-объект BOPF, сгенерированный из CDS

Имя бизнес-объекта BOPF совпадает с именем корневого ракурса CDS. Имена узлов в бизнес-объекте BOPF соответствуют именам ракурсов CDS для отдельных подсущностей. Композиционным привязкам к дочерним узлам также присваивается то же самое имя. На Рис. 9.3 показаны соответствующие элементы в ракурсе Eclipse Обзор (Outline) для BOPF. В общем смысле мы будем называть сущностями ракурс CDS и связанный узел BOPF.

Рис. 9.3. Бизнес-объект BOPF: обзор модели BOPF

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

Привязки к другим сущностям или бизнес-объектам в BOPF не требуются и не могут быть созданы. Альтернативные ключи DB_KEY, PARENT_KEY и ROOT_KEY можно игнорировать. Они требуются только технически для инфраструктуры, поскольку в данном примере выбрана модель с семантическим ключом. Действие LOCK_... рассматривается в Раздел 9.3.4. Более подробно действия с именем ACTION_AND_FIELD_CONTROL описаны в Раздел 9.3.7.

На Рис. 9.4 обзорно представлен бизнес-объект BOPF. В отображаемой ссылке на ракурс CDS напрямую указан его источник. Отсюда можно перейти к структуре узлов в древовидном ракурсе или просмотреть подробные данные узла.

Рис. 9.4. Обзор бизнес-объектов BOPF

На Рис. 9.5 показан пример корневого узла. Здесь очень хорошо видно, что автоматически создаётся не только сам бизнес-объект BOPF, но и различные объекты ABAP-словаря (ABAP DDIC), а также классы ABAP.

Рис. 9.5. Бизнес-объект BOPF: корневой узел

Удаление модели BOPF

В случае удаления модели CDS модель BOPF и все дополнительно созданные артефакты разработки сохраняются. В данном случае необходимо удалить модель BOPF и все прочие релевантные объекты разработки вручную для очистки всех артефактов. Поскольку все созданные объекты разработки относятся к тому же пакету, что и ракурс CDS, найти их достаточно просто.

Тестовая среда BOPF

Созданный таким образом бизнес-объект BOPF теперь позволяет получать доступ через транзакционный интерфейс — уровень сервисов BOPF. Данные можно считывать посредством уровня сервисов BOPF. Например, как показано на Рис. 9.6, это можно выполнить с помощью тестовой среды BOPF.

Рис. 9.6. Тестовая среда BOPF с данными

Тестовую среду можно запустить напрямую с помощью ABAP Development Tools (ADT) в Eclipse для бизнес-объекта BOPF в древовидной структуре. Для этого выберите «Выполнить • Выполнить как • Тестовая среда» (Run • Run As • Test Environment). С помощью этого инструмента также можно осуществлять навигацию по всей модели. Указанные в Раздел 9.2 технические ключи не входят в модель CDS (поскольку эта модель работает с семантическими ключами).

Загрузка экземпляров узлов в тестовую среду

В настоящее время определить запрос в модели BOPF невозможно, поэтому данные необходимо всегда загружать в тестовую среду с явным указанием ключа. В модели на базе GUID для этого применяются собственные ключи BOPF (DB_ KEY), а в нашей модели с семантическими ключами — автоматически создаваемые альтернативные ключи. Их имена совпадают с именами собственных ключей BOPF, но структура соответствует семантическому ключу вашей модели CDS.

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

Использование существующих хранилищ и таблиц базы данных

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

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

Определение статических свойств (раздел 9.3.3)

Активация изменений

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

Статические свойства определяются с помощью следующих аннотаций.

• @ObjectModel.createEnabled:true

  Эта аннотация используется для создания экземпляров сущности.

• @ObjectModel.updateEnabled:true

  Эта аннотация используется для изменения экземпляров сущности.

• @ObjectModel.deleteEnabled:true

  Эта аннотация используется для удаления экземпляров сущности.

• @ObjectModel.readOnly:true

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

• @ObjectModel.mandatory:true

  Эта аннотация используется для указания обязательных полей для обеспечения непротиворечивости экземпляра бизнес-объекта с точки зрения бизнес-данных.

Пример: транзакционные аннотации

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

Перейдём к заполнению модели соответствующими транзакционными аннотациями. В заголовке заказа клиента вы определяете возможность создания и изменения (но не удаления напрямую) заказа клиента, как показано в Листинге 9.7. Как было сказано выше, последнее ограничение также применяется в случае отсутствия соответствующей аннотации. Однако добавление аннотации делает модель более удобной для чтения.

@AbapCatalog.sqlViewName: 'ZISALESORDERTP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales Order'
@ObjectModel.modelCategory: #BUSINESS_OBJECT
@ObjectModel.compositionRoot:true
@ObjectModel.transactionalProcessingEnabled:true
@ObjectModel.writeActivePersistence: 'ZSALESORDER'
@ObjectModel.createEnabled: true
@ObjectModel.updateEnabled: true
@ObjectModel.deleteEnabled: false
define view ZI_SalesOrderTP
as selectfrom ZI_SalesOrder
association [0..*] to ZI_SalesOrderItemTP as _SalesOrderItem
on $projection.SalesOrder = _SalesOrderItem.SalesOrder
{
@ObjectModel.readOnly: true
key SalesOrder,
@ObjectModel.mandatory: true
SalesOrderType,
@ObjectModel.mandatory: true
SalesOrganization,
@ObjectModel.mandatory: true
DistributionChannel,
@ObjectModel.mandatory: true
OrganizationDivision,
DeliveryStatus,
@ObjectModel.readOnly: true
DeletionIndicator,
@ObjectModel.readOnly: true
CreatedByUser,
@ObjectModel.readOnly: true
CreationDateTime,
@ObjectModel.readOnly: true
LastChangedByUser,
@ObjectModel.readOnly: true
LastChangeDateTime,
@ObjectModel.association.type: [#TO_COMPOSITION_CHILD]
_SalesOrderItem
}

Листинг. 9.7. Ракурс CDS для заказа клиента со статическими транзакционными свойствами