Как проектировать интерфейс вызываемого модуля и понимать транзакционные границы BAPI, сообщения об ошибках и поддержку API.
3 мин чтения·База знаний
Ревизия 1Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Function module предоставляет именованный интерфейс для передачи данных и обработки результата в ABAP. BAPI является опубликованным бизнес-интерфейсом объекта и имеет отдельные правила контракта и транзакции. Не всякий function module является BAPI, а RFC-enabled не означает автоматически released, стабильный или рекомендуемый для внешней интеграции.
Перед созданием модуля сначала проверьте, существует ли подходящая стандартная функция или released API. Если нужна новая функция, определите её область ответственности, входные и выходные параметры, исключения и поведение при частичном отказе. Интерфейс должен выражать единицы, валюты, формат ключа, обязательность и версии структур, а не полагаться на неявные глобальные данные function group.
Группируйте связанные модули по общей функции и учитывайте, что runtime загружает function group целиком. Документируйте параметры и ограничения, проверяйте типизацию и граничные значения, добавляйте полномочия там, где модуль пересекает границу доступа, и тестируйте вызываемый контракт вместе с вызывающей программой.
BAPI ориентирован на бизнес-операцию и должен передавать результат в согласованном формате сообщений, включая ошибки, предупреждения и успешное создание объекта. Идентификатор созданного документа и сообщения следует сохранять у вызывающей стороны для последующей проверки. Не считайте отсутствие исключения доказательством, что каждый ожидаемый объект сохранён.
Уточните доступность и статус поддержки конкретного BAPI для продукта и релиза. Старый объект может быть RFC-enabled, но документация способна прямо не рекомендовать его для RFC-сценария. Для новых расширений проверьте released API и модель расширяемости целевой редакции вместо выбора только по совпадающему имени.
В документированной модели BAPI вызывающая сторона контролирует завершение объединённой единицы работы. Записывающий BAPI обычно не должен самовольно выполнять COMMIT WORK, чтобы клиент мог объединить несколько согласованных вызовов и решить, когда фиксировать или откатывать транзакцию. Сервисные функции commit/rollback применяйте согласно контракту BAPI и release-specific документации.
Не переносите эти правила на любой function module без проверки. Уточните, какие изменения происходят при вызове, как используется update task, что означает успешный ответ, какие сообщения считаются ошибками и какие ограничения действуют между чтением и записью в одном SAP LUW. После сетевого таймаута проверьте состояние по бизнес-ключу прежде, чем повторять запись.
Для интеграционного вызова зафиксируйте endpoint и версию контракта, техническую идентичность, бизнес-ключ, correlation ID, таймаут, порядок, правила повторов, идемпотентность и сверку результата. RFC transport не является бизнес-гарантией доставки ровно один раз. Не создавайте синхронную цепочку вызовов, которая скрывает длительные операции и оставляет неизвестным состояние частично выполненной работы.
Источники описывают ABAP Platform 2025 и транзакционную модель BAPI. Фактическая поддержка интерфейса зависит от целевой системы и выпуска. В проекте нет SAP runtime; function modules, BAPI, RFC, commit и rollback не выполнялись.
A function module provides a named interface for passing data and handling results in ABAP. A BAPI is a published business interface of an object with its own contract and transaction rules. Not every function module is a BAPI, and RFC-enabled does not automatically mean released, stable, or recommended for external integration.
Before creating a module, first check whether a suitable standard function or released API exists. If a new function is needed, define its responsibility, input and output parameters, exceptions, and behavior on partial failure. The interface should express units, currencies, key format, required fields, and structure versions instead of relying on implicit global data in a function group.
Group related modules by function and account for the runtime loading the entire function group. Document parameters and limitations, check types and boundary values, add authorization where the module crosses an access boundary, and test the callable contract together with its caller.
A BAPI is oriented around a business operation and should return a result in an agreed message format, including errors, warnings, and successful object creation. The caller should retain the created document identifier and messages for later verification. Do not treat the absence of an exception as proof that every expected object was saved.
Check the availability and support status of a specific BAPI for the product and release. An older object can be RFC-enabled while its documentation explicitly advises against using it in RFC scenarios. For new extensions, verify released APIs and the extensibility model of the target edition instead of choosing by a matching name alone.
In the documented BAPI model, the caller controls completion of the combined unit of work. A write BAPI should generally not issue COMMIT WORK on its own, so the client can combine compatible calls and decide when to commit or roll back. Apply service commit/rollback functions according to the BAPI contract and release-specific documentation.
Do not apply these rules to every function module without checking. Determine which changes occur during a call, how update task is used, what a successful response means, which messages count as errors, and what restrictions apply to reads and writes in one SAP LUW. After a network timeout, check the state by business key before repeating a write.
For an integration call, record endpoint and contract version, technical identity, business key, correlation ID, timeout, ordering, retry rules, idempotency, and reconciliation. RFC transport is not a business guarantee of exactly-once delivery. Avoid a synchronous call chain that hides long operations and leaves partially completed work in an unknown state.
The sources describe ABAP Platform 2025 and the BAPI transaction model. Actual interface support depends on the target system and release. This project has no SAP runtime; function modules, BAPIs, RFC, commit, and rollback were not executed.