Problem solve Get help with specific problems with your technologies, process and projects.

BAPIs (RFCs) vs. IDOCs

A question often raised in the discussion forums is: "Shall I use BAPIs (RFCs) or IDOCs to interface to SAP?"

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 with. 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.


This was last published in May 2002

Dig Deeper on SAP ABAP

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchManufacturingERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchFinancialApplications

Close