Идея следующая (можно пропустить):
Есть транзакция, в которой делается проводка (MIRO). И для каждой позиции документа необходимо создать подтверждение с помощью BAPI (BAPI_NETWORK_CONF_ADD - на вход нужен номер сетевого графика, а он у позиций может быть разный). Мы создали реализацию BADI метод CHANGE_AT_SAVE, где и пытаемся вызвать BAPI несколько раз. И нужно сделать так, чтобы проводка и все запуски BAPI проводились в БД либо вместе, либо вместе откатывались.

1) Соответственно вставить 'BAPI_TRANSACTION_COMMIT' нельзя, т.к. нарушится целостность данных и при COMMIT WORK в самой транзакции - получаем DUMP. Кроме того мы не сможем в таком случае сохранять и откатывать все данные вместе.
2) Если 'BAPI_TRANSACTION_COMMIT' - не вставлять вообще, чтобы все сохранения выполнились по COMMIT WORK в самой транзакции - то все работает, если BAPI запускается только один раз. Но позиции могут принадлежать разным сетевым графикам, поэтому запускать BAPI нужно несколько раз. А при повторном запуске BAPI в ней возникает неконсистентность и она выдает ошибку - из-за того, что два запуска BAPI делаются в рамках одного LUW

Проблема
Получается, что мы имеем примерно следующее

* наше расширение


* далее где-то в стандарте


И как сделать, чтобы такая логика работала и все сохранялось или откатывалось вместе вопрос??????


На данный момент реализовал так - но это не правильно
* наше расширение


* далее где-то в стандарте

обычно не получается чередовать вызовы bapi в одном sap luw,
т.к. контекст один и тот же, и в очередь задачи обновления копятся все запуски,
это не гарантирует целостность данных.

можно попробовать такой вариант:
какая именно bapi функция? поищите параметр тестового запуска, либо используйте откат (rollback):
запускаете bapi по очереди, лучше в другой задаче (напр: завернуть в ф/м и его запускать в нужной задаче),
с откатом в каждой итерации, при условии, что запуск очередной bapi не зависит от результатов
работы предыдущей итерации. накопленные сообщения проверяете на критичность.
если ошибок по списку нет - запускаете ,лучше в другой задаче, с commit в каждой итерации.

главное не затронуть sap luw текущей транзакции.
в любом случае, остаётся вариант со сторнированием проведённого при появлении первой ошибки

trop - спасибо, коллеги также сказали, что именно как я хотел - реализовать нельзя.
BAPI которую я использую - BAPI_NETWORK_CONF_ADD в ней есть testrun.

Сейчас сделал следующим образом:


(код проверен - работает)

Таким образом, все мои запуски BAPI проверяются в тестовом режиме и если хоть один с ошибкой - прерываю всю работу.
Если ошибок нет и стандарт дошел до COMMIT WORK - запустятся все мои модули обновления и все BAPI сохранятся.
Но что делать, если вдруг BAPI в тестовом режиме выполнилась успешно, а уже при commit в модуле обновления возникла ошибка?
Как тогда откатывать все изменения.

с этой bapi не работал, для отката при ошибках в другой задаче нужно найти bapi удаления(сторно|reverse)
если есть или написать пакетник для отмены

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

Но в итоге мы с постановщиком сошлись на том, что если стандартная ТА выполнится успешно и будет commit - то и мы создаем документ "подтверждения" с помощью BAPI_NETWORK_CONF_ADD - причем, если вдруг не создалось "подтверждение" - то достаточно записать информацию в какой-нибудь лог. Главное, чтобы не было того, чтобы BAPI-ки создавали документы "подтверждения", если сама проводка в транзакции MIRO - не будет создана (т.е. будет ROLLBACK). А это уже предусмотрено в моем вышеописанном алгоритме.

Спасибо, Тему можно считать закрытой.