Насколько я слышал при разработке BAPI нельзя использовать диалоговое программирование. Мотивируется это тем что при RFC вызове этой BAPI возникнут трудности. Однако в системе есть BAPI которые используют вызовы экранов. В чем соль?

А не тот ли это BAPI который вызывает транзакцию?

Просто есть еще недописанные BAPI, к которым нет ФМ, а просто вызывается транзакция, я тоже не могу понять тот дурдом.

Эти BAPI как правило создавались для Workflow.. Вероятно нужно считать стандартные диалоговые BAPI многочисленным исключением из обязательного правила отсутствия работы с экранами, не использования commit work, не использования call transaction, submit и т.п.

Непонятно утверждение, что в BAPI нельзя использовать экраны - это же не модули обновления, а RFC-модули. В первых, действительно, использование экранов недопустимо, поскольку идет фоновое выполнение. А при RFC-вызовах... почему бы и нет?

Это не я придумал:

Идея BAPI заключается в том, чтобы предоставить универсальный и самодостаточный интерфейс для работы с R/3, причём этот интерфейс должен быть полностью описан параметрами самого ФМ и быть максимально изолированным от системы. Согласитесь, что при вызове других отчётов, транзакций и тем более экранов с их непредсказуемой логикой появления (вспомним злосчастный batch-input) - при всех этих вызовах эту идею можно будет благополучно похоронить. По-моему, так.

Я думаю ограничения на экраны, транзакции и отчёты растут из концепции неиспользования COMMIT внутри BAPI..

Соглашусь с тем, что объекты BAPI есть самодостаточные объекты бизнес-логики, работа с которыми возможна из других систем через RFC.
Однако, ФМ есть, как правило, реализация методов этих объектов, которые имеют свои атрибуты. Эти данные, естественно, должны заполняться, в том числе, с помощью вызовов стандартных транзакций с экранами.
То есть, я хочу донести свое понимание - есть реализация бизнес-объектов, со своими методами и атрибутами. ФМ BAPI есть лишь часть реализации этих объектов.

Может, концепция неиспользования COMMIT внутри BAPI растет из вышесказанного?

А вообще, мне кажется недоразумения по поводу использования диалогов SAPом несмотря на свои же настоятельные рекомендации заключаются в следующем.

Бизнес-объект по понятным причинам может иметь в методах вызовы экранов/транзакций. Например распространённый метод Display. В принципе объект может и не иметь методов реализованных в виде RFC-ФМ. Тогда противоречий никаких, используй всё что хочешь. Это внутрисистемные методы.
Но в некоторых случаях требуется, чтобы метод был удалённовызываемый (к примеру для workflow), но предназначается он для вызова из R/3. Надо - значит сделали метод вызываемым удалённо.

А поскольку BAPI это метод бизнес-объекта, реализованный в виде RFC-ФМ (этого достаточно), то наш метод становится BAPI-методом, несмотря на то, что он не соответствует другим требованиям.

Связь между экранами, CALL TRANSACTION, SUBMIT и COMMIT WORK довольно слабая:

Другое дело, что все они вызывают DB commit, но это уже совсем другая история...