BAPIs (RFCs) vs. IDOCs

BAPIs (RFCs) vs. IDOCs by Wolfgang G. Propfe, Wolfgang Consulting, Inc.

Excerpted with permission from his book title "ABAP with Style." To purchase the text, click here: http://www.wolfgangconsulting.com/WCInc/AWS.html

A question often raised in the discussion forums is: "Shall I use BAPIs (RFCs) or IDOCs to interface to SAP?" This is not so much a matter of taste, but of the task's requirements. Both are very different in terms of mode (synchronous or asynchronous), reprocessing capabilities and success/failure communication.

IDOCS
An IDOC (intermediate document) is similar to a file transfer combined with a processing trigger. Data is passed to SAP in a predefined package, and the corresponding processing via a function module is kicked off. Depending on the syntactical correctness of the data and the success of the processing, the IDOC is tagged with a status. The data transfer via IDOC is an asynchronous process, where the IDOC-posting external program does not get an immediate reply about the success. Waiting for the processing to complete is not an option, because the IDOC may not be considered immediately. Similar to an e-mail, you will not know when it is processed completely. Outbound IDOCs are generated and put on a queue ready for transmission, but again you cannot rely on an immediate transfer and a successful reception by the other side. IDOCs require additional configuration to determine where to go. The communication channels to relay them have to be set up, often outside of SAP, e.g., in MQSeries.

In order to track the success of IDOC processing, a functional acknowledgment (FA) is typically sent, which contains information on the processing status and a reference to the original message. The sender can then match FAs and original IDOCs to determine, what requires additional action ad what is done and over wit...

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT SAP ABAP/Java developer tips How to do additional dialog processing after SAP COMMIT WORK statement How to find a piece of SAP ABAP code without debugging How to read an SAP transaction in an ABAP code How to provide an SAP R/3 4.5B application server with a Web service interface How to find owners and transports of deleted ABAP programs Fixing a common OPEN_FORM and START_FORM error in SAPscript Select Text fields: Case-insensitive Is this the quickest way to find a BADI? Easily debug error messages in SAP processes Accessing private attributes in ABAP Objects

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

h. FAs are also asynchronous IDOCs, so the sender does not wait, but rather collects any information over time and matches it upon arrival. A certain time should be allotted until an FA is expected, which can range from seconds to minutes to hours, depending on the scheduling inside SAP and on the polling interval of the communication layer.

FYI - useful IDOC information:
IDOCS are stored in tables EDIDC (document control), EDID2 (document data in segments) **or EDID3 or EDID4- depending of the version and EDIDS (document status). Use structures EDI_DC, EDI_DD and EDI_DS to communicate data to the subsystem (SAPLink or EDI.) The actual segments(e.g. 'E1EDK01') should only be maintained via the Segment Editor, but you can view the generate structures in SE11: A set of three virtually identical structures is generated, which typically starts with "E" for standard or "Z" for custom segments, and has the numbers 1, 2, and 3 in second position (respectively.)

RFCs
An RFC (remote function call) is similar to a regular function module, but typically called from outside of SAP. A session is established from the calling application to SAP, a user ID is logged on, and then a call is issued, triggering the processing inside the call. When it is done, it usually returns information such as a return code and application data. The calling application waits for the processing to complete, receives the data and can continue processing, taking the result into account. It can even issue multiple RFCs during one session. The main difference between RFCs and regular function modules is the definition of the interface (e.g. CHANGING parameters are not allowed) and the interaction with the user (RFCs should not popup windows, because there is no user available to react to it). RFCs leave no data behind for restarting the task. They either fail or complete according to the transaction concept, but since you are on a function level, a transaction may encompass more than one call. Therefore, you may need to issue a separate COMMIT call after you are done or you risk losing your work. RFCs are also bi-directional, i.e. they can be called by a client program or they can invoke a server program can be the client. In interfaces, you are more likely to use an RFC from a client program.

Note that an IDOC can actually issue an RFC during processing and that an RFC can create an IDOC. They are two different and independent mechanisms. But as soon as one asynchronous method is involved, the overall communication flow is asynchronous, meaning the sender should not be on stand-by to expect an answer.