Чем SAP LUW отличается от DB LUW, когда срабатывает COMMIT WORK и почему граница фиксации должна принадлежать вызывающему процессу.
3 мин чтения·База знаний
Ревизия 1Общие понятияЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
В ABAP важно различать SAP LUW - логическую единицу бизнес-работы приложения - и DB LUW, то есть атомарную транзакцию базы данных. Одна SAP LUW может включать несколько шагов и запросов, а изменения могут быть организованы так, чтобы фиксироваться согласованно. DB LUW сама по себе не выражает бизнес-границу документа или процесса.
COMMIT WORK завершает текущую SAP LUW и инициирует фиксацию зарегистрированных изменений. В классическом сценарии он может запускать зарегистрированные update function modules; COMMIT WORK AND WAIT ожидает завершения синхронной обработки update task. ROLLBACK WORK отменяет текущую работу в пределах применимой модели SAP LUW, включая незапущенные регистрации update task. Точная последовательность и доступность механизмов зависят от платформы и версии; классический update task недоступен в ABAP Cloud.
Повторно используемый доменный метод обычно не должен самовольно фиксировать транзакцию. Его вызывающая сторона может объединять несколько операций, и внутренний commit способен зафиксировать неполный бизнес-сценарий или лишить вызывающий код возможности отката. Поэтому договоритесь о владельце границы транзакции: команда приложения или верхнеуровневый сценарий координирует шаги и решает, когда завершить LUW.
Бизнес-операция должна иметь ясный контракт: какие изменения она готовит, какие ошибки возвращает или поднимает, какие внешние действия инициирует и кто отвечает за commit. Внешний HTTP-вызов, отправка сообщения или запись во внешнюю систему не становится атомарной с DB LUW автоматически. Для таких взаимодействий проектируйте отдельную надёжную координацию и обработку повторов; не представляйте это как гарантию обычной транзакции базы.
В классическом ABAP вызов CALL FUNCTION ... IN UPDATE TASK регистрирует выполнение для более позднего этапа, который инициируется COMMIT WORK. Сам факт регистрации не означает, что изменение уже выполнено. Учитывайте отдельный update work process, диагностируйте ошибки через предусмотренные механизмы и не помещайте в update-функцию произвольные операции фиксации/отката. Для ABAP Cloud классическая модель update task неприменима - используйте поддерживаемые платформой API и модели транзакций.
AND WAIT влияет на ожидание синхронной обработки; оно не заменяет проверку всех последующих бизнес-условий и не превращает несвязанные внешние действия в атомарные. Ошибки после фиксации требуют компенсирующей бизнес-операции или процедуры восстановления, а не попытки откатить уже завершённую DB LUW.
Distinguish the SAP LUW, the application's logical unit of business work, from a DB LUW, an atomic database transaction. One SAP LUW can include multiple steps and requests; database changes can be organized to commit consistently. A DB LUW alone does not express the business boundary of a document or process.
COMMIT WORK ends the current SAP LUW and initiates commitment of registered changes. In classic scenarios it can trigger registered update function modules; COMMIT WORK AND WAIT waits for synchronous update processing. ROLLBACK WORK cancels work within the applicable SAP LUW model, including update task registrations not yet started. Exact behavior and availability depend on platform and release; the classic update task is not available in ABAP Cloud.
A reusable domain method should not commit a transaction unexpectedly. Its caller may be coordinating several operations, and an internal commit can persist an incomplete business scenario or remove the caller's ability to roll back. Make the transaction owner explicit: an application command or top-level scenario coordinates steps and decides when to end the LUW.
Define a clear operation contract: changes prepared, errors returned or raised, external effects initiated, and who owns commit. An HTTP call, message, or external system write does not become atomic with a DB LUW automatically. Design separate reliable coordination and retry handling for such interactions.
In classic ABAP, CALL FUNCTION ... IN UPDATE TASK registers work for a later stage initiated by COMMIT WORK. Registration does not mean the change has already executed. Account for a separate update work process, diagnose failures with supported mechanisms, and do not place arbitrary commit or rollback operations inside an update function. Classic update task is not applicable to ABAP Cloud; use supported platform APIs and transaction models.
AND WAIT affects waiting for synchronous processing; it does not replace checking all business conditions or make unrelated external effects atomic. Failures after commit need a compensating business operation or recovery procedure, not an attempted rollback of a completed DB LUW.