RFC, BAPI и IDoc: контракт и результат финансовой интеграции
Как выбрать синхронный или асинхронный путь, различать технический приём и бизнес-результат, безопасно повторять обработку и ограничивать применимость интерфейсов по редакции SAP.
4 мин чтения·База знаний
Ревизия 1Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-GENERALКонтекст: CTX-S4-ONPREMКонтекст: CTX-S4-PUBLICдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
RFC, BAPI и IDoc: контракт и результат финансовой интеграции#
RFC, BAPI и IDoc обозначают связанные, но разные уровни интеграции. RFC описывает удалённый вызов функции; BAPI задаёт бизнес-операцию SAP и может вызываться по RFC; IDoc переносит структурированное сообщение для отдельной входящей или исходящей обработки. Совпадающее имя бизнес-объекта не означает одинаковый контракт, транзакционную границу или гарантию доставки.
Синхронный RFC подходит, когда вызывающей стороне нужен ответ в рамках запроса и операция укладывается в согласованный таймаут. При обрыве соединения вызывающая сторона может не знать, завершилась ли операция на сервере. Перед повтором нужно проверить бизнес-ключ и результат предыдущего запроса, иначе технический повтор способен создать вторую проводку или документ.
Асинхронный сценарий через ALE/IDoc разделяет передачу сообщения и его прикладную обработку. Наличие записи IDoc или подтверждение приёма означает, что сообщение дошло до соответствующего технического этапа, но не доказывает успешное создание бизнес-документа. Контракт должен задавать корреляционный идентификатор, наблюдаемые статусы и место, где проверяется документ-результат.
В SAP документированы разные RFC-варианты: синхронные и асинхронные вызовы, транзакционные единицы и очереди имеют разные свойства доставки и упорядочивания. Некоторые механизмы SAP используют технический идентификатор транзакции и обеспечивают повторную обработку в рамках описанного механизма. Это не общее обещание exactly once для бизнес-операции через все системы: бизнес-дубликаты, сбои на границах систем и повторная отправка требуют отдельных проверок.
До реализации укажите точный продукт, редакцию и релиз; поддерживаемый BAPI, IDoc message type или RFC-enabled интерфейс; направление потока; систему-владельца записи; техническую идентичность; ключ документа; правила сериализации; подтверждения; таймаут; повторы; очередь ошибок; срок хранения и сверку результата. Для финансового документа ключ обычно должен включать применимые измерения вроде компании, финансового года, номера документа и источника, а не только локальный номер сообщения.
Опишите значения и правила для валюты документа и локальной валюты, знака суммы, даты документа и даты проводки, периода, ledger, дебета и кредита, корректировки и сторно. Укажите, что происходит при частичном успехе, блокировке периода, ошибке проверки, дублирующем ключе и повторной доставке. Сохраняйте исходный payload или его контрольный отпечаток, версию контракта, correlation ID, технические статусы и бизнес-результаты в соответствии с политикой защиты данных.
Для каждого сообщения нужна явная модель состояний: сформировано; отправлено; принято транспортом; передано обработчику; отклонено или ожидает исправления; бизнес-объект создан либо изменён; результат сверен. Перечень и смысл статусов зависят от выбранного механизма и конфигурации. Не называйте общий HTTP/RFC успех доказательством проводки и не выводите бизнес-успех только из статуса транспортного сообщения.
Для безопасной повторной обработки определите бизнес-ключ и способ обнаружить уже применённый запрос. Разделите временные ошибки, при которых разрешён ограниченный повтор с задержкой, и ошибки данных или конфигурации, требующие исправления. Сохраняйте порядок там, где важны зависимые обновления одного объекта; не переигрывайте более старое состояние поверх нового без проверки версии или временной последовательности. После повтора сверяйте количество, суммы по валюте, компанию, период и итоговые идентификаторы документов.
Проверьте допустимость интерфейса в целевой редакции#
В SAP S/4HANA On-Premise и Private Edition интерфейсы и настройка зависят от релиза и системы. Для Public Edition проверяйте доступные для выбранного scope публичные API и соответствующие communication scenarios. Документация Public Edition 2608 перечисляет BAPI/IDoc в ограниченном сценарии интеграции с SAP ERP On-Premise при активации SAP_COM_0574; это не делает произвольные BAPI и IDoc универсально доступными для внешнего потребителя. Для нового сценария сначала установите наличие поддерживаемого интерфейса в конкретном релизе и документированном сценарии коммуникации.
Проверьте допустимость интерфейса, release contract и конфигурацию в тестовой среде.
Отправьте валидное сообщение, дубль, повтор после таймаута, неверный ключ и ошибку закрытого периода.
Сопоставьте технические подтверждения с бизнес-документом, который действительно создан или изменён.
Проверьте порядок нескольких сообщений для одного бизнес-объекта и обработку старого сообщения после нового.
Сверьте финансовый результат и убедитесь, что исправление, повтор и сторно имеют отдельную историю.
Материал задаёт метод проектирования, а не готовую настройку. SAP Help источники сохранены как metadata_only; конкретный BAPI, message type, partner profile, очередь, доступность в целевом релизе и SAP runtime здесь не проверялись.
RFC, BAPI, and IDoc describe related but different integration layers. RFC describes a remote function call; a BAPI defines an SAP business operation and can be invoked through RFC; an IDoc carries a structured message for separate inbound or outbound processing. Sharing a business object name does not imply the same contract, transaction boundary, or delivery guarantee.
Choose the mode around time and transaction boundaries#
Synchronous RFC fits when the caller needs a response within the request and the operation fits an agreed timeout. If the connection drops, the caller may not know whether the operation completed on the server. Before retrying, check the business key and prior request outcome; otherwise, a technical retry can create a second posting or document.
An asynchronous ALE/IDoc scenario separates message transfer from application processing. An IDoc record or receipt acknowledgment means the message reached a technical stage, but does not prove that a business document was created successfully. The contract should define a correlation identifier, observable statuses, and where the resulting document is verified.
SAP documents different RFC variants: synchronous and asynchronous calls, transactional units, and queues have different delivery and ordering properties. Some SAP mechanisms use a technical transaction identifier and provide retry handling within the documented mechanism. This is not a blanket exactly-once promise for a business operation across systems: business duplicates, failures between systems, and resubmission need separate controls.
Before implementation, specify the exact product, edition, and release; supported BAPI, IDoc message type, or RFC-enabled interface; direction; system of record; technical identity; document key; serialization rules; acknowledgments; timeout; retries; error queue; retention; and outcome reconciliation. A financial-document key usually needs applicable dimensions such as company, fiscal year, document number, and source, rather than only a local message number.
Describe currency values, sign, document and posting dates, period, ledger, debit and credit, correction, and reversal rules. State what happens on partial success, a closed-period error, validation failure, duplicate key, and redelivery. Retain the original payload or its digest, contract version, correlation ID, technical statuses, and business outcomes under the data-protection policy.
Each message needs an explicit state model: created; sent; transport accepted; handed to a handler; rejected or awaiting correction; business object created or changed; outcome reconciled. The names and meaning of statuses depend on the chosen mechanism and configuration. Do not call an RFC/HTTP success proof of a posting, or infer business success from a transport-message status alone.
For safe reprocessing, define a business key and a way to detect whether the request has already been applied. Separate transient errors eligible for a bounded delayed retry from data or configuration errors that require correction. Preserve order where updates to one object depend on one another; do not replay older state over newer state without checking a version or event sequence. After retries, reconcile counts, amounts by currency, company, period, and final document identifiers.
Check interface availability in the target edition#
In SAP S/4HANA On-Premise and Private Edition, interfaces and configuration depend on the release and system. For Public Edition, check the public APIs available for the selected scope and their communication scenarios. Public Edition 2608 documentation lists BAPI/IDoc for a restricted SAP Cloud to SAP ERP On-Premise integration scenario when SAP_COM_0574 is activated; this does not make arbitrary BAPIs and IDocs generally available to external consumers. For a new scenario, first verify that the supported interface exists for the exact release and documented communication scenario.
Check interface eligibility, release contract, and configuration in a test environment.
Send a valid message, a duplicate, a retry after timeout, an invalid key, and a closed-period error.
Compare technical acknowledgments with the business document actually created or changed.
Check ordering of multiple messages for one business object and handling of an old message after a newer one.
Reconcile the financial outcome and preserve separate histories for correction, retry, and reversal.
This material provides a design method, not a ready-made configuration. SAP Help sources are retained as metadata_only; the target BAPI, message type, partner profile, queue, release availability, and SAP runtime were not checked.