Здравствуйте.

Подскажите пожалуйста, есть ли возможность при запуске из abap-программы необходимой транзакции (например as01) с пропуском первого экрана автоматически заполнять еще некоторые поля в экране, который вывела транзакция (например поле "название" заполнить значением "ХХХ")?

Заранее спасибо.

Можно, сформировать пакетный ввод (Batch Input) и скормить его через CALL TRANSACTION ... USING ...
В хелпе все есть

Ага... все получилось, супер
Но. Возникла новая проблема.
Как заполнять некоторые поля экрана, используя не CALL TRANZACTION, а LEAVE TO TRANSACTION?

В этом случае никак, а чем не устроил простой CALL TRANSACTION?

Можно попробовать немного извращённый способ. Обернуть вызов CALL TRANSACTION в отчёт, а его вызывать через SUBMIT. Данные передавать либо через параметры отчёта, либо - если их много - через EXPORT/IMPORT.

CALL TRANSACTION не устроил потому, что новая транзакция использует то же ОС, что и текущая транзакция (я в карточке ОС добавил кнопку, по которой вызывается новая транзакция. И при запуске этой транзакции, транзакция AS02 остается запущенной и соответственно нужное мне ОС блокировано).

Значит мне нужно либо использовать LEAVE TRANZACTION, либо программно перед CALL TRANSACTION закрывать текущую транзакцию.

Можно руками снять блокировку, потом call transaction, а потом leave program.

А как руками снять блокировку?

CALL FUNCTION 'DEQUEUE_EXXXXXXX', где XXXXXXX ваш объект блокировки. Только нужно быть уверенным на 100%, что в этот момент транзакция AS02 оставила объект в консистентном состоянии.
Можно даже rollback или commit work для надёжности сделать.

Вы, извините, ерунду советуете. Как можно в чужой программе снимать чужие блокировки, да ещё для надёжности делать commit work? Человек мыслит в правильном направлении. Самое надёжное - прекратить работу транзакции, тогда она автоматически будет 100% в консистентном состоянии.

Это масло масляное. Обсуждается то, каким именно образом прекратить работу транзакции.

Вы предлагаете из транзакции выйти по leave to transaction?
А про SAP LUW и DB LUW предлагаете забыть — пусть с ними неявно что-нибудь случится? Уж лучше сделать rollback и быть уверенным, что в БД ничего не запишется. Согласен, что делать commit очень опасно, это допустимо в очень редких случаях.

Вообще, вызывать из чужой транзакции что-либо опасно и нужно чётко понимать, в какой момент это можно сделать, а в какой нельзя. Особенно если обе транзакции изменяют один и тот же объект. Так что, каков вопрос — таков ответ.

Если AS02 запущена под другим пользователем, к чему приведет удаление чужой блокировки? Как вы можете управлять чужим commit и rollback?

Про SAP LUW, конечно, забыть. При выходе из программы SAP LUW завершается, блокировки снимаются и весь контекст освобождается. Про DB LUW... Есть, конечно, риск, что что-то было сделано прямым апдейтом, но в случае со стандартной программой он стремится к нулю.

Так ежели он всё равно завершается и блокировки снимаются, то почему бы в рамках поставленной задачи не написать
ROLLBACK
DEQUEUE
CALL TRANSACTION
LEAVE PROGRAM
?


Вот поэтому Submit, конечно, надёжнее. Скорее всего в обеих транзакциях используются общие ф.м., которые не всегда инициализируют свои глобальные переменные.


О чём говорить, если даже в bapi'шках встречаются rollback work (и даже иногда commit work!).

Думаю, что в очень многих стандартных транзакциях возникают прямые апдейты. Например, если используется APPL_LOG_WRITE_DB без параметра UPDATE_TASK = 'X'. Ну и тому подобное...