В программе вызывается транзакция создания заказа. После того, как она отработает, необходимо получить номер этого заказа и сделать с ним еще некоторые манипуляции. Если поставить точку останова и пошагово пройтись, то все будет работать. Если же все точки останова убрать, то программа ничего не будет делать после создания заказа. Как быть?

Ну наверное привести вырезки текстов программы сестра... а то знаете как то мыслескоп на таких расстояниях барахлит... Вообще-то наверное GET PARAMETERS <код параметра>, только вот что за заказ... в общем пишем подробненько или ковыряемся сами.

Почти наверняка просто update process не успевает отработать.
самое простое и не совсем правильное сделать задержку (WAIT UP TO 1 SECONDS) после завершения транзакции, ещё к этому можно прибавить скобление базы данных на предмет появления в ней создаваемого заказа.

скорей всего, что не успевает.
у меня стояло
commit work and wait.

но он не срабатывает.

а каким образом добавить "скобление базы данных "?
как вариант, посмотреть, что возвращаемый GET PARAMETERS не постой.

К вышесказанногму - требуется указать режим обновления 'L' при call transaction.
Вообще, я бы порекомендовал посмотреть в сторону Workflow...

В данной транзакции наверное имеется COMMIT в каком-то цикле. Который прерывает работу CALL TR... Т.е. первую итерацию в отладке вы видели а последующие были прерваны.
Чтобы этого не было используйте параметр RACOMIT при вызове тр.

был такой трабл
и update 'S' стоит и commit work and wait и bapi commit и даже wait up to 1 секунда .... и все равно бывает проскакивает=)

Ники, можно про 'L' (local update) - поподробнее? чего то в хелпе ничего об этом

L означает, что все обновления будут выполнены в рамках той же задачи (т.е. локально), а не в отдельной задаче обновления. Это гарантирует, что к моменту выхода из CALL TRANSACTION все обновления буду завершены и все lock'и освобождены.

Тот же эффект дает SET UPDATE TASK LOCAL перед вызововм BAPI, который содержит вызовы функций IN UPDATE TASK.

CALL TRANSACTION ... MESSAGES INTO msgtab
с последующим поиском в msgtab сообщения с типом 'S' и номером сохраненного документа спасет отца русской демократии

по крайней мере у меня так проблема решилась, WAIT UP To 1 SECOND далеко не всегда хватает.

Если после выполнения с документом нужно еще что-то делать и UPDATE не 'L', то не спасет - проверено не один раз.

Да, надо читать конкретный мессадж - он всегда одинаковый. И из него и брать заказ.

Толку то. проблема не в том что-бы №заказа определить, а в том что с созданым заказам надо ещё чтот-то сделать, а его еще нет в базе данных - т.к. данные туда попадают через update task process, а он ещё не сработал.


Огромное спасибо nicky555 и Сергей Королев за L - задолбался уже на эти грабли наступать.

Ну я бы объектики блокирования все таки проверил бы... а то иногда и L, зараза подводит при массовой заливке...

всем спасибо и за ответ на мой вопрос и за другие дельные идеи. номер заказа определяется селектом по соответствующей таблице до победного. в какой-то момент он туда все же попадает

Лучше воспользоваться советом Uukrul.
Подробнее - наhelp.sap.com