SAP LUW

LUW (logical unit of work) — часовий інтервал, протягом якого БД переходить з одного консистентного стану в інший. Правило all-or-nothing: або всі зміни комітяться разом, або всі відкочуються. Для ABAP існують два рівні: database LUW (керується самою БД) і SAP LUW (керується ABAP-рантаймом поверх бази).

Типова проблема, яку розв’язує SAP LUW: одна бізнес-транзакція (наприклад, переказ між двома рахунками) виконується у кількох work process — між ними БД неявно комітить проміжний стан. Щоб зберегти консистентність, всі зміни треба відкласти й виконати в одному фінальному database LUW. Це і є bundling.

Терміни

• Transaction — послідовність взаємопов’язаних дій, що закінчується консистентним станом БД.
• Database LUW — неподільна послідовність операцій БД, що завершується database commit. Якщо помилка — database rollback.
• Database commit / rollback — запис/відкат змін БД. Можуть бути неявними або явними.
• Work process — компонент AS ABAP, що виконує програму. Один work process виконує тільки один database LUW.

Неявні database commit

Спрацьовують автоматично в таких випадках:

• Завершення dialog step у dynpro (при зміні work process).
• Синхронний/асинхронний RFC-виклик (крім update-процесів).
• HTTP/HTTPS/SMTP через ICF.
• WAIT з перериванням work process.
• Повідомлення (error/information/warning).

Явні database commit

• COMMIT WORK [AND WAIT] — через ABAP SQL, завершує й SAP LUW.
• COMMIT CONNECTION — для конкретного конекшена.
• Функціональний модуль DB_COMMIT.
• Native SQL команди БД.

Rollback — аналогічно: implicit (runtime error, повідомлення типу A) або explicit (ROLLBACK WORK, ROLLBACK CONNECTION, DB_ROLLBACK).

SAP LUW overview

Як SAP LUW забезпечує консистентність:

1. На початку SAP LUW відкривається internal session.
2. Виконання може розподілятися між кількома work process.
3. Усі зміни БД відкладаються — збираються у transactional buffers або через bundling-техніки.
4. У кінці — один фінальний database commit в одному work process.

Приклад банківського переказу: не можна списати з рахунку A в одному work process, а зарахувати на B — в іншому. Якщо між ними станеться помилка, відкотити зміни А буде неможливо (commit уже пройшов).

Bundling-техніки (Standard ABAP)

Update function modules

Спеціально позначені FM з прапорцем update module. Реєструються для пізнішого виконання, виконуються update work process після COMMIT WORK.

FUNCTION zsome_update_fu_mod
  IMPORTING VALUE(values) TYPE some_dbtab.

  MODIFY some_dbtab FROM @values.

ENDFUNCTION.

Три режими виконання:

• Synchronous — COMMIT WORK AND WAIT: програма чекає завершення update work process.
• Asynchronous — COMMIT WORK: програма продовжує без очікування.
• Local — SET UPDATE TASK LOCAL до реєстрації FM: update виконується в поточному work process, завжди синхронно.

" Synchronous
CALL FUNCTION 'ZSOME_UPDATE_FU_MOD' IN UPDATE TASK
    EXPORTING values = st_a.
COMMIT WORK AND WAIT.

" Asynchronous
CALL FUNCTION 'ZSOME_UPDATE_FU_MOD' IN UPDATE TASK
    EXPORTING values = st_b.
COMMIT WORK.

" Local — перед реєстрацією
SET UPDATE TASK LOCAL.
CALL FUNCTION 'ZSOME_UPDATE_FU_MOD' IN UPDATE TASK
    EXPORTING values = st_c.
COMMIT WORK.   " ефект той самий, що COMMIT WORK AND WAIT

Грабля: runtime error в update FM

Якщо update FM падає — update work process робить database rollback і шле повідомлення користувачу у Business Workplace. Транзакція фактично провалена, але оригінальна програма цього може не помітити (при асинхронному режимі вона вже продовжила).

Remote-enabled function modules

FM з прапорцем remote-enabled, реєструються через CALL FUNCTION ... IN BACKGROUND UNIT (bgRFC) для виконання у фоні. Новіший механізм — background Processing Framework (bgPF).

PERFORM … ON COMMIT (subroutines)

Застарілий механізм (використовувати не рекомендується). Subroutine реєструється на COMMIT WORK:

PERFORM some_sub ON COMMIT.
PERFORM other_sub ON ROLLBACK.

Виконуються у поточному work process перед update FM.

COMMIT WORK vs ROLLBACK WORK

Оператор	Що робить
COMMIT WORK	асинхронний update, закриває SAP LUW, db commit на всіх конекшенах
COMMIT WORK AND WAIT	синхронний update, далі те саме
ROLLBACK WORK	скасовує всі реєстрації, db rollback на всіх конекшенах, закриває SAP LUW

Порада: COMMIT WORK у ABAP Cloud

У ABAP Cloud update function modules недоступні — SET UPDATE TASK LOCAL діє неявно завжди. Тому COMMIT WORK і COMMIT WORK AND WAIT поводяться ідентично: оновлення завжди локальне й синхронне. У RAP-транзакціях використовуй COMMIT ENTITIES / ROLLBACK ENTITIES — див. сторінку про EML.

Супутні концепти

Перевірка авторизації

ABAP SQL не викликає перевірок авторизації у БД. Тому програма має явно робити AUTHORITY-CHECK або використовувати CDS access control. Див. Перевірка авторизації.

SAP lock concept

Database locks живуть тільки до наступного database commit — тобто одну database LUW. Для цілої SAP LUW цього мало. Рішення — lock objects (repository objects у ABAP Dictionary):

• При створенні lock object генеруються два FM: ENQUEUE_... і DEQUEUE_....
• Вони виконуються у спеціальному enqueue work process і пишуть у центральну lock table (ім’я таблиці + ключі).
• На відміну від database locks — locked-запис не мусить існувати у БД; блокування не автоматичне, його треба ставити проактивно.
• У кінці SAP LUW блокування знімаються автоматично під час update або явним DEQUEUE_....

Для BTP ABAP Environment є клас CL_ABAP_LOCK_OBJECT_FACTORY.

SAP LUW у ABAP Cloud та RAP

У ABAP Cloud доступний обмежений набір мов — bundling-техніки вище недоступні. Local update завжди активний.

RAP — це transactional programming model для ABAP Cloud, побудована за правилами SAP LUW. Зміни БД робляться у фінальному кроці — late save phase — з transactional buffer.

EML-оператори для commit/rollback у RAP:

• COMMIT ENTITIES — неявно викликає COMMIT WORK, завжди локальний/синхронний update.
• ROLLBACK ENTITIES — скасовує зміни поточної транзакції, очищає transactional buffer, викликає ROLLBACK WORK.

Controlled SAP LUW

Розширення SAP LUW, що виявляє порушення transactional contract під час виконання. Є у ABAP Cloud і classic ABAP.

Дві основні transactional phases:

• modify — інтерактивна фаза, зміна даних у буфері. Модифікації БД заборонені.
• save — фінальне збереження у БД.

У RAP фази вмикаються автоматично (RAP interaction + early save = modify; late save = save). Вручну — через CL_ABAP_TX:

cl_abap_tx=>modify( ).
" Модифікація БД тут кидає BEHAVIOR_ILLEGAL_STMT_IN_CALL
MODIFY zdemo_abap_carr FROM TABLE @( VALUE #( ( ... ) ) ).

cl_abap_tx=>save( ).
" У save-фазі — дозволено
MODIFY zdemo_abap_carr FROM TABLE @( VALUE #( ( ... ) ) ).

Classified APIs

Методи класів можуть бути позначені інтерфейсами IF_ABAP_TX_MODIFY, IF_ABAP_TX_SAVE тощо — це й є transactional contract. Виклик поза дозволеною фазою — runtime error.

Приклад: cl_bcs_mail_message=>create_instance( ... )->send_async( ) помічений як IF_ABAP_TX_SAVE — у modify-фазі його викликати не можна. Класифікацію можна подивитись у ADT: Class-Relevant Local Types або F2 на методі.

Грабля: MODIFY dbtab у RAP handler

RAP handler methods стартують у modify-фазі. MODIFY dbtab там кине помилку. Для RAP event handler — аналогічно: треба явно активувати cl_abap_tx=>save( ) або робити зміни через EML.

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