Как выбирать CDS, API, BAPI и расширения SAP#

CDS, API, BAPI и механизмы расширения описывают разные части решения. CDS-модель задаёт семантику данных; API публикует разрешённый интерфейс; BAPI представляет бизнес-метод SAP; расширение добавляет требуемое поведение в предусмотренной точке или рядом с системой. Совпадение технических имён и успешная активация объекта сами по себе не подтверждают пригодность для нужного потребителя.

Эта страница помогает выбрать направление и собрать проверки. Детали CDS, контрактов OData/RAP, BAPI и расширяемости разобраны в материалах по CDS-моделям, released API и OData, RFC, BAPI и IDoc и расширениям ABAP.

Начните с бизнес-операции и потребителя#

Сначала запишите, что должен сделать потребитель и где он работает: прочитать данные, выполнить бизнес-команду, расширить приложение или реализовать новый процесс. Укажите продукт, редакцию, установленный выпуск, ABAP language version, компонент и потребителя - локальную разработку, Fiori-приложение, внешнюю систему или аналитику.

Задача	Что исследовать в первую очередь	Что не следует предполагать
Читать и анализировать бизнес-данные	CDS view и его семантику, ключ, уровень строки, фильтры, авторизации и сценарий извлечения	Что любой CDS является released API или подходит для удалённого доступа
Выполнить бизнес-команду	Опубликованный API или документированный бизнес-метод, параметры, транзакционный результат и ошибки	Что чтение таблицы или вызов внутренней функции равны бизнес-операции
Связать системы	API-каталог для точного продукта и версии; протокол, версия, аутентификация, лимиты и жизненный цикл	Что технически доступный endpoint разрешён для производственного клиента
Добавить поле, правило или действие в стандартное приложение	Поддерживаемая key-user или developer точка расширения и её контракт	Что расширяемая форма, CDS или BAdI доступны для любого приложения
Создать отдельный процесс или приложение	On-stack и side-by-side варианты, владение данными, удалённые API и события	Что размещение логики рядом с SAP автоматически делает её независимой от релиза

Задача пользователя задаёт требуемый бизнес-результат, но не предопределяет технический объект. Проследите путь от шага процесса к бизнес-объекту, затем к выбранному интерфейсу, реализации и проверке результата. Для FI/CO отдельно фиксируйте документ и строки, компанию, ledger, период, валюту, статус и правила сторно, если они влияют на смысл операции.

Различайте модель данных, интерфейс и расширение#

CDS описывает модель данных и её семантику. CDS может использоваться внутри приложения, как основа аналитики или как часть опубликованного сервиса, но её наличие не означает автоматически разрешённый удалённый API, право записи или стабильность для конкретной версии. Уточните гранулярность, ключи, associations, фильтры и назначение конкретного view. Для выпуска и уровня поддержки важен контракт именно этого объекта.

API задаёт поверхность взаимодействия и допустимый способ использования: например, локальный API разработки или удалённый сервис. Проверяйте каталог API для нужного продукта и выпуска, публикацию, версию, операции, модель авторизации, лимиты, ошибки и обратную совместимость. SAP Business Accelerator Hub помогает искать опубликованные интерфейсы; запись в каталоге не доказывает, что API включён, настроен и доступен в конкретном tenant или системе.

BAPI - бизнес-метод SAP, связанный с бизнес-объектом. В классических сценариях BAPI реализуется RFC-capable function module, однако метод и функция, которая его реализует, не являются взаимозаменяемыми уровнями контракта. Уточните статус выпуска BAPI, параметры и структуры, модель commit/rollback, синхронную или асинхронную обработку и результат бизнес-документа. Наличие BAPI в ECC или On-Premise не означает его наличие или рекомендацию для Public Edition. Для конкретной интеграции сопоставьте BAPI с опубликованными API и сценарием целевой редакции.

Расширение добавляет пользовательские поля, поведение или собственное приложение в поддерживаемой точке. Это может быть key-user конфигурация, on-stack developer extension, BAdI или иной extension point, либо side-by-side приложение на SAP BTP. Точка расширения определяет, какие объекты доступны и как система защищает их стабильность. Прямое изменение стандартного кода и обращение к внутреннему объекту не становятся поддерживаемым расширением из-за того, что они технически возможны.

В RAP данные и поведение могут быть представлены CDS и behavior definition, а service definition и service binding задают состав и способ публикации сервиса. Это связанные слои: локальная модель, внешний протокол и доступ потребителя должны быть проверены каждый отдельно. Для внешней интеграции также проверьте, что выбранный контракт разрешён удалённому потребителю, а не только разработке внутри системы.

Проверяйте назначение release contract#

Состояние жизненного цикла и назначение контракта - разные характеристики. Released означает, что объект выпущен для определённого использования, но не объясняет, для какого именно. Контракт задаёт цель потребления и допустимые правила изменения; доступность зависит от типа объекта, видимости, language version, продукта и редакции.

В ABAP Cloud часто встречаются контракты C0, C1 и C2: расширение, системное использование и удалённый API соответственно. Используйте обозначение как ориентир для чтения документации, а не как универсальное разрешение: проверьте точное имя контракта, visibility и допустимость в целевом контексте. Не переносите доступность объекта из одной версии S/4HANA или пакета в другой.

Статус Deprecated указывает на переходный этап и обычно сопровождается рекомендуемым преемником. Не начинайте новую зависимость от устаревшего объекта без оценки миграции. Для каждого используемого элемента сохраните статус, контракт, область видимости, версию документации, преемника и дату повторной проверки. Уточните правила совместимости и срок поддержки именно для этого API: они различаются между ABAP-объектом, CDS, BAPI и опубликованным сетевым сервисом.

Учитывайте редакцию и место исполнения#

Для SAP S/4HANA Cloud Public Edition 2608 SAP описывает key-user, developer и side-by-side расширяемость раздельно. В их контрактах различаются аудитория и доступные типы объектов: например, BAdI и CDS views для ряда key-user сценариев; BAdI, классы, интерфейсы, CDS и behavior definitions для developer extensibility; BAPI, IDoc, OData, SOAP API и события для ряда удалённых сценариев. Это обзор модели редакции, а не гарантия доступности любого перечисленного объекта в конкретном tenant.

Для On-Premise и Private Edition проверяйте release contract и правила установленного ABAP Platform так же внимательно; более широкий набор классических механизмов не делает каждый внутренний объект публичным или upgrade-stable. Для BTP side-by-side определите удалённый контракт, владельца данных, аутентификацию, согласованность изменений, обработку таймаутов и независимый жизненный цикл приложения.

Сначала зафиксируйте редакцию, версию и language version, затем проверьте документацию и каталог в целевой системе или SAP Business Accelerator Hub. Не переносите транзакционный код, API-имя, приложение или маршрут настройки из другой редакции без отдельной проверки.

Проведите контракт от процесса до кода#

Для выбранного объекта ответьте на вопросы и сохраните результат в техническом решении:

Процесс: какое бизнес-действие или представление данных требуется; что считается успешным финансовым результатом?
Объект: какой CDS entity, API, BAPI, RAP service или extension point выбран; какой документированный бизнес-смысл он представляет?
Контекст: для какого SAP-продукта, редакции, выпуска, компонента и языка разработки это подтверждено?
Контракт: каковы статус, release contract и visibility; какие операции, поля, ключи и изменения разрешены?
Реализация: где находится логика, кто владеет данными, как задаются авторизации, транзакционная граница, повторы и ошибки?
Версия и жизненный цикл: как публикуются изменения, что совместимо, есть ли преемник и кто следит за deprecation?
Проверка: какой тест подтверждает результат процесса, ограничения доступа, повтор запроса, конкурентное изменение, сумму, валюту и сверку?

Для чтения CDS проверьте набор строк, ключ, фильтры, авторизации и сверку агрегатов с согласованным источником. Для изменяющего API/BAPI проверяйте бизнес-результат после ответа, ошибки, таймаут и безопасный повтор команды. Для расширения проверяйте вызов точки на нужных вариантах процесса, отсутствие реализации, права, порядок выполнения и регрессию после обновления. Статический анализ или успешная активация подтверждают только свою ограниченную область.

Куда перейти за деталями#

Границы проверки#

Примеры по Public Edition относятся к выпуску 2608, а ссылка на ABAP Cloud / On-Premise относится к S/4HANA 2025 FPS01 там, где это указано. Другие материалы SAP охватывают свои версии и редакции. Список типов объектов в обзоре не подтверждает их наличие, статус, полномочия или настройки в конкретной системе. Данный проект не подключён к целевой SAP-системе: каталог API, реализации BAdI, CDS и BAPI, настройки публикации и runtime не проверялись. Источники сохранены как metadata_only; при проектировании решения сверяйте контракт с документацией и системой фактического целевого релиза.

How to choose SAP CDS, APIs, BAPIs, and extensions#

CDS, APIs, BAPIs, and extension mechanisms describe different parts of a solution. A CDS model defines data semantics; an API publishes a permitted interface; a BAPI represents an SAP business method; an extension adds behavior at a provided point or alongside the system. Matching technical names and successful activation alone do not prove that an object fits its consumer.

This page helps select a direction and collect the required checks. Details are covered in the guides to CDS models, released APIs and OData, RFC, BAPI, and IDoc, and ABAP extensibility.

Start with the business operation and consumer#

First record what the consumer must do and where it runs: read data, execute a business command, extend an application, or implement a new process. Specify the product, edition, installed release, ABAP language version, component, and consumer: local development, a Fiori app, an external system, or analytics.

Task	What to investigate first	What not to assume
Read and analyze business data	CDS view semantics, key, row granularity, filters, authorizations, and extraction scenario	That any CDS view is a released API or supports remote access
Execute a business command	A published API or documented business method, its parameters, transaction result, and errors	That reading a table or calling an internal function equals a business operation
Connect systems	The API catalog for the exact product and version; protocol, version, authentication, limits, and lifecycle	That a technically reachable endpoint is approved for a production client
Add a field, rule, or action to a standard app	A supported key-user or developer extension point and its contract	That an extensible form, CDS view, or BAdI is available for every app
Create a separate process or application	On-stack and side-by-side options, data ownership, remote APIs, and events	That placing logic next to SAP makes it independent of SAP releases

The user's task defines the required business result, but does not predetermine the technical object. Trace the path from a process step to its business object, then to the chosen interface, implementation, and result check. For FI/CO, record the document and line items, company, ledger, period, currency, status, and reversal rules whenever they affect the meaning of the operation.

Distinguish the data model, interface, and extension#

CDS describes a data model and its semantics. A CDS view can be used inside an application, as the basis for analytics, or as part of a published service. Its existence does not automatically mean it is a permitted remote API, supports writes, or is stable for a particular version. Confirm the granularity, keys, associations, filters, and purpose of the specific view. The contract of that object determines its supported use.

API defines the interaction surface and permitted use, such as a local development API or remote service. Check the catalog for the target product and release, publication state, version, operations, authorization model, limits, errors, and compatibility. SAP Business Accelerator Hub helps discover published interfaces; a catalog entry does not prove that an API is enabled, configured, or available in a particular tenant or system.

BAPI is an SAP business method associated with a business object. In classic scenarios, a BAPI is implemented by an RFC-capable function module, but the method and its implementing function are not interchangeable contract layers. Check the BAPI release status, parameters and structures, commit/rollback model, synchronous or asynchronous processing, and resulting business document. A BAPI in ECC or On-Premise does not imply availability or recommendation in Public Edition. Compare the BAPI with published APIs and the use case of the target edition.

An extension adds custom fields, behavior, or an application at a supported point. It may use key-user configuration, an on-stack developer extension, a BAdI or another extension point, or a side-by-side application on SAP BTP. The extension point determines which objects are available and how the system protects their stability. Directly changing standard code or calling an internal object does not become a supported extension just because it is technically possible.

In RAP, data and behavior can be represented by CDS and a behavior definition, while a service definition and service binding define the service composition and publication method. These are connected layers: verify the local model, external protocol, and consumer access separately. For an external integration, also confirm that the contract permits remote use rather than only development inside the system.

Check the release contract's purpose#

Lifecycle state and contract purpose are different properties. Released means an object has been released for a particular use, but does not say which use. The contract defines the consumption purpose and allowed change rules; availability depends on object type, visibility, language version, product, and edition.

C0, C1, and C2 contracts are common in ABAP Cloud: extend, use system-internally, and use as a remote API, respectively. Treat these names as a starting point for reading the documentation, not as universal authorization. Confirm the exact contract name, visibility, and allowed target context. Do not transfer an object's availability from one S/4HANA version or package to another.

Deprecated indicates a transition state and usually comes with a recommended successor. Avoid creating new dependencies on a deprecated object without assessing migration. For each dependency, record its status, contract, visibility, documentation version, successor, and next review date. Check compatibility rules and support duration for the exact API: they differ among ABAP objects, CDS views, BAPIs, and published network services.

Account for the edition and execution location#

For SAP S/4HANA Cloud Public Edition 2608, SAP describes key-user, developer, and side-by-side extensibility separately. Their contracts differ in audience and object types. For example, some key-user scenarios use BAdIs and CDS views; developer extensibility includes BAdIs, classes, interfaces, CDS, and behavior definitions; some remote scenarios expose BAPIs, IDocs, OData, SOAP APIs, and events. This is an overview of the edition's model, not a guarantee that every listed object is available in a particular tenant.

For On-Premise and Private Edition, check the release contract and installed ABAP Platform rules just as carefully. A broader set of classic mechanisms does not make every internal object public or upgrade-stable. For a BTP side-by-side extension, define the remote contract, data owner, authentication, change consistency, timeout handling, and the application's independent lifecycle.

Record the edition, version, and language version first, then check the documentation and catalog in the target system or SAP Business Accelerator Hub. Do not reuse code, an API name, an app, or a configuration path from another edition without checking it separately.

Trace the contract from process to code#

For each selected object, answer these questions and preserve the result in the technical decision:

Process: What business action or data view is required, and what counts as a successful financial result?
Object: Which CDS entity, API, BAPI, RAP service, or extension point is selected, and what documented business meaning does it represent?
Context: For which SAP product, edition, release, component, and development language is this confirmed?
Contract: What are its state, release contract, and visibility? Which operations, fields, keys, and changes are allowed?
Implementation: Where does the logic run, who owns the data, and how are authorization, transaction boundaries, retries, and errors handled?
Version and lifecycle: How are changes published, what is compatible, is there a successor, and who monitors deprecation?
Verification: Which tests confirm the process result, access limits, retry behavior, concurrent changes, amount, currency, and reconciliation?

For a CDS read, check the row population, key, filters, authorization, and aggregate reconciliation against an agreed source. For a changing API or BAPI, verify the business result after the response, error behavior, timeouts, and safe command retries. For an extension, test the extension point on relevant process paths, the absence of an implementation, permissions, execution order, and regression after upgrades. Static analysis or successful activation confirms only its limited scope.

Continue to the detailed guides#

Verification limits#

Public Edition examples refer to release 2608; the ABAP Cloud / On-Premise link refers to S/4HANA 2025 FPS01 where stated. Other SAP materials cover their own releases and editions. The overview's object lists do not confirm availability, state, authorizations, or configuration in a specific system. This project is not connected to a target SAP system: the API catalog, BAdI implementations, CDS and BAPI objects, publication settings, and runtime were not checked. Sources are recorded as metadata_only; verify the contract against documentation and the actual target release when designing a solution.