Задача: Создаю свою транзакцию. По логике работы предполагаются нормальные ситуации, когда в рамках одной транзакции происходят повторные вызовы ОДНОГО И ТОГО ЖЕ ЭКРАНА. Представляется, что уровень таких вот вложенностей может быть 2-3, ну может быть 4-5, не более.
Насколько я понимаю, диалоговые экраны в ABAP являются сугубо статическими вещами и не могут быть динамически (пере)создаваться в процессе выполнения кода. Поэтому, при повторном вызове одного и того же экрана в одной сессии в нём будут оставаться данные от предыдущего уровня стека..(( так что если такой экран тронуть, то при возврате в вызывающую процедуру всё пойдёт всмятку. (((

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

Немного своих, ИМХО, мыслей: Что саповские экраны являются ну очень статичными вещами и в динамике с ними можно делать довольно-таки немного манипуляций пришлось узнать уже давно. В том числе, экраны можно создавать только в построителе экранов - никаких динамических созданий изнутри кода! (селекционные экраны в коде не в счет..) Поэтому, приходилось быть внимательным и избегать возможности рекурсий на одни и те же экраны. И была надежда, что так и можно выкручиваться. Но в этот раз иные варианты, увы, ведут к ну очень мрачному увеличению объемов кодирования самого тупого свойства, так что хотелось бы поискать варианты обхода нехороших моментов со статичностью..((

Может быть у кого есть что присоветовать по этому поводу?

Думаю их просто надо научиться готовить - посмотри курс BC410 для начала.
Если действительно есть потребность хранить снэпшоты - я бы создал класс для данных экрана и для каждой итерации создавал объект.

на 410м я учился, и транзакций с экранами создал вполне достаточно. Про рекурсию в курсе пусто. Ну не любит сап лишний раз показывать свои не самые лучшие места.
Вроде бы можно вызывать из транзакции другую транзакцию, которая выполняется в своей сессии и тогда получаем отдельный экранный контекст. Но сессий то можно открыть максимум 6, что маловато будет. Да и передачу/возврат параметров нужно думать.
Да, действительно, вариант с сохранением всех внутренностей экрана в какой-нить динамически создаваемый объект класса, затем вызов процедуры и по возвращении восстановление исходного экрана имеет место быть. Хоть и некрасиво, но работать должен. Но и здесь есть вопросы - например, как принудительно обновить содержимое восстановленного экрана? имитировать нажатие клавиши? как-то нехорошо.. впрочем, это нужно пробовать.

Собственно, хотелось бы услышать о каких-то иных вариантах решений, чем "в лоб" сохранять-восстанавливать экраны. Возможно, кто-то уже сталкивался с подобной проблемой..

Что то не видно, что Вы "транзакций с экранами создали вполне достаточно".
Если бы действительно "достаточно", то тогда Вы знали бы что у экрана, фактически, нет никаких данных, которые можно было бы где то сохранять, а потом востанавливать.
Экран, на текущем диалоговом шаге в PBO получает данные (глобальные) и отображает их в соответствующих полях. В PAI наоборот, из полей, по мере необходимости, возвращает их в ABAP.
Так что претензии в данном случае следует предъявлять не SAP-у, а криворуким разработчикам, не предусмотревшим рекурсию, либо криворукому постановщику задачи, который не может избавиться от рекурсии.
Например ФМ REUSE_ALV_GRID_DISPLAY вполне себе и безпроблемно допускает многократный рекурсивный вызов. Там просто об этом подумали и реализовали.

Да, и число 6 не имеет отношения к глубине вызовов по CALL TRANSACTION

Ваша мысль про то, что использование рекурсии является признаком криворукости весьма любопытна. ))

Спасибо, конечно, за переложение хелпа по транзакциям, но ничего полезного по сабжу я из него не смог увидеть.
Фишка в том, что переменные с которыми экран обменивается данными при PAI/POB являются ГЛОБАЛЬНЫМИ в пределах текущей сессии. Так что варианты
динамического создания объектов, которые так вот, автоматом делали бы отдельные независимые наборы этих "зеркальных" переменных не проходят.
Остается разве что вариант перезаписи и последующего восстановления "зеркальных" переменных из неких других буферных структур, но про него я уже упоминал.

Про ALV-шные возможности были мысли. Используем понемногу. Но функционала, сравнимого со стандартным функционалом саповских транзакций (BC410) в ALV нет.
Например, нет возможности управлять обновлением данных, вся работа с базой, ИМХО, делается в "черном ящике". В простых случаях это и не нужно, конечно, но как только
нужно что-то более сложное, то начинаются вопросы. А так безусловно более продвинутая технология, втч с поддержкой рекурсии, что не может не радовать. )

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

Ещё более любопытно как Вы её(мысль) извратили.

Жаль что ничего полезного Вы так и не поняли

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

Но Вы вполне не двусмысленно связали число 6 с CALL TRANSACTION

ИМХО Зря ругаетесь, ну да в САП экраны не такие как допустим в Delphi отсюда и проблемы у человека... к сапу нужно привыкнуть.

Действительно экран в САПе отображает глобальные данные программы.
Я бы сделал функциональный модуль примерно с такой концепцией


таким образом нет мороки с организацией стека для хранения переменных

Как вариант создать свою группу функций имеющую свой скрин и интерфейс к выводу ALV, а в ней можно крутить уже что угодно.

Да чтож за хрень!!! (пардоньте)
Тут может и не в сапе дело? Для чего интересно в принципе рекурсивный вызов экрана нужен? Может автор просто к задаче не с того угла подошел?

Рекурсия экранов прекрасно реализуется, необходимо только включать моск и воображение!
Была как-то одна задача по созданию динамической формы следующего формата
Причём для каждого Уровня 1 было свое кол-во Уровней 2. Понятно, что легче было бы создать дерево, но... заказчик сказал в морг, значит в морг.
Единственным ограничением является глубина рекурсии. Точно не помню, но что-то около 100.

Insect, если Вы действительно читали курс BC410, то должны были бы знать про такую конструкцию как LOOP для экранов.

А вот с этого места пожалуйста по подробней, посвятите убогих

ЗЫ: очень не приятно когда новичкам так отвечают, это не ответы а издевательство какое-то

Новичкам? Человек помнит ещё как SAP R/3 3.0 работала, а Вы говорите "новичкам".
А ответы соответствуют вопросу.

Ну, и на самом экране 0100 должно быть 2 подэкрана. Про LOOP, я думаю, нет смысла рассказывать.

Я указал путь поиска, не писать же за него весь код. А то в последнее время на форуме наблюдается тенденция, что при малейшей проблеме сразу создается тема.

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

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