RAP: бизнес-объекты, транзакции и EML#

Эта статья частично раскрывает MOD-07, MOD-08 и MOD-09 на основе документации SAP ABAP Cross-Product и ABAP Platform 2025 FPS02. Она объясняет основные границы модели, но не является пошаговой инструкцией по созданию приложения в конкретной системе. Имена объектов, доступные функции, язык ABAP и правила расширения зависят от редакции и версии.

Из каких частей состоит бизнес-объект#

В RAP бизнес-объект (BO) объединяет модель данных, объявленное поведение и исполняющую это поведение инфраструктуру. Обычно данные описаны CDS-сущностями. Корневая сущность задаёт точку входа, дочерние сущности входят в композиционное дерево. Behavior definition описывает операции и свойства сущностей; behavior pool содержит пользовательскую реализацию тех частей, которые не предоставляет выбранный runtime. Потребитель обращается к объекту напрямую через EML либо к опубликованному business service.

Разделяйте внутреннюю модель BO и её проекцию для конкретного сервиса. Проекция ограничивает публикуемые элементы и операции, но не должна незаметно менять предметный смысл корневой сущности, ключа или композиции. Service definition и service binding образуют отдельную границу публикации. Сам факт наличия CDS-представления ещё не означает, что оно стало изменяемым бизнес-объектом или опубликованным API.

Для финансового примера можно спроектировать синтетический BO «запрос на перенос бюджета»: корень содержит компанию, период и статус, дочерние строки - источник, получателя и сумму с валютой. Команда отправки на согласование меняет статус запроса; она не проводит перенос бюджетной суммы в SAP. Такое моделирование помогает обсуждать ключи, инварианты и жизненный цикл, но не заменяет стандартную функцию бюджетирования, FI-FM или AVC.

Managed или unmanaged#

Выбор реализации определяет, какую часть транзакционной работы принимает на себя framework.

• В managed BO стандартные операции и управление транзакционным буфером предоставляет RAP runtime. Разработчик добавляет предметные правила: determinations, validations, actions и другие предусмотренные моделью расширения.
• В unmanaged BO разработчик реализует обязательные части контракта и сам отвечает за транзакционный буфер и согласование изменений с существующей логикой хранения. Этот вариант может подойти для обёртки ранее реализованного процесса, но увеличивает объём обязанностей по корректности.

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

Проверки, вычисления и явные действия#

У трёх расширений разный смысл.

• Validation проверяет условие и может запретить сохранение экземпляра. Ошибки и сообщения возвращаются через структуры RAP FAILED и REPORTED. Проверка не должна сама запускать изменение через EML. Не полагайтесь на заранее заданный порядок нескольких validations с одним триггером.
• Determination автоматически вычисляет или устанавливает значения при заданном изменении. Повторный запуск при тех же входных данных должен давать тот же результат. Поэтому расчёт итоговой суммы запроса по его строкам естественнее выразить determination, если этот инвариант принадлежит самой модели.
• Action представляет явную предметную операцию, например «отправить запрос на согласование». Она вызывается потребителем или из другой реализации через EML и выполняет предусмотренную бизнес-логику. Не прячьте необратимый внешний эффект в determination, которую runtime может вызвать повторно.

Триггеры, фаза выполнения, поддержка draft и допустимые действия зависят от типа реализации. В частности, SAP документирует ограничения для некоторых unmanaged-сценариев: отдельные validations и determinations поддерживаются только для draft instances. Проверяйте конкретный контракт и версию; не переносите поведение одного варианта реализации на все RAP BO.

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

EML и транзакционная граница#

Entity Manipulation Language (EML) - типизированный ABAP-интерфейс к RAP BO. Через него можно читать сущности, изменять их стандартными операциями, выполнять actions и работать с ассоциациями. Операция доступна только если она объявлена для соответствующей сущности и реализована согласно контракту. EML позволяет применять поведение BO без OData-клиента; это не превращает обращение в произвольную запись в базовую таблицу.

Изменения EML сначала находятся в транзакционном буфере RAP. Внешний вызывающий код в подходящем сценарии завершает RAP LUW через COMMIT ENTITIES; ROLLBACK ENTITIES сбрасывает изменения текущего буфера. Внутри обработки поведения точку сохранения контролирует RAP runtime. Не вставляйте COMMIT WORK в локальную логику handler-метода: это может нарушить единый порядок сохранения BO и участников одной SAP LUW. Для автоматизированной проверки BO вне behavior pool SAP предоставляет EML-тестовый сценарий с явным завершением RAP LUW.

IN LOCAL MODE требует особой осторожности. Внутри реализации собственного BO оно позволяет EML обойти проверки authorization и feature control, которые иначе выполняются на внешней границе. Это может быть уместно для внутреннего шага уже авторизованного сценария, но только если вызывающий путь действительно гарантирует необходимые права. При потреблении чужого или released BO локальный режим не является способом отменить контракт доступа. Не используйте его как универсальное исправление отказа.

Согласование параллельных изменений#

Два механизма защищают разные моменты изменения.

• Optimistic concurrency сравнивает версию прочитанной записи с текущей версией, обычно через ETag при OData-взаимодействии. Оно обнаруживает, что пользователь отправил изменение поверх устаревшего состояния.
• Pessimistic concurrency блокирует изменение объекта на время заданной RAP транзакции. В managed BO runtime выполняет стандартную блокировку; unmanaged реализации должны обеспечить необходимые обязанности сами. Для draft жизненный цикл блокировки отдельный.

Для BO важны обе гарантии: актуальность клиентского снимка и отсутствие несовместимой одновременной записи. Ключи и уникальность при создании проверяйте отдельно: блокировка существующего экземпляра не доказывает, что другой клиент не создаёт тот же ключ. В модели с корнем и дочерними строками укажите lock master и зависимые сущности так, чтобы область блокировки соответствовала бизнес-инвариантам, не захватывая несвязанные документы.

Проектная проверка до реализации#

1. Зафиксируйте release, ABAP language version, редакцию и доступные released APIs.
2. Опишите корневой объект, композиции, ключи, обязательные поля, валюту, единицы и владельца состояния.
3. Выберите managed или unmanaged по существующему storage и логике, а не по привычке.
4. Для каждого правила определите: это validation, determination, action или отдельная координация процесса?
5. Определите внешний service/API contract отдельно от внутреннего behavior.
6. Опишите EML-потребителя, authorization boundary, commit/rollback и требуемый результат при ошибке.
7. Проверьте ETag, enqueue lock, draft и уникальность на двух параллельных изменениях.
8. Подготовьте тесты для повтора determination, отказа validation, неуспешного сохранения, устаревшего ETag, конфликта ключа и отката всего BO.

Источники#

Источники зарегистрированы как metadata_only: локальные снимки и хеши страниц не сохранены. Код примера намеренно не представлен как активируемый RAP-артефакт; проверок ABAP syntax, ATC, ABAP Unit или SAP runtime для этого материала не проводилось.

• ABAP RESTful Application Programming Model, ABAP Cross-Product
• Defining and Implementing Behavior of the Business Object
• Developing Unmanaged Transactional Apps, ABAP Platform 2025 FPS02
• Validations
• Determinations
• Actions
• Concurrency Control
• Entity Manipulation Language (EML)
• Pessimistic Concurrency Control (Locking)

RAP: business objects, transactions, and EML#

This article partially covers MOD-07, MOD-08, and MOD-09 based on SAP ABAP Cross-Product and ABAP Platform 2025 FPS02 documentation. It explains core model boundaries, but it is not a step-by-step guide for building an application in a particular system. Object names, available features, ABAP language versions, and extension rules depend on the edition and release.

What a business object contains#

In RAP, a business object (BO) combines a data model, declared behavior, and the runtime infrastructure that executes that behavior. Data is typically described by CDS entities. The root entity defines the entry point; child entities belong to its composition tree. A behavior definition declares operations and entity properties; a behavior pool contains the custom implementation for the parts not provided by the selected runtime. A consumer accesses the object directly through EML or through a published business service.

Separate the internal BO model from its projection for a specific service. A projection limits the elements and operations that are published, but should not silently change the domain meaning of the root entity, key, or composition. A service definition and service binding form a separate publication boundary. The existence of a CDS view alone does not make it a modifiable business object or a published API.

A synthetic financial example is a “budget transfer request” BO: the root contains the company, period, and status; child rows contain source, recipient, and amount with currency. A submit-for-approval operation changes the request status; it does not post a budget transfer in SAP. This model helps discuss keys, invariants, and lifecycle, but does not replace standard budgeting, FI-FM, or AVC functionality.

Managed or unmanaged#

The implementation type determines how much transactional work the framework takes over.

• In a managed BO, the RAP runtime provides standard operations and transactional-buffer handling. The developer adds domain rules through determinations, validations, actions, and other supported extensions.
• In an unmanaged BO, the developer implements essential parts of the contract and is responsible for the transactional buffer and consistency with existing persistence logic. It may suit a wrapper around an existing process, but it increases the responsibilities for correctness.

This is not a distinction between a “new” and “old” interface. Choose based on ownership of the data and existing business process. Before deciding, record who checks keys and authorization, who changes state, how inconsistent writes are rejected, where the save boundary lies, and which component releases locks. A superficial unmanaged wrapper is not safe just because it reuses an existing table or function.

Checks, calculations, and explicit actions#

These three extensions have different purposes.

• A validation checks a condition and can prevent an instance from being saved. Errors and messages are returned through RAP structures FAILED and REPORTED. A validation should not itself start a modification through EML. Do not rely on a predefined order among multiple validations with the same trigger.
• A determination automatically calculates or sets values when a specified change occurs. Repeated execution with the same inputs should produce the same result. Calculating a request total from its rows is therefore a natural determination when that invariant belongs to the model itself.
• An action represents an explicit domain operation, such as “submit the request for approval.” It is called by a consumer or another implementation through EML and performs the intended business logic. Do not hide an irreversible external side effect in a determination that the runtime may execute again.

Triggers, execution phases, draft support, and permitted operations depend on the implementation type. SAP documents restrictions for some unmanaged scenarios: particular validations and determinations are supported only for draft instances. Check the contract and release in question; do not generalize behavior from one BO implementation type to all RAP BOs.

Make an error actionable: identify the affected instance keys, an appropriate message type, and the field to which it applies. The consumer can then show the result next to the data and correct the specific condition. A concurrent-change conflict, an authorization error, and a violated business rule are different causes and should not be hidden behind one generic message.

EML and the transaction boundary#

The Entity Manipulation Language (EML) is a typed ABAP interface to RAP BOs. It can read entities, modify them through standard operations, execute actions, and work with associations. An operation is available only if it is declared for the relevant entity and implemented according to its contract. EML allows a BO to be used without an OData client; it does not turn the call into arbitrary writes to the underlying tables.

EML changes first reside in the RAP transactional buffer. In an appropriate caller scenario, external code ends the RAP LUW with COMMIT ENTITIES; ROLLBACK ENTITIES resets changes in the current buffer. During behavior processing, the RAP runtime controls the save point. Do not insert COMMIT WORK in a local handler method: this may break the unified save order for the BO and participants in one SAP LUW. For automated BO checks outside a behavior pool, SAP provides an EML test scenario with explicit completion of the RAP LUW.

IN LOCAL MODE requires particular care. Inside an implementation of its own BO, it allows EML to bypass authorization and feature-control checks that otherwise apply at the external boundary. This may be appropriate for an internal step of an already-authorized scenario, but only if the caller path truly guarantees the required access. When consuming another or released BO, local mode is not a way to cancel its access contract. Do not use it as a general workaround for a rejected operation.

Coordinating concurrent changes#

Two mechanisms protect different moments of a change.

• Optimistic concurrency compares the version read by a client with the current version, usually through an ETag in OData interaction. It detects a change submitted on top of stale state.
• Pessimistic concurrency locks an object against changes for the duration of a defined RAP transaction. For a managed BO, the runtime performs standard locking; an unmanaged implementation must provide the required responsibilities itself. Draft has its own lock lifecycle.

Both guarantees matter: the client snapshot must be current, and incompatible writes must not happen simultaneously. Check keys and uniqueness separately: locking an existing instance does not prove that another client is not creating the same key. For a model with a root and child rows, define the lock master and dependent entities so that the lock scope matches business invariants without locking unrelated documents.

Design review before implementation#

1. Record the release, ABAP language version, edition, and available released APIs.
2. Describe the root object, compositions, keys, required fields, currency, units, and state owner.
3. Choose managed or unmanaged based on existing storage and logic, not habit.
4. Classify each rule as a validation, determination, action, or separate process coordination.
5. Define the external service/API contract separately from internal behavior.
6. Describe the EML consumer, authorization boundary, commit/rollback, and expected error result.
7. Check ETag, enqueue locks, draft, and uniqueness with two parallel changes.
8. Prepare tests for determination replay, validation rejection, failed save, stale ETag, key conflict, and rollback of the whole BO.

Sources are registered as metadata_only: local snapshots and page hashes were not retained. No code example is presented as an activatable RAP artifact; syntax, ATC, ABAP Unit, and SAP runtime checks were not performed for this material.

Sources#

• ABAP RESTful Application Programming Model, ABAP Cross-Product
• Defining and Implementing Behavior of the Business Object
• Developing Unmanaged Transactional Apps, ABAP Platform 2025 FPS02
• Validations
• Determinations
• Actions
• Concurrency Control
• Entity Manipulation Language (EML)\n- Pessimistic Concurrency Control (Locking)