Есть несколько бапи в цикле, есть запросы обновления z* таблиц (insert/update/delete).
Какая конструкция обеспечит целостность данных в бд (либо отработает всё без ошибок, либо ничего)?

В теории, такая не подходит:
<...после цикла с бапи, если не было ошибок>:
perform sql_queries on commit
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.

1. Ваши insert/update/delete вынесите в модули обновления
2. После выполнения бапи вызывайте ваши модули (CALL FUNCTION ... IN UPDATE TASK)
3. BAPI_TRANSACTION_COMMIT, если все ок

Разве если внутри BAPI_TRANSACTION_COMMIT COMMIT_WORK вернет не 0, транзакции внутри update-модуля откатятся?
В чем принципиальное отличие perform on commit от update-модуля в данном случае?

Курс BC414.

Кстати, а почему не отрабатывает "в лоб": винегрет из бапи и прямых апдейтов БД и затем общий commit или rollback?

В лоб в принципе отрабатывает, но один раз данные из z* таблиц удалились, а бапишки не закоммитились, воспроизвести ситуацию пока не получилось.

Немного не понятна связь между LUW, который создается в update-модуле, и отработкой бапи.

А BAPI-ха вообще "живая"? Я о том, что много ФМ BAPI помечено как неподдерживаемые SAP или устаревшие. Кроме того, один раз сами знаете кто, и даже проверенные годами транзакции иногда дают сбой. У нас не так давно при большой нагрузке на сервер Z-документы создавались, а объекты под них - через раз. Но такое один раз за 3 года.
Схема такая:
1. Стандартный ФМ (не BAPI, но не суть важно). Внутри кстати, стоит PERFORM ON COMMIT, внутри которого CALL FUNCTION IN UPDATE TASK.
2. INSERT Z.
3. COMMIT WORK AND WAIT.

Кстати да, совсем забыл, часть бапи просто тупо некорректно работает в цикле. У них например могут сохраняться глобальные данные только для текущего вызова - а старые удаляться. И получается совсем криво - объект создался, а часть его подобъектов в базе не сохранилась. Например такое было у заказов ТОРО с внешними услугами.
Проблема решается созданием отдельного объекта (с прямыми апдейтами) в отдельной сессии. Но в этом случае общий коммит невозможен.

Это тоже да, беда. Вот нота для примера: 1024902.

Потому что есть такая вещь как неявный коммит БД (implicit commit), в это время все ваши прямые апдейты сохраняются в базу не дожидаясь COMMIT WORK. Во встроенном хелпе можно посмотреть ситуации, когда возникают эти неявные коммиты.
Бапишки же (по большей части:)) не пишут в БД напрямую, они так же стартуют модули обновления, которые висят в ожидании COMMIT WORK. Вы к ним можете добавлять свои модули, и выполняться они будут в рамках одной транзакции БД. Вообще почитайте хотя бы встроенную справку по COMMIT WORK и по статьям что рядом - там много интересного

Читал, и не только справку . За неявными коммитами - да, разумеется, нужно следить, но за ними всегда нужно следить - и без циклов легко могут сломать целостность данных.

Возможно V1 обновление свалилось в дамп, а прямое обновление прошло нормально. В SM13 можно посмотреть ошибки обновлений, запускаемых в UPDATE TASK.

Конструкция perform ... on commit насколько я понимаю имеет те же проблемы с целостностью данных, как и прямое обновление. Поэтому лучше делать как писал ArmAnn

Сделал, как описано выше.
В цикле BAPI на сторно документов -> ФМник на удаление записей из z-таблиц IN UPDATE TASK -> следом BAPI_TRANSACTION_COMMIT (WAIT = 'X').
Бывают случаи (пока не понял от чего зависит), что данные из z-таблиц удаляются, но бапишки не коммитятся. Как исключить эту ситуацию?
В sm13 всё чисто.

А вы анализируете как отработала бапишка на сторно? Т.е. в случае ошибки вызываете BAPI_TRANSACTION_ROLLBACK ?