BAPI_TRANSACTION_COMMIT с WAIT = 'X' в BADi

Каков будет эффект использования «BAPI_TRANSACTION_COMMIT» с параметром «WAIT», если он равен «X» внутри BADi? Должен ли я ожидать, что SAP зафиксирует данные, когда LUW зафиксирует?

Я знаю, что внутри 'BAPI_TRANSACTION_COMMIT' происходит 'COMMIT WORK' или 'COMMIT WORK AND WAIT', если вы укажете параметр 'WAIT' = 'X'.

Я также знаю, что неправильно делать «COMMIT WORK» внутри BADi, но если я использую «COMMIT WORK AND WAIT» через BAPI?

В документации SAP, касающейся COMMIT, говорится:

При этом выполняются все высокоприоритетные (VB1) функциональные модули обновления в порядке их регистрации и в общей базе данных LUW. Если вы не укажете дополнение AND WAIT, программа не будет ждать, пока рабочий процесс обновления выполнит ее (асинхронное обновление), а возобновится сразу после COMMIT WORK. Однако, если указано дополнение AND WAIT, обработка программы после COMMIT WORK не будет продолжаться до тех пор, пока рабочий процесс обновления не выполнит высокоприоритетные функциональные модули обновления (синхронное обновление).

Когда все высокоприоритетные функциональные модули обновления успешно завершены, оператор выполняет низкоприоритетные (VB2) функциональные модули обновления в порядке регистрации вместе в общей базе данных LUW.

Мое замешательство возникает из-за того, что у нас есть реализация BADi, в которой есть вызов упомянутой функции с параметром «WAIT» = «X», и мы нашли SAP-ноты, в которых запрещается использование «COMMIT WORK» внутри этого BADi, однако он говорит «ЗАВЕРШИТЬ РАБОТУ», а не «ЗАВЕРШИТЬ РАБОТУ И ЖДАТЬ».

Поэтому я мог подумать, что реализация правильная, потому что эти данные будут зафиксированы, когда LUW завершится... или нет. Любые комментарии?


commit bapi abap badi
person Nelson Miranda    schedule 21.10.2014    source источник

Ответы (1)


arrow_upward
4
arrow_downward

На самом деле LUW завершается, когда вы вызываете COMMIT WORK или COMMIT WORK AND WAIT. Единственное отличие состоит в том, что COMMIT WORK является асинхронным, а COMMIT WORK AND WAIT — синхронным.

BAPI_TRANSACTION_COMMIT с набором параметров WAIT равно COMMIT WORK AND WAIT. Без набора параметров равно COMMIT WORK.

И это правда. Вы не должны фиксировать BAdI. Что делать, если происходит откат после того, как BAdI уже выполнен? Это может оставить ваши данные в совершенно несогласованном состоянии.

person Jagger    schedule 22.10.2014
comment
Последняя часть не совсем корректна. Безопасно или нет использование COMMIT в реализации BAdI, полностью зависит от программы, вызывающей реализацию. - person vwegert; 22.10.2014
comment
И как узнать, есть ли коммит в программе (обычно это стандарт SAP) или нет? Лучше и безопаснее не выполнять фиксацию или откат в BAdI. - person Jagger; 22.10.2014
comment
@Jagger, не могли бы вы уточнить это, пожалуйста: когда все функциональные модули обновления с высоким приоритетом успешно завершены, оператор выполняет функциональные модули обновления с низким приоритетом (VB2) в порядке регистрации вместе в общей базе данных LUW. - person Nelson Miranda; 22.10.2014
comment
@nmiranda Речь идет об обновлениях функциональных модулей. Те называются с предложением IN UPDATE TASK. Посмотрите на первую вкладку под названием Атрибуты любого функционального модуля в транзакции SE37. Там у вас есть опция «Обновить модуль», а подопции запускаются немедленно и запускаются с задержкой. Если функциональный модуль помечен как запускаемый немедленно, это означает, что он имеет высокий приоритет и будет выполняться в VB1. Последний будет выполняться в VB2. Посмотрите на процессы в SM50, вы найдете как минимум два процесса, помеченных как UPD и UP2. UPD — это VB1, а UP2 — это VB2. - person Jagger; 22.10.2014