Подскажите пожалуйста,
1. Обязательно ли после каждого бапишного вызова делать bapi_transaction_commit? В моем случае речь про пакетную загрузку На мой взгляд это расточительно да и как-то противоречит самой идее LUW/транзакций.
1а. Если следущие функции зависят от результата предыдущих, имеет ли для них значение проведенный вовремя коммит. Например после вызова BUPA_CREATE_FROM_DATA вызывать BUPA_IDENTIFICATION_ADD, BUPA_ROLE_ADD.
1б. После неудачного вызова какой-либо функции нужно ли делать rollback для очистки последствий ее выполнения, если на ранее сделанное ее результат не влияет (в примере выше - не создалась идентификация - ну и хрен с ней. Или неудача с созданием одного партнера никак не влияет ни на последующих, ни на предыдущих).

Опять заранее извиняюсь за вопросы человека который как будто никогда с транзакциями не работал, но передо мной код который
а. в пакетной обработке делает коммит после каждого бапишного чиха (причем для уверенности следом иногда встречается commit work :)
б. в случае неудачи какой-либо функции делает rollback - и это в условиях того что каждое успешное изменение уже подтверждено в силу пункта а.

В зависимости от логики BAPI процесса. В общем случае не обязательно.
Поясните, что Вы имеете в виду под пакетной загрузкой? Вообще в терминах SAP 'пакетная загрузка = Batch Input' <> 'BAPI'
Имеет. В Вашем примере BAPI-изменение может не отработать сразу после BAPI создания даже если будет указан явный COMMIT. Для таких целей предназначена сомманда Commit Work and Wait Считал, что не нужно, но вот Note 798535 - COMMIT WORK after calling a BAPI. говорит обо обратном
Вообще ФМ BAPI_TRANSACTION_COMMIT предназначен для внешних систем
Поэтому дублирование данного ФМ и Commit Work конечно лишнее.
p.s. Кстати, загрузке BP посвященна целая ветка в SPRO. Компоненты общие для всех приложений - Центральный деловой партнер - Перенос внешних данных.
update. Не заметил что у Вас CRM - но что-то похожее наверняка есть.

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

Мне же нужно делать коммит ОДИН раз на несколько созданий партнеров, внутри каждого из которых будут вызовы про роли, адреса, подразделения и т.д. Для чего - маленький опыт показал, что скорость возрастает, да и вроде как иначе и быть не может. Текущая обработка нескольких записей в секунду это как-то катострофически мало.


Мне непонятно - неужели функции BAPI не атомарны - некорректное завершение может оставить за собой какую-то грязь и я должен думать об этой кухне?

Но в целом спасибо, вы меня как-то все-таки обнадежили

По причине, что вновь созданного объекта еще нет в БД. см. Note 192235 - WAIT parameter for BAPI_TRANSACTION_COMMIT
Согласен. Имел такое же мнение. По хорошему, если ФМ отработал с ошибкой - для пользователя это должно значить, что в системе не произошло никаких изменений. В Вашем случае, считаю целесообразно разделить 2 процесса : создание -> общий commit и изменение для успешно созданных -> общий commit.

Извините, есть ощущение что мы говорим о разных вещах.
Про WAIT я хорошо понял, речь о другом.
Рассмотрим 2 набора данных клиентов: которые лежат в БД и свежесозданные в достаточно длинном BAPI LUW (судя по коду они где-то в памяти лежат, но не в БД). BAPI-вызов который полагается на существование клиента в своей работе учтет оба набора или тупо будет только в БД смотреть?


Так и не уловил какова же реальность...


Так если функция не атомарна, неуспех в любой точке обоих процессов ставит вопрос - как откатиться не похерив все целиком? Ну и важен ответ на вопрос чуть выше, может и процесс делить не надо будет?

только БД. Реальность такова что, на самом деле самого дела нет. В самой деятельности заключена самость дела - и наоборот. Наоборот получим оборот на, и таким образом перевернем образ. Я уже не говорю о природе говора в роде при уже. Ужи и узы - вы меня понимаете? Ну с SAP примерно та же хрень
Тут надо понимать, что такое неуспех в каждом отдельном случае. Например, неуспех - ошибка при создании одного BP , в приницпе не влечет за собой ничего критичного для создания остальных BP. Ну без commit для вновь созданных BP, Вы не сможете изменить их данные.

golomeen, а проверить на практике? Глобальные таблицы в этой ГФ присутствую. При создании данными заполняются. Так что вероятность имеется.

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

так и представляю себе какую-нибудь субд с неатомарным инсертом или не дай Бог селектом
почему тогда коммит/роллбек не включен внутрь функций..? Это же самое естественное решение.


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

Если нет доступа к нотам SAP - попросите логин у базисников.
В чем проблема, если вы сами доказательства не читаете?

С этим в САПе полный порядок. Все атомарно.
Если проводить аналогию с СУБД - то дурак разработчик, написавший код, который приводит к неконсистентности данных.
Вы же не будете отрицать что неконсистентность в СУБД возможна?
Да и результаты того же SELECT сильно разнятся в зависимости от уровня изолированности

Бывает и включен. Бывает что параметр есть специальный для автокоммита внутри. Бывает что коммит можно сделать только самостоятельно.
Зачем так - понятия не имею.

Не будет такого
В каждом случае надо разбираться отдельно.
Не придерживается САП единого подхода к BAPI. За что САПу, естественно, давно надо настучать по голове. Но руки коротки

В релизе 3.1 BAPIs сами вызывают команду COMMIT WORK.Другими словами BAPI - синоним LUW или транзакции.
В релизе 4.0 Commit контроль изъят из BAPIs как обеспечение изменений БД. Здесь, должен быть совместимый с RFC ФМ BAPI_TRANSACTION_COMMIT который выполняет команду COMMIT WORK.
Начиная с релиза 4.6:
В транзакционной модели, используемой для разработки BAPI, транзакции представляют - LUW(много BAPI - один LUW)
Операции изменения БД должны выполнятся через обновление.
Как ив релизе 4.0 BAPIs не содержат белее команды COMMIT WORK. Они включают несколько BAPIs объединенных в собственную LUW.
Для закрытия LUW процесса порожденного вызовом BAPIs используют BAPI_TRANSACTION_COMMIT.Этот модуль представляет метод TransactionCommit бизнесобъекта BAPISERVICE.

см.курс BC414
Для более подробно информации см.BAPI User Manual и BAPI Programming Guide.Они доступны в документации по адресу:
SAP Homepage (http://www.sap-ag.de) далее Technology -> Open BAPI Network/ BAPI Section.

Ответы увы были слишком противоречивыми, пришлось поковыряться в дебрях исходников.

В принципе хватило create_from_data и create_identification.

Функции вполне себе атомарны, [censored] за собой подчищают, при проверке наличия/зависимостей используют и собственные буфера и БД, при коммите буфера сбрасываются в БД максимально умным способом. Бапишный коммит или роллбек очищают эти буфера через buffer_refresh_all.

Делать простой коммит в принципе можно - изменения появятся в БД, но буфера не будут очищены.
Короче говоря сап не дурак, что и требовалось доказать.

Спасибо за внимание.

раз уж заговорили про уровни изолированности, то видел где-то в исходных кодах следущее:
CALL FUNCTION 'DB_SET_ISOLATION_LEVEL', в комментариях написано, что ставит Commited Read.
Как работет, не проверял..