Всем привет! Я так понимаю, похожие темы уже много раз обсуждалась, но ответа для себя я что-то не нашел.
Итак, ситуация такая.
вариант 1.

Вторая бапишка ругается, что заявка еще заблокирована.
Пробую Вариант 2

Тоже не помогает Видимо потому, что в конце BAPI_REQUISITION_RELEASE уже стоит commit work но без wait.

В общем вопрос - как грамотно вызвать в данном случае две бапишки, чтобы они отработали строго одна за одной?

BAPI_COMMIT ?

Так там же есть параметр управляющий NO_COMMIT_WORK, т.е. можно и без commita внутри с после запуска.

Если вы про BAPI_TRANSACTION_COMMIT, то она внутри содержит тот же самый commit work and wait плюс считывание журнала сообщений, так что разницы, ИМХО, нет.

Но я утолько что нашел нотку Note 967440 - BAPI_REQUISITION_RELEASE(_GEN) with COMMIT WORK

Вот такие пироги

Alex80, спасибо. Я сейчас с 4.7 работаю, и там как раз этого параметра еще нет. Ну сейчас нотку накатим и все будет ок.

Сразу не заметил циферки справа

Ну вот, только обрадовался и снова огорчение. Для BAPI_REQUISITION_RESET_RELEASE соотвествующей ноты нет, а COMMIT WORK в конце есть

Я конечно выставил сообщение в САП, но пока вопрос актуален - если в тексте бапи есть commit work без wait, можно ли добиться чтобы следующая бапишка дожидалась завершения работы предыдущей?

Вот это зря. Works as designed. Смотрим описание асинхронных апдейтов.
Чтобы избежать проблем блокировки перед каждым BAPI (если вызываются цепочкой) ставим оператор SET UPDATE TASK LOCAL.

Сергей, спасибо за совет, попробуем. Я как-то раз в хелпе к абапу смотрел описание SET UPDATE TASK LOCAL, сломал голову, но так и не понял как это должно работать.

Есть ли где-нибудь более понятное описание концепции всех этих SET UPDATE TASK LOCAL, SAP LUW и т.п?

А насчет "Works as designed", они сами честно написали "execution of the COMMIT WORK violates BAPI programming conventions". Вот пусть и исправляют Только долго ждать...

Не сочтите за издевательство, но таки в хэлпе, в том числе в том, который по F1 в системе.
Works as designed касалось не этого BAPI, а вообще COMMIT+асинхронный апдейт+снятие блокировок.

Да какое уж тут издевательство, буду разбираться.
Просто я думал, может в каком нибудь курсе есть пара картинок или примеров, которые помогут разобраться с этой концепцией.

Есть курс BC414 (Programming Database Updates), но не знаю, насколько там понятно объяснено. Насчет LUW вот тут посмотрите:
http://sapboard.ru/forum/viewtopic.php?t=33320

Большое спасибо всем откликнувшимся!
SET UPDATE TASK LOCAL перед вызовом бапишек помог.

Конечно в BC414 всё понятно разжевано, как для дебилов, всё с картинками! Вобщем-то, как обычно в курсах BC*.

По вопросам ABAP изучайте курсы BC4*, там все есть и всё очень понятно.

В курсе BC414 можно прочитать, что без оператора SET UPDATE TASK LOCAL запросы обновления пишутся в таблицу БД VBLOG. При обновлении используется свой рабочий процесс для модулей обновления.
В случае SET UPDATE TASK LOCAL для запросов обновления используется память сервера приложений и для обновления используется текущий диалоговый процесс.
Это и есть самый что ни на есть синхронный метод обновления.

Соответственно, в данном случат бапишки будут выполняться строго одна за другой.

При использовании BAPI такое бывает нужно. Бывает, что поставишь COMMIT WORK AND WAIT (через BAPI_TRANSACTION_COMMIT), после выполнения BAPI делаешь SELECT из таблицы, куда бапишка заносит данные. А селект возвращает 4. Почему так происходит в системе - не совсем ясно. Смотрел по ST05, там показано, что сначала отрабатывает весь диалоговый процесс, а затем запускается программа обновления. Т.е. сначала происходит селект (до выполнения бапи), затем бапи.

Борьба со следствием этой проблемы - помогает использование как раз-таки SET UPDATE TASK LOCAL. Как бороться с причиной - неизвестно, т.к. неизвестна причина По крайней мере, для меня.
Может, кто знает?

SM50, если память не изменяет,

По существу: причина в том, что ваш диалоговый процесс и процесс, в котором выполняется обновление - асинхронны.

Результаты же ST05 вы просто неверно интерпритировали.