Добрый день.
Есть странная (на мой взгляд), ситуация с блокировкой объектов.
Поэтому прошу сведущих лиц прояснить логику работы стандарта.
В общем, есть стандартная транзакция изменения документа.
Понятно, что при открытии этот документ блокируется.
При выходе из документа, происходят вызовы в след. порядке:
1) разблокировка документа
2) commit work
3) user-exit, в котором вызывается BAPI для изменение связанного документа
4) внутрях программ обработки этого связанного документа анализируется блокировка исходного документа
5) дык вот эта проверка в некотором % случаев выдает, что исходный документ блокирован текущим пользователем
Подскажите, в чем может быть косяк. Или как эту проблему можно разрешить.

Дело в том, что блокировка действует и на ФМ обновления (IN UPDATE TASK), которая выполняется асинхронно в отдельном процессе и к моменту вызова USER-EXIT этот ФМ может еще выполняться.
В этом случае необходимо в USER-EXIT организовать цикл с задержкой, внутри цикла сделать проверку блокировки.

Спасибо, попробую.

Т.е. пока не отработали все обновления (даже если была принудительна вызвана разблокировка в USER-EXIT), документ остается блокированным? И правильно ли я понял, если commit был бы с WAIT, то проблема не возникла?

А гляньте в ST05 анализ блокировок.

Да, при команде commit work and wait модули обновления запускаются синхронно. Но бывают ньансы. Пример - обработка ММ-заказов - commit work and wait не помогает. К своему стыду не нашел времени выяснить почему. Кроме цикла с попыткой блокирования можно еще сделать цикл с чтением таблицы блокировок (ENQUEUE_READ)

__Gennady, возможно запускались V2 процессы. Они априори асинхронные и на WAIT чихать хотели.

V2 процессы априори не требуют блокировки

__Gennady, источником не поделитесь?

З.Ы.: Однако да. Сам нашел. http://help.sap.com/saphelp_nw04/helpdata/en/e5/de86e135cd11d3acb00000e83539c3/content.htm.
Но в таком случае ваше описание проблемы следует признать чудом

Сергей Королев это чудо объясняет в своей статье.

SU53, я там не зря смайл поставил.
То, что сброс блокировок занимает некоторое время и, в принципе, может быть не закончен при передаче управления - это как бы очевидно. Но, ИМХО, крайне редкое явление.

Меня другое удивило. Что V2 процессы не наследуют блокировки. По идее это потенциальная беда.

Я это редкое явление наблюдаю постоянно. Не все BAPI, а только некоторые, кстати. Например BAPI_PO_CHANGE, BAPI_PO_RELEASE. Если между вызовами не вставить ожидание снятия блокировки - вторая скажет, что заказ блокирован.



Почему беда? В V2 выносится то, что не должно требовать блокировки. Например обновление статистики. И ресурсы системы распределяются более правильно.

Вопрос много раз обсуждался.

Я для себя вывел следующие правила, хотя в последнее время было мало случаев проверить, поэтому могу ошибаться:
1. Чтобы после выполнения Update Task дождаться снятия блокировки, нет никакого способа кроме цикла ожидания, то есть даже SET UPDATE TASK LOCAL+ COMMIT WORK AND WAIT не помогает.
2. Теоретически SET UPDATE TASK LOCAL с COMMIT WORK AND WAIT должен гарантировать, что произошло ОБНОВЛЕНИЕ. То есть например после BAPI выполняем селект и видим уже измененные данные. 100% не проверял, это мое предположение. В любом случае завершение обновления не значит снятие блокировки, блокировка может еще висеть, см. пункт 1.

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

...какой вариант лучше/надежнее/быстрее/чащеиспользуется??

Мы используем конкретные объекты блокировки.
Насчет "чаще используется": посмотрите журнал использования ФМ ENQUEUE_READ и к примеру ENQUEUE_EFBKPF.
Затем в SE12 посмотрите количество объектов блокировки
С точки зрения "универсальности" ENQUEUE_READ удобнее, но есть один ньюанс: его использование не гарантирует, что после снятия блокировки она не появится опять (в документ на редактирование зайдет другой пользователь).

А есть ли принципиальное отличие в использовании LOOP-блокировки от использования параметра _WAIT?
Если нет, то где можно узнать(изменить) время ожидания по умолчанию?