Читаю книжку "Enhancing the Quality of ABAP Development". И там приведен такой вот пример:

Вариант 1 (не рекомендуется):
1. Standard SAP: CALL FUNCTION <update order header> IN UPDATE TASK
2. Standard SAP: CALL FUNCTION <update order item> IN UPDATE TASK
3. User Exit: UPDATE <customer table>
4. Standard SAP: COMMIT WORK
- The update on <customer table> is committed
- The update process is triggered to execute the first two UPDATE TASK functions for the standard SAP data (in one LUW)

Тут все понятно. Теперь вариант 2 (рекомендуется):

1. Standard SAP: CALL FUNCTION <update order header> IN UPDATE TASK
2. Standard SAP: CALL FUNCTION <update order item> IN UPDATE TASK
3. User Exit: CALL FUNCTION <update customer table> IN UPDATE TASK
4. Standard SAP: COMMIT WORK
- Update on <customer table> is committed
- Triggering the update process to execute the two UPDATE TASK functions within one logical unit

Сколько же тут тогда этих LUWей (по идее 3)? Почему "Update on <customer table>" и в этом варианте отдельно, а два остальных вместе? Я бы предположила, что все 3 функции выполнятся в том порядке, как они прописаны (наверное также с учетом того, что стоит у них в Update Mode в Attributes)...

P.S. От чтения help'ов по этому поводу хочется только чтобы "ты не мудри, ты пальцем покажи".

Это не так...

Елена, если верить описанию процессов в книге, предположу, что первые два FM принадлежат к группе V2 update, а <update customer table> к V1 update.

Сначала выполяется V1 update в одном LUW, после его выполнения запускется V2 update в собственном LUW.

Итого LUW - 2.

В случае запуска нескольких модулей IN UPDATE TASK они будут выполняться в рамках одного LUW.
Поэтому, чтобы ВСЕ данные, включая свои и стандартные, или целиком записались в БД, или целиком откатились, нужно, чтобы они были в одной очереди на обновление.
Запуск очереди происходит при вызове COMMIT WORK.

В первом случае 2-й LUW, который запускаются при commit - это сохранение стандартных данных, 1-й LUW - сохранение своих данных в user-exit.
Т.е свои данные обновятся в любом случае, а вот в случае ошибки в одном из стандартных модулей не запишутся только стандартные данные .

По-хорошему, не могут order header и item выполняться в V2-процессах. Книжку не смотрел, но не верю, что там это подразумевается. И документ, и юзер-экзит должны выполняться в рамках одного LUW.

Я так понимаю, что книжка написана с опечатками, а точнее просто небрежно. Во втором случае должно быть написано примерно так:
- Customer Update function module is registred
- Triggering the update process to execute the three UPDATE TASK functions within one logical unit

Давайте не путать понятия. Под LUW в этом топике (и, видимо, в книге) подразумевается SAP LUW, а не DB LUW. Поэтому сохранение своих данных в user-exit происходит не в LUW, а непосредственно в БД.

Если в книге опечатка, то для первого примера:

LUW 1 основного процесса, в котором выполняется
User Exit: UPDATE <customer table>

При вызове CALL FUNCTION ... IN UPDATE TASK
создается LUW 2, в котором будут выполняться все
отложенные функции с IN UPDATE TASK.
Итого два LUW.

Во втором примере тоже два LUW. В рамках первого LUW не выполняется ни одного update, все три будут выполнены в LUW 2.

LUW2 будет запущен только в случае успешного завершения LUW1, но в случае ошибки в LUW2 изменения, сделанные в рамках LUW1 так и останутся в БД, в этом и заключается опасность инконсистентности данных, о чем предупреждается в первом примере.



Вы видимо под LUW понимаете только Update-программу, временно сохраняющей в таблице VBDATA модули, которые должны быть запущены в результате COMMIT WORK. Но это не так.
Вызываемый макрос COMMIT WORK завершает работу именно SAP LUW, а не DB LUW.
Если бы после прямого UPDATE <customer table> был вызван
commit на Native SQL, тогда бы можно было говорить, что ициирован прямой апдейт БД, минуя SAP LUW. Но в этом примере вызывается именно COMMIT WORK, который делает все по правилам SAP:
1) прямой commit к БД
2) В случае его успешного выполнения, создание нового рабочего процесса для запуска Update-программы, извлечение данных из VBLOG (VBDATA), запуск функций или подпрограмм, вызванным в программе с опциями IN UPDATE или ON COMMIT в собственном LUW.
3) В случае их успешного выполнения, запуск V2 ФМ.

Удав и vga правильно все написали. Только тут вообще можно говорить об одном LUW, в первом случае в нем смешаны синхронное и асинхронное обновление ( это и разбивает его на два чего не должно быть ) - а во втором все правильно только асинхронное и один LUW.

Ну вот, все понятия всё-таки перепутались.


Синхронное обновление, это когда COMMIT WORK AND WAIT.



Вспоминаем определение.

Начинается SAP LUW при запуске новой транзакции или программы (с генерацией нового vbkey), а заканчивается после того, как отработали все v1-модули обновления.

Завершает и то, и другое.

Ну, можно конечно, каждый DB LUW, содержащий команды OPEN SQL и заканчивающийся COMMIT WORK'ом, назвать вырожденным SAP LUW'ом. Но тогда нормальный SAP LUW (от submit до commit work) в update-процессе будет содержать вырожденный SAP LUW. В общем, путаница сплошная.

Если в SAP library где-то под SAP LUW подразумеваются вырожденные SAP LUW, то просьба показать это место. Я очень удивлюсь.

Здесь нужно понимать, что:




Имелось ввиду, что COMMIT WORK завершает SAP LUW, а DB LUW завершается внутри SAP LUW. Это понятно из приведенного описания.

Чепуха какая-то. Здесь написано, что внутри CALL FUNCTION IN UPDATE TASK начинается новый LUW. Какой здесь имеется в виду? Ни DB LUW, ни SAP LUW там начинаться не могут, если это v1-модуль!

Это тоже неправильно. SAP LUW начинается именно с начала внутренней сессии, ну или сразу после commit work, а не в тот момент, как вызывается первый update ф.м. Хотя бы потому, что set update task local должна стоять между началом SAP LUW и первым зерегистрированным Update модулем. (Понятно, что set update task local "подцепляет" к SAP LUW апдейты из последнего DB LUW'a и нельзя SAP LUW ассоциировать только с update-процессом.)

Откуда цитата? В SAP Library не нашёл такого.

Понятно, что мы говорим об одном и том же. Только на разных языках.
Вот в такой программе, два DB LUW, а SAP LUW — пустой (в нём не зарегистрировано update-модулей, поэтому иногда даже говорят, что его нет)?

Согласно документации COMMIT WORK не завершает SAP LUW
The dialog part of the transaction finishes with the COMMIT WORK statement. The update part of the SAP LUW then begins, and this is the responsibility of the update work process. The SAP LUW is complete once the update process has committed or rolled back all of the database changes.

это если используются update модули - а если обычное обновление в диалоговом процессе - оно всегда синхронное так как дальше выполнение процесса не идет пока не закоммитятся обновления.



В определении ничего не говорится про VBKEY - это вы дописали - вам vga именно об этом говорит что необязательно SAP LUW привязан к V1 обновлениям и правильно
changes are written to the database in a single database LUW
это не обязательно VBKEY и т.д.

на счет последнего замечания по UPDATE TASK который начинает новый LUW все верно но если речь идет о V2 модуле

Это локальное обновление.



Я не переводил определение, а написал, как я это понимаю. Ну, хорошо, чтобы не зацикливаться на абстрактных спорах по поводу определений, давай рассмотрим всё на примере кусока кода, который я привёл. Допустим, что не существует uppdate-процессов и update-модулей. Сколько там SAP LUW'ов?


Ну, это уже ближе к софистике. Имелись в виду границы SAP LUW в рамках текущего прикладного (диалогового или фонового) процесса, а не собственно его завершение.

Границами является завершение V1 процесса, т.к. имеено там либо ставиться "окончательный" commit, либо, при возникновении ошибки в одном из ФМ происходит откат.