SAP ABAP Integration Interview Questions: IDoc, RFC and BAPI

SAP ABAP INTERVIEW SERIES • PART 8

IDoc, RFC and BAPI Interview Guide

Integration architecture, monitoring, LUWs, error handling, practical ABAP code and real project decisions.

IDoc, RFC and BAPI are related but not interchangeable. A strong interview answer explains the business requirement, communication style, transaction boundary, monitoring and retry design—not just a transaction code. Exact capabilities vary by SAP product and release, so verify the interface contract in your system.

1. Quick comparison

IDoc
Structured business message with control, data and status records. Commonly asynchronous and monitorable.

RFC
Technical remote function-call protocol. Can be synchronous, asynchronous, transactional or queued.

BAPI
A stable business-oriented API exposed through methods; many BAPIs are remote-enabled function modules.

2. What is an IDoc?

An Intermediate Document is SAP's structured container for exchanging business data. It separates communication from application processing and stores processing status for support and reprocessing.

• Control record (EDIDC): sender, receiver, message type, IDoc type and technical metadata.
• Data records (EDIDD/EDID4): ordered segments containing business fields.
• Status records (EDIDS): processing history and messages.
• Basic type: the standard segment structure.
• Extension: customer segments appended through a governed extension design.
• Message type: business meaning such as an order or master-data message.

Outbound IDoc flow

Business event or application → message determination/change pointers/program → IDoc creation → partner profile/port → communication layer → receiver. Common configuration areas include WE20 for partner profiles, WE21 for ports, BD64 for ALE distribution models and SM59 for RFC destinations.

Inbound IDoc flow

Receiver accepts the IDoc → partner profile and process code determine processing → inbound function/application posts the business document → status is written. Do not treat technical receipt as proof of successful business posting.

3. Important IDoc statuses and monitoring

Common examples include outbound status 03 for data passed to port, inbound 53 for successfully posted application document and inbound 51 for application error. Status meaning and flow depend on processing mode; always read the current status text and application log.

• WE02 / WE05: search and inspect IDocs.
• BD87: analyze and reprocess eligible errors.
• WE19: test tool—use carefully in a non-production environment.
• SM58: tRFC errors and retries.
• SMQ1 / SMQ2: outbound and inbound qRFC queues.
• SLG1: application logs when the solution writes them.

4. Custom outbound IDoc example

The following simplified pattern shows the classic distribution call. In real projects prefer the standard application message interface when available, populate every mandatory control/segment field and handle returned communication IDocs and errors.

DATA: ls_control TYPE edidc,
      lt_data    TYPE STANDARD TABLE OF edidd,
      lt_comm    TYPE STANDARD TABLE OF edidc.

ls_control-mestyp = 'ZORDER'.
ls_control-idoctp = 'ZORDER01'.
ls_control-rcvprt = 'LS'.
ls_control-rcvprn = 'TARGET_SYS'.

APPEND VALUE #( segnam = 'Z1ORDER_HDR'
                sdata  = ls_header_segment ) TO lt_data.

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
  EXPORTING
    master_idoc_control        = ls_control
  TABLES
    communication_idoc_control = lt_comm
    master_idoc_data           = lt_data
  EXCEPTIONS
    error_in_idoc_control      = 1
    error_writing_idoc_status  = 2
    error_in_idoc_data         = 3
    OTHERS                     = 4.

IF sy-subrc = 0.
  COMMIT WORK.
ENDIF.

5. What is RFC?

Remote Function Call is SAP's protocol for invoking remote-enabled function modules across ABAP systems or supported external connections. The destination is configured in SM59. Never hard-code credentials; use managed destinations, least privilege and secure network settings.

Type	Meaning	Interview focus
sRFC	Synchronous call; caller waits	Immediate result and error handling
aRFC	Asynchronous execution	Parallel tasks and callback design
tRFC	Transactional asynchronous delivery	Retry, TID and SM58
qRFC	Queued tRFC processing	Serialization and SMQ1/SMQ2
bgRFC	Background RFC framework	Durable units and monitored processing

Synchronous RFC call

CALL FUNCTION 'Z_RFC_GET_STATUS'
  DESTINATION lv_destination
  EXPORTING
    iv_document = lv_document
  IMPORTING
    ev_status   = lv_status
  EXCEPTIONS
    system_failure        = 1 MESSAGE lv_message
    communication_failure = 2 MESSAGE lv_message
    OTHERS                = 3.

IF sy-subrc <> 0.
  "Log destination, document key and safe error context
ENDIF.

Asynchronous RFC pattern

CALL FUNCTION 'Z_RFC_CALCULATE'
  STARTING NEW TASK lv_task
  DESTINATION IN GROUP DEFAULT
  CALLING on_end_of_task ON END OF TASK
  EXPORTING
    is_request = ls_request.

"Callback method/form uses RECEIVE RESULTS FROM FUNCTION.

Transactional and queued calls

tRFC persists the call and retries after communication problems, but does not guarantee business-level idempotency by itself. qRFC adds queue-based serialization when sequence matters. For a queued design, choose stable queue keys that preserve required order without creating one global bottleneck.

6. What is a BAPI?

A Business Application Programming Interface represents a business operation through a defined contract. Many classic BAPIs are remote-enabled function modules associated with SAP business objects. A BAPI should be called according to its documentation, including mandatory structures, extension fields, authorization and transaction handling.

BAPI return and commit pattern

DATA lt_return TYPE STANDARD TABLE OF bapiret2.

CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
  EXPORTING
    order_header_in = ls_header
  IMPORTING
    salesdocument   = lv_salesdocument
  TABLES
    return           = lt_return
    order_items_in   = lt_items.

IF line_exists( lt_return[ type = 'E' ] )
 OR line_exists( lt_return[ type = 'A' ] ).
  CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
ELSE.
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
    EXPORTING
      wait = abap_true.
ENDIF.

Changing BAPIs commonly require BAPI_TRANSACTION_COMMIT or rollback after all return messages are evaluated, but follow the individual BAPI contract. Do not commit after every item in a bulk logical unit of work.

7. BAPI vs RFC-enabled function module

• RFC describes the remote-call mechanism; a remote-enabled function module is a technical callable unit.
• A BAPI is intended as a business API with a published semantic contract; many BAPIs use RFC technology underneath.
• Not every RFC-enabled function module is a BAPI, and not every internal function module is safe for external use.
• For new integration, prefer released APIs appropriate to the SAP product and extensibility model.

8. Real project scenario: external order integration

Question: An external platform sends thousands of orders. Business wants resilience, traceability and no duplicates.

Strong answer: If delayed processing is acceptable, use a durable asynchronous contract such as a standard IDoc/API supported by the product. Define an external message ID and enforce idempotency, validate partner and authorization, store correlation keys, monitor technical and application statuses, separate transient from business errors, and design safe reprocessing. Use a synchronous BAPI/API only when the caller truly needs an immediate business response and can handle timeouts and retries without creating duplicates.

9. Reliability, LUW and idempotency

• Technical retry is not business deduplication. Persist a unique source-message key or enforce a business-key check.
• Keep the logical unit of work clear; the application that owns the transaction decides commit boundaries.
• Do not retry permanent validation errors as if they were network failures.
• Log correlation ID, sender, receiver, object key, status, retry count and sanitized error text.
• Protect sensitive payloads and avoid writing credentials or personal data into unrestricted logs.

10. Performance and security interview points

• Use package-size processing for large volumes and avoid one remote call per item.
• For parallel RFC, respect work-process capacity and resource groups.
• For qRFC, balance ordering needs against queue contention.
• Restrict SM59 destinations and RFC authorizations; review trusted-system configurations carefully.
• Validate inbound values even when the sender is another SAP system.
• Use released interfaces and version contracts; never depend silently on undocumented fields.

11. Common mistakes

• Saying IDoc is always real-time or always asynchronous without discussing processing mode.
• Assuming status 03 means the target business document was posted.
• Reprocessing status 51 without correcting the root cause.
• Using RFC in a loop and creating avoidable network latency.
• Ignoring BAPI return type A/E messages or committing after an error.
• Believing tRFC automatically prevents duplicate business documents.
• Hard-coding destinations, credentials, partner numbers or receiver systems.

12. Practice exercise

Design an outbound order interface for 50,000 daily records. Document: message contract, IDoc/BAPI/API choice, partner and destination setup, commit unit, idempotency key, success/error monitoring, alert thresholds, reprocessing procedure, security roles and a reconciliation report. Include a sequence diagram for one success and one retry case.

13. Rapid revision questions

1. Name the three IDoc record categories.
2. What do WE20, WE21, WE02 and BD87 do?
3. Why does status 03 not prove application posting at the receiver?
4. What is the difference between sRFC, tRFC and qRFC?
5. Where do you monitor tRFC and qRFC?
6. Why is a BAPI more than just an RFC-enabled function module?
7. When is BAPI_TRANSACTION_COMMIT appropriate?
8. How do you make retries idempotent?

Official SAP references

• SAP Help: RFC destinations and communication types
• SAP Help: inbound IDoc processing
• SAP Help: qRFC and serialized processing
• SAP Help: BAPI transaction commit and rollback
• SAP Help: ALE message distribution

← Part 7: Smart Forms and Adobe FormsPart 9: SAP Workflow →

Examples are educational. Validate interfaces, release status, authorizations, LUW behavior and monitoring in your SAP landscape before production use.