Всем доброго времени суток!

Понимаю вопрос не для пятницы, но все же:

Был написан batch input для транзакции VF11 - необходимо было выполнить сторнирование документа из отчета, при этом написали хитрый user exit в момент создания сторнированной СФ, в которым был переписан стандартный журнал ошибок и в него запихивались именно те данные которые нам нужны, однако при возвращении данных о результатах сторнирования возвращается таблица с журналом ошибок, в которой нет ниче, а только статус с кодом 131 нехватает параметров для отладчика!!! В результате мы не можем проверить как же наш документ был сторнировать. Стоит отметить что такая проблева возникает только при режиме call transaction = N , в остальных режимах все отрабатывает отлично! Мы же в такой ситуации даже не может просмотреть в отладчике что происходит!

Даа сам вопрос))) Кто что может прокомментировать ???

Всем спасибо за внимание!

"N" Processing without display of screens. If a breakpoint is reached in one of the called transactions, processing is terminated with sy-subrc same as 1001. The field sy-msgty contains "S", sy-msgid contains "00", sy-msgno contains "344", sy-msgv1 contains "SAPMSSY3", and sy-msgv2 contains "0131".
Может из-за этого?

Даа это мы уже поняли)) ВОт только таких user exit много и еще неизвестно в инклюдах где еще могут быть запиханы break-poin или просто brek... Придется ручками везде искать и комментить их! ТУт проблема может возникнуть в другом, как в будущем этого предостеречья чтобы другие разработчики снова не наставили точек прерывания! Можно ли в системе отключить как-то на данную транзакцию такого типа прерывание из транзакции???

Нет конечно, как это понимать, программа будет работать с точками прерывания, точки нужны для отладки, программу завершили, точки удалили, ну или на крайний случай пусть разработчики под своими именами точки ставят типа IF SY-UNAME = 'РАЗРАБОТЧИК' ТОГДА ТОЧКА ПРЕРЫВАНИЯ, а тестите под другим пользователем...

Дак в том-то и дело, что данный журнал возвращается у любого пользователя.... Само собой обычные break-point не оставляются в программах без проверки пользователя! К тому же для тестирования есть специальные пользователи в системе!

У нас в Development Standards было прописано, чтобы после к моменту релиза транспорта из DEV никаких breakpoints вообще не было, под страхом увольнения. Один раз тут учудил товарищ, потом два часа телефон разрывался, чуть не до главы компании дошло.

А отключить это никак нельзя, по-моему, так что проверяйте свой код.

Jelena +1
У нас вообще для инструментальных запросов включена проверка при деблокировании запроса, которая ловит break-point в тексте программы.

...или

Вообщем проблема разрешилась только когда полностью закомментировали все break-poin и break <userid> даже если в проверочных условиях по пользователю они стоят! Очевидно при активации, проверяется на содержание такого рода операторов и ставится где-то признак что запуск будет в режиме отладки. Вообщем будем писать user-exit на деблокирование запросов, чтобы впредь такого не было!

Зачём? Это же решается стандартными настройками:

Ну тут дело в том, что у нас даа тоже включен отлов при деблокирвоании, но несмотря на это можно запрос деблокировать и перенести в продуктив. Тут же будет выдаваться предупреждение и данный запрос нельзя будет деблокировать!

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