Using IDOCs to call a BAPI

Posted on by

SAP ERP supports a variety of interface standards to ensure seamless integration with other systems and applications. Here is a short list of common interface standards used in SAP ERP ECC and S/4 Hana along with brief descriptions:

  • RFC (Remote Function Call): Enables the calling of functions and methods in remote systems. RFCs can be used for calling and executing predefined functions within SAP systems or in non-SAP systems over a network. There are Repository API´s like RFC_READ_TABLE that are not part of a business objects.
  • IDoc (Intermediate Document): A standard SAP document format for exchanging data between SAP systems or between SAP and external systems. IDocs serve as containers for data that is structured in a way that is understandable by the target system.
  • BAPI (Business Application Programming Interface): BAPIs are standardized programming interfaces (APIs) allowing external access to business processes and data in SAP systems. BAPIs are implemented as methods of SAP business objects (SWO1 and BAPI) and can be accessed via RFC or IDOC.
  • SAP API Business Hub Integration: Exclusive to S/4HANA, it offers easy access to SAP’s business APIs (OData, REST, SOAP) and Business Object Interfaces to facilitate seamless integration with SAP and non-SAP applications.

In SAP S/4 Hana the focus has shifted towards using APIs based on Odata for real-time integration. For S/4 Hana Cloud certain interface standards are not available anymore or need a special enabling to use them.

  • „Deprecated integration technologies can no longer be used in the ABAP Cloud development model (for example, IDoc) – only released frameworks are available.“ source reference https://learning.sap.com/learning-journeys/practicing-clean-core-extensibility-for-sap-s-4hana-cloud
  • Non-released BAPIs can still be utilized in SAP HANA Cloud by creating customer-made APIs that wrap around them, enabling their usage within the ABAP Cloud development model while ensuring compliance with released API requirements.

In this example i want to demonstrate how to use IDOCs for BAPI processing. Using IDOCs for BAPI processing can be beneficial because it offers standardized data exchange, seamless integration and communication between different SAP systems or external applications. IDocs come in two variations:

  • As a fixed-length format (predominantly in older SAP systems)
  • XML-based format. You can use the function „IDOC_XML_TRANSFORM“ to display an IDOC in a XML format.

To obtain an overview of the currently configured IDocs in SAP we can utilize the transaction code WE60 to access to further documentation.

In this example we want to use IDOC basic type BANK_CREATE01 to create a new bank entry. SAP will process this IDOC by using the Business Object BUS1011 and calling BAPI_BANK_CREATE. You can check for Business Objects in transaction SW01 that is basically the equivalent for the BAPI transaction but also allows you to create your own business object.

Specific customizing configurations are necessary to enable the processing of IDOCs within a SAP system. Like already mentioned IDOCs can be used for exchanging data between SAP systems or between SAP and external systems. In this test case scenario, our objective is to create an IDoc through an ABAP program and process it as if it were sent by another SAP system (Inbound IDoc) within our own system (local system). These processing rules can be customized by using partner profiles WE20. 

These partner profiles involves establishing communication settings including IDOC message type and process code, enabling the exchange of IDocs between different systems or partners.

The process code will try to process the IDOC by using function BAPI_IDOC_INPUT1 (BD67).

To determine which Basic Types and IDOC Message Types are permitted for processing by a specific function, you can execute transaction code WE57.

The IDOC structur of Basic Type BANK_CREATE01 can be checked by using transaction WE30. An IDOC has multiple segments that has different hierarchy levels. These segments and their data record can be further analysed by using WE31. There is a forward navigation function to WE31 when you click on Segment editor. There is a data dictionary structur for every IDOC segment that can be used in an ABAP program. 

In this example we use the function „IDOC_INBOUND_SINGLE“ to create and process an Inbound IDOC. We have to export a structur PI_IDOC_CONTROL_REC_40 „IDoc Control Record for Interface to External System“  and an internal table PT_IDOC_DATA_RECORDS_40 „IDoc Data Record for Interface to External System“ to that function to create an IDOC instance.

An IDoc instance refers to a specific IDoc existing within an SAP system, stored internally in the database across the following database tables:

  • EDIDC: Contains a control record for each IDoc with a unique IDoc number.
  • EDID4: Contains one or more data records, referencing the control record via the unique IDoc number.
  • EDIDS: Contains one or more status records, also referencing the control record via the unique IDoc number.

Here is the code for that example:

REPORT  ZGPT_IDOC9.

DATA: g_control_record LIKE EDI_DC40,
      gt_communication LIKE STANDARD TABLE OF EDI_DC40,
      g_data_segment LIKE EDI_DD40,
      gt_data_segments LIKE STANDARD TABLE OF EDI_DD40,
      g_address_segment LIKE e1bp1011_address,
      g_bank_create_segment LIKE E1BANK_CREATE.

DATA: g_idoc_status LIKE STANDARD TABLE OF BDIDOCSTAT,
     g_return LIKE STANDARD TABLE OF BDWFRETVAR,
     g_serial LIKE STANDARD TABLE OF BDI_SER.

DATA: docnum TYPE EDI_DOCNUM.

* Fill control record information
g_control_record-MANDT = sy-mandt.
„g_control_record-docnum = 1.
g_control_record-mestyp = ‚BANK_CREATE‘.
g_control_record-IDOCTYP = ‚BANK_CREATE01‘.
g_control_record-DIRECT = ‚2‘.
g_control_record-SNDPRN = ‚MAIN‘.
g_control_record-SNDPRT = ‚LS‘.
g_control_record-RCVPRN = ‚MAIN‘.
g_control_record-RCVPRT = ‚LS‘.
g_control_record-SNDPOR = ‚Test‘.

APPEND g_control_record TO gt_communication.

* Convert E1BANK_CHANGE segment to IDoc data segment format


CLEAR g_data_segment.

g_bank_create_segment-BANK_CTRY = ‚DE‘.
g_bank_create_segment-BANK_KEY = ‚90052001‘.

MOVE g_bank_create_segment TO g_data_segment-sdata.

g_data_segment-segnam = ‚E1BANK_CREATE‘.
g_data_segment-HLEVEL = ’01‘.
g_data_segment-MANDT = sy-mandt.
„g_data_segment-docnum = 1.

APPEND g_data_segment TO gt_data_segments.

* Fill the segment data for changing SWIFT code

g_address_segment-BANK_NAME = ‚Test Bank‘.
g_address_segment-SWIFT_CODE = ‚SOBADEFFXXX‘.  “ Set the new SWIFT code here

* Convert segment data to IDoc data segment format
CLEAR g_data_segment.
MOVE g_address_segment TO g_data_segment-sdata.
g_data_segment-segnam = ‚E1BP1011_ADDRESS‘.
g_data_segment-HLEVEL = ’02‘.
g_data_segment-MANDT = sy-mandt.
„g_data_segment-docnum = 1.

APPEND g_data_segment TO gt_data_segments.


* Use IDOC_INBOUND_SINGLE for creating an inbound IDoc
CALL FUNCTION ‚IDOC_INBOUND_SINGLE‘
  EXPORTING
    PI_IDOC_CONTROL_REC_40           = g_control_record
  TABLES
    PT_IDOC_DATA_RECORDS_40             = gt_data_segments
  EXCEPTIONS
    error_idoc_control     = 1
    error_idoc_data        = 2
    idoc_not_saved         = 3
    OTHERS                 = 4.

IF sy-subrc <> 0.
  „Error handling goes here
  WRITE: / ‚Error processing inbound IDoc‘.
ELSE.
  COMMIT WORK.
  WRITE: / ‚Inbound IDoc processed successfully.‘.
ENDIF.

Idoc Processing can be tracked by using BD87.

The new bank entry was done succuessfuly by IDOC processing.