It all looked like Alphabet soup when I encountered these acronyms for the first time. I even mistook one for another. Admittedly this happened with IDOC vs ALE vs EDI.
By the end of this post, I do hope that I would have been able to help you sort these terms out. It can get confusing, but I know I will be going back to this post from time to time.
- Acronym Breakdown
- Formal Definitions
- Organizing / Grouping the Acronyms
- Grouping and Differentiation Discussion
- Additional References and Links
Let us start by getting familiarized with what these acronyms stand for. I will throw all the words in the table below for your reference then we can try and sort them out later.
Here is a breakdown of what these acronyms stand for:
|RFC||Remote Function Call|
|BAPI||Business Application Programming Interface|
|EDI||Electronic Document Interchange|
|ALE||Application Link Enabling|
|UDDI||Universal Description Discovery and Integration|
|SOAP||Simple Object Access Protocol Web Service|
|WSDL||Web Service Definition Language|
|REST||REpresentational State Transfer|
|API||Application Programming Interface|
|FTP||File Transfer Protocol|
|SFTP||Secure File Transfer Protocol (or SSH File Transfer Protocol where SSH stands for Secure Shell)|
By now, these acronyms may look something like this in your head:
Now, let us refer to their formal definitions and capabilities below.
- Remote Function Call
- Standard SAP interface for communication with SAP and/or other systems.
- RFC calls function modules.
- Business Application Programming Interface
- Specific methods for SAP business objects, which are stored in the Business Object Repository (BOR) of the SAP system
- Used for carrying out business tasks.
- In SAP, BAPIs are stored as RFC-capable function modules in the ABAP Workbench Function Builder.
- BAPIs have standard business interfaces, which enable external applications (with the help of SAP business objects) to access SAP processes, functions and data.
- Application Link Enabling
- Mechanism for the exchange of business data between R/3 applications.
- It is a basic service within SAP Netweaver AS ABAP with which applications send and receive IDocs.
- Intermediate Document
- Standard data structure used in SAP applications to transfer data to and from SAP system applications and external systems.
- Using IDocs, companies with SAP ERP systems, for example, can exchange data with external entities like their partners or customers.
- It is a data container that exchanges data.
- When we execute an outbound ALE or EDI Process, an IDOC is created.
- Electronic Document Interchange
- Exchange of business documents electronically between a business and its partners over a communication network using a standard format. EDI requires IDoc.
- Instead of the direct exchange of IDocs, data will first be converted to a uniform exchange format, the so-called EDI format. A lot of companies request their vendors to send data through EDI.
- SAP does not provide EDI converters but there are EDI messages available in the standard system for utilization.
- Universal Description Discovery and Integration
- XML-based standard for describing, publishing, and finding web services.
- UDDI is seen with SOAP and WSDL as one of the three foundation standards of web services.
- Provides a mechanism for clients to dynamically find other Web services.
- Acts as a directory of Web-services interfaces.
- Simple Object Access Protocol Web Service
- It is an XML-based messaging protocol for exchanging information among computers.
- Web Service Definition Language
- It is the standard format for describing a web service.
- REpresentational State Transfer
- Architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other.
- REST-compliant systems, often called RESTful systems, are characterized by how they are stateless and separate the concerns of client and server.
- Application Programming Interface
- Allows your product or service communicate with other products and services without having to know how they’re implemented.
- This can simplify app development, saving time and money.
- When you’re designing new tools and products—or managing existing ones—APIs give you flexibility; simplify design, administration, and use; and provide opportunities for innovation.
- APIs are sometimes thought of as contracts, with documentation that represents an agreement between parties: If party 1 sends a remote request structured a particular way, this is how party 2’s software will respond.
- File Transfer Protocol
- Standard Internet protocol for transmitting files between computers on the Internet.
- Secure File Transfer Protocol
- or SSH File Transfer Protocol where SSH stands for Secure Shell
- Secure version of File Transfer Protocol (FTP), which facilitates data access and data transfer over a Secure Shell (SSH) data stream.
Organizing / Grouping the Acronyms
From the formal definitions, we can try to organize these terms and associate them to one another. From the image shown earlier, I have added some colors to make these associations.
You will also notice a dashed line grouping because there is a high-level association between them (including the gradient in colors) which we will eventually discuss.
Grouping and Differentiation Discussion
Now, let us go through these terms by color association: Yellow, Blue, Purple, and Pink.
ALE vs IDOC vs EDI
First, we have the Yellow color association for ALE, IDOC, and EDI. Let us visualize a vehicle and a passenger.
From their formal definitions, you can think of ALE and EDI as vehicles. Treat IDOC as the passenger with the information. Basically, there are 2 vehicles as options for the passenger.
ALE can only go from SAP to SAP locations (for example: SAP Dev Environment to SAP Test Environment) while EDI can go from SAP to Non-SAP locations vice versa (for example: .NET application to SAP Dev Environment vice versa).
|Data Exchange SAP to SAP||Data Container||Data Exchange SAP to Non-SAP|
|Vehicle (SAP to SAP)||Passenger (with information)||Vehicle (SAP to Non-SAP)|
RFC vs BAPI
Second, we have the Blue color association for RFC and BAPI. Let us visualize a telephone operator or a call.
These are both function calls in SAP. You can think of these two as calls to operators. RFC would cater to operators that will cover local calls only (SAP to SAP) while BAPI would cater to operators who can cover international calls (local to abroad/international or SAP to Non-SAP vice versa).
RFC would facilitate local calls while BAPI would facilitate international calls. BAPIs are technically RFC enabled function modules. In this context, you can say that all BAPIs are RFC’s but not all instances of RFC’s are BAPIs.
On a technical perspective, you can associate BAPI with Business Objects. These Business Objects are created in a Business Object Repository which can be accessed by Non-SAP applications. For example, a BAPI can be created / utilized to accommodate data coming from an external system such as an order or sales order.
Another thing to note is that you can associate BAPI to Business Objects and an Object-Oriented Programming (OOP) approach.
At this point it can still a bit confusing but in general you can associate BAPI as a function call that enables external applications to access business processes and data in SAP.
|RFC is a function call that can handle SAP to SAP.||BAPI is an RFC-enabled function call that enables Non-SAP to SAP interface.|
|Local Calls||International Calls External / Non-SAP systems to SAP|
FTP vs SFTP
Third, we have the Purple color association for FTP and SFTP. Let us visualize a mail.
You can think of these two (on a high level) as documents. FTP as your regular mail and SFTP as your encrypted email. The main purpose of FTP and SFTP is to bring files from one computer to another (even from one system to another).
The only difference is that SFTP comes with a method for secure remote login from one computer to another. There is a layer or shell of security for SFTP. Therefore, it is okay to associate it to an encrypted email but not to a point that it would be taken too literally.
For example: if a client is expecting some files from a bank, the bank can send these files over through SFTP from their server to the client’s server. These files will be brought from their “computer” to the client’s “computer” and will be placed in a folder. In turn, the clients can move these files from the said folder (accessed by the bank) and move it over to another server folder where an application can access / consume the files for processing.
|File Transfer||Secured File Transfer. Shell.|
|Regular Mail (Postman Delivered)||Email (With Encryption)|
UDDI vs SOAP vs WSDL vs REST vs API
Lastly, we have the Pink color association for UDDI, SOAP, WSDL, REST, and API. Let us visualize the world wide web as web services.
These are all associated to Web Services. We can differentiate them as follows:
- UDDI is the directory of web services interfaces. It is like a directory service where business can list themselves and in turn search for web services.
- UDDI uses WSDL to describe interfaces to web services.
- SOAP is always in XML format and it serves as the message (with actual data)
- WSDL is an XML document that describes the concerned web service. If this document describes the web service, this document is part of the UDDI directory.
- REST is an architectural style or pattern (explanation for the darker pink color) and it is always associated to API (you might have heard of REST API). Unlike SOAP, it is not limited to XML. It can cover plain text, HTML, XML, JSON, etc.
- API is an agreement between applications. Think of it as a straightforward contract. An API doesn’t care about another applications background. It just needs the application to fulfill the end of the deal. A simple example would be a waiter.
- This waiter would be your API. You mention your order to the waiter and the waiter communicates / mentions your order to the chef. The chef then cooks your order. Once the order is fully cooked, the waiter then delivers the order to you. This fulfills the example.
- You made a request. You get your order. It is quite a cold example to mention that the waiter on a high level doesn’t need to know both backgrounds (you and chef). The waiter just needs to fulfill the “contract”.
- From the visuals provided a while ago, there is a red dotted line to signify that all Web Services are API’s but not all API’s are Web Services.
|Directory of Web-services interfaces||XML-based messaging protocol for exchanging the actual data/info.||XML document that describes and explains the concerned web service||Architectural Style + Plain text, HTML, XML, JSON, etc.||Agreement between applications.|
|Directory.||Sends the message with actual data.||Describe the Web Service.||Architectural Style. Always associated to API.||Just fulfill the contract. I do not need to know your background.|
Here are some key words / phrases that we can associate with each:
|Acronym||Keywords / Key Phrases|
|RFC||SAP standard interface. |
Calls function modules.
Enables function calls between SAP Systems.
Enables function calls between SAP and Non-SAP Systems.
SAP + SAP
SAP + Non-SAP
|BAPI||Has standard business interfaces for Non-SAP applications. |
BAPI is implemented as a function module.
BAPI is an RFC-enabled function module.
SAP + Non-SAP
|ALE||Data exchange between R/3 Applications (SAP systems only). |
Through sending and receiving IDocs.
SAP + SAP
|IDOC||SAP standard data structure. |
Uses ALE processes.
Between SAP and/or Non-SAP systems.
SAP + SAP
SAP + Non-SAP
|EDI||Data exchange between different systems. |
Through sending and receiving IDocs
From IDOCS to Conversion to EDI format.
SAP + Non-SAP
|UDDI||Web Service |
Mechanism to find other Web Services
Directory of web services interfaces
UDDI + SOAP + WSDL
|SOAP||Web Service |
XML-based messaging protocol for exchanging the actual data/info.
|WSDL||Web Service |
XML document that describes and explains the concerned web service.
|REST||Web Service |
Architectural style of networked systems.
Created to fix SOAP’s shortcomings.
Separation of client and server.
Can exchange data through Plain text, HTML, XML, JSON, etc.
|API||All Web Services are API’s. |
Not all API’s are Web Services.
Agreement between applications.
|SFTP||Secured File Transfer. Shell.|
Feel free to drop by these links for more information on each. Most of these go in depth on the subject.
I hope this helps. Good luck! 🙂
14 thoughts on “SAP Interfaces In A Nutshell | RFC, BAPI, IDOC, EDI, ALE, UDDI, SOAP, WSDL, REST, API, FTP, SFTP”
I am gaining good understanding on IDOC, Agile, SAP MDG, Scrum, BRF frame work plus
LikeLiked by 1 person
Great to hear that Ibrahim! I was also thinking of writing a post on Agile and Scrum too 🙂
Really helpful post. I struggle with visualizing these concepts and keep forgetting them, but your post is detailed and simple.
Thank you for the effort I really appreciate it.
Brilliant article, but I think something important is missing in the picture: OData (and Gateway) …
Using ALE we can exchange the data between SAP and non-sap systems as well.
really good, one-shot clarity. Thanks, and really appreciate the effort
Information mismathc.. In one section it is mentioned RFC can do SAP to SAP only.. whereas in another section it says it can do SAP to SAP and SAP to Non-SAP. Do not trust the content completely. just go for Acronyms