Добрый день!

Для деблокирования сетевого графика используется вот такой набор ФМ-ов,
т.е. непосредственно сам ФМ, устанавливающий статус сет.графика(BAPI_BUS2002_SET_STATUS ) должен находиться в блоке между
BAPI_PS_INITIALIZATION и BAPI_PS_PRECOMMIT.
Но за один запуск программы требуется обработать несколько сетевых графиков, принадлежащих одному проекту.
В случае если если делать так:
, то все работает, но при единственной ошибке внутри блока - весь блок будет считаться ошибочным.
Этого бы не хотелось.

Есть вариант:

Результатом при определенном количестве значений будет произвольный дамп, т.к. как правильно инициализировать память перед повторным запуском BAPI_PS_INITIALIZATION в рамках одной программы - не знаю.

Есть ещё третий вариант:



Но в данном случае прерывается будет прерываться обновление уже внутри системы и соответственно деблокируется только последний сетевой график.

Вот в связи с этим вопросы к знающим людям:
1) можно ли как-то инициализировать память для повторного запуска BAPI_PS_INITIALIZATION/BAPI_PS_PRECOMMIT в рамках одной программы.
2) Как недопустить прерывание обновления в системе, в случае вызова блока в отдельном ФМ-е.
3) Как лучше деблокировать сетевой график, возможно другим способом?
4) что я делаю не так

sorry за длиннючее письмо

может так
1 инициализация
2 в цикле вызовы BAPI_BUS2002_SET_STATUS, для каждго анализируем результат и запоминаем удачные изменения
3 прекомит
4 если в п.2 удачны все, то п.8, иначе ролбэк, если есть удачные, то п.5, иначе п.9
5 инициализация
6 в цикле вызовы BAPI_BUS2002_SET_STATUS, только для успешных из пункта 2
7 прекомит
8 комит
9 конец

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

что такое прекомит комрады и чем отличается от комита
простите за оффтоп

В данном случае прекоммит - это функциональный модуль BAPI_PS_PRECOMMIT.
Некоторый набор бапишек работающих в PS требуют, чтобы они выполнялись внутри блока ФМов BAPI_PS_INITIALIZATION/BAPI_PS_PRECOMMIT, первый из которых подготавливает среду для их работы, а последний завершает, выполняя необходимые действия для удачного завершения при последущем вызове commit work.
т.е. это просто ФМ.

РК: спасибо, надо было повнимательнее присмотрется к ФМ

Не несколько раз, а максимум два
Если позволяет точка вызова, то можно один из них делать с destination, тогда не пересекутся и будет как два по одному

В документашке это описано к тем BAPI-шкам, которым такое надо.

И еще, если все же понадобится второй вызов, то ролбэк после первого должен все почистить и вторя инициализация должна пройти нормуль
Производительность это да, конечно никакая

На текущий момент уже будет три раза, т.к. предварительно деблокируются спп-элементы.
Но открытым остается вопрос производительности, т.к. когда будет около 3 тысяч сетевых графиков и 30 тыс. операций - это будет чувствительно(а это реальная цифра). Если бы не это, то можно было бы выделить в отдельный ФМ с роллбэком внутри и все было бы гарантировано нормально.

В диалоге у стольких объектов менять статус за раз, хм
Может запуск это добра в job, и пусть юзеры ждут спокойно результат чаёк попивая , у там уже два вызова или один без разницы

Job - это наверное хорошо было бы, но пока нормально и так.
Проблема решилась через третий вариант из первоначального поста, но с добавление вызова как синхронного rfc в той же системе с последущим коммит энд вэйтом. Если коммит делать в самом ФМ-е, то работает неправильно.
Так же нормально отрабатывает и при асинхронном rfc, но оно здесь не нужно, плюс попытки открыть дополнительные диалоговые режимы.

И ещё забавно, что при простановке статуса - в фоне отрабатывает, а вот при попытке деблокировать - нет, в какой-то из стандартных подпрограмма слетает на операторе SET SCREEN.

Вопрос остается открытым в той части, сильно ли упадет производительность, если часто вызывать BAPI_PS_INITIALIZATION/BAPI_PS_PRECOMMIT или наоборот возрастет, т.к. обработка большого количества объектов за раз возможно будет более ресурсоемкая, чем поочередная обработка.