ABAP для хмарної розробки

ABAP Cloud — сучасна парадигма розробки для SAP BTP ABAP Environment та embedded steampunk в S/4HANA Cloud. Ідея: обмежити мову, відрізати прямий доступ до таблиць бази та старого API, залишити тільки released API — і завдяки цьому отримати код, який переживає апгрейди без ручного «допилювання».

Якщо Standard ABAP (класичний on-premise ABAP) історично все дозволяє (SAP GUI, SE80, будь-які таблиці, старі FM і BAPI), то ABAP Cloud — навпаки: все, що не released, — заборонено на рівні компілятора. Це принципово інша модель мислення.

Чим ABAP Cloud відрізняється

Три ключові обмеження, що формують стиль розробки:

Аспект	Standard ABAP	ABAP Cloud
Мова	Повна ABAP	Restricted ABAP for Cloud Development
API	Будь-які репо-обʼєкти	Тільки released
Інструмент	SAP GUI + ADT	Тільки ADT (Eclipse)

Мовна версія. Не всі оператори ABAP дозволені. Наприклад, заборонені CALL FUNCTION до не-released FM, прямий SELECT з не-released таблиць, CALL TRANSACTION до SAP GUI-транзакцій, dynpro, класичні списки, SUBMIT, PERFORM.
Released API. Кожен released репо-обʼєкт класифікується за release contract (C0, C1 тощо), який визначає цільову аудиторію і гарантії стабільності. Стан API перевіряється у вкладці Properties обʼєкта в ADT — розділ API State показує release contract.
Інструмент. SAP GUI транзакції (SE80, SE11, SE24) недоступні. Усе через ADT у Eclipse: wizard-и для створення обʼєктів, Project Explorer.

Що робити замість заборонених штук

Якщо звична практика Standard ABAP не проходить ATC, є офіційна альтернатива:

Замість	Беремо
`SELECT` з SAP-таблиці напряму	released CDS view entity
Класичний FM/BAPI	released API клас або released FM
Dynpro, selection screen, класичний список	RAP + Fiori Elements, SAPUI5
`CALL TRANSACTION` на старий модуль	OData-сервіс з RAP BO
BAdI у класичному стилі (SE18/SE19)	released BAdI або Key User Extensibility
Direct update tables	RAP managed BO

Контракти та release state

Коли беремо репо-обʼєкт до використання, перевіряємо його API State у вкладці Properties в ADT. Приклади:

CL_ABAP_RANDOM_INT — released з контрактом C1 (обчислення випадкових цілих).
CL_ABAP_PROB_DISTRIBUTION — released з контрактом C1 (випадкові числа з розподілів імовірності).
CL_IXML_CORE — released (замість старого не-released CL_IXML).
XCO_CP бібліотека — released API для роботи з датами/часом, структурами, файловими обʼєктами.

Не-released обʼєкти (SCARR, CL_IXML тощо) в ABAP Cloud використовувати не можна — компілятор / синтаксис-чек видасть помилку.

Перевірка на cloud-readiness

Якщо мігруємо Standard ABAP код в ABAP Cloud (clean core підхід у S/4HANA), є спеціальний ATC-варіант:

ATC check variant: ABAP_CLOUD_READINESS

Запускаємо через ADT → права кнопка на пакеті → Run As → ABAP Test Cockpit With… → у діалозі вводимо ABAP_CLOUD_READINESS і Ok. На виході — список порушень: використання не-released API, заборонених операторів, dynpro, CALL FUNCTION до не-released FM.

Де шукати released API

ADT → Project Explorer → Released Objects — список released репо-обʼєктів у системі.
Properties → API State на обʼєкті в ADT — показує release contract.
ABAP Keyword Documentation (F1) — сторінки з позначкою ABAP Cloud.

Типовий проект у ABAP Cloud

Скелет RAP-застосунку виглядає так:

Package ZFIN_DEMO (software component ZLOCAL, language version ABAP Cloud)
├── CDS table entity    ZI_Order         (персистентність)
├── CDS view entity     ZR_Order         (root view entity)
├── CDS projection view ZC_Order         (публічний шар)
├── Behavior Definition ZR_Order         (managed implementation in class ...)
├── Behavior Pool       ZBP_R_Order      (поведінка у CCIMP)
├── Service Definition  ZSD_Order
└── Service Binding     ZSB_Order        (OData V4 UI)

Ніяких SE80, ніяких dynpro — тільки декларативні CDS + BDL + класи ABP. Результат — OData-сервіс, до якого чіпляється Fiori Elements або SAPUI5.

Посилання

_{Адаптовано з 19_ABAP_for_Cloud_Development.md (Apache 2.0). Повний перелік нюансів — в оригіналі.}