Expand +



SAP Interface Technologies and Middleware Products

by Thomas G. Schuessler | SAPinsider

January 1, 2002

by Thomas G. Schuessler, ARAsoft SAPinsider - 2002 (Volume 3), January (Issue 1)

SAP is a very open system. Several interface technologies exist to retrieve data from SAP or update information in SAP. Often, customers are confused because of the plethora of options. To complicate things further, SAP allows you to use different middlewares with which you can utilize the interface technologies. This article tries to give you an overview of some of the more relevant interface technologies1, as well as discuss past and current middlewares.

The three most important interface technologies are:

  • BAPIs (Business Application Programming Interfaces): BAPIs are actually a special case of RFC2-enabled Function Modules (RFMs).

  • IDocs (Intermediate Documents): IDocs were invented originally to support EDI.

  • Dynpros (Dynamic Programs): "Dynpro" is SAPish for a screen in an SAP transaction.

BAPIs and Other RFMs

The ABAP development environment supports several ways of structuring software, one of them being (ABAP) Function Modules. Function Modules are equivalent to what most programming languages call "functions". The R/3 system contains tens of thousands of Function Modules (more than 100,000 in 4.6C). A subset (more than 10,000 in 4.6C) of those can be called from outside the SAP system, using a protocol called Remote Function Call (RFC). These remotely callable functions are called RFC-enabled Function Modules (RFMs). RFMs can have import and export parameters so that they can (if necessary) both receive and return information.

Not all RFMs are intended for use by non-SAP programs. An RFM can be in one of the following states:

  • Not released: RFMs in this category are often not documented very well (or at all). SAP can change this function at any time (or even delete it). If you want to use non-released RFMs in your applications, you need to have one and only one component that actually calls the RFM, so that future changes (e.g., if SAP changes the function interface) affect only one component and not every application.

  • Released for internal use: For non-SAP employees, these are not different from non-released RFMs.

  • Released for external use: In theory, SAP guarantees that there will never be any incompatible changes to a released RFM. In practice, this is mostly true, but there are exceptions.

BAPIs (of which there are almost 2,000 in 4.6C) are RFMs with a few special attributes:

  • Once a BAPI has been released (always for external use), it is guaranteed to be upward-compatible. (Exceptions to this rule exist, but are very rare.)

  • If incompatible changes are required, SAP will create a new BAPI and mark the old one as obsolete. Obsolete BAPIs are guaranteed to work at least in two functional releases, starting with the one in which they were declared obsolete. (In other words, a BAPI made obsolete in 4.0A has to work until at least 4.5B.) This gives developers at least two years in which their application will not have to be modified, since SAP publishes not more than one functional release per year.

  • BAPIs are defined as methods of business object types in the Business Object Repository (BOR). This makes it much easier to find suitable BAPIs, compared to non-BAPI RFMs. (The best starting point for any interface research is, by the way.)

  • BAPIs should follow all the rules laid down in the BAPI Programming Guide (available in the online documentation). Some of the things that BAPIs should not do are: throwing ABAP exceptions, invoking COMMIT WORK (since 4.0), and using the SAP internal format for currency amounts. If you have been following my articles in the SAP Professional Journal (,3 you know that there are exceptions to all these rules, but most BAPIs are well-behaved.

Customers can write their own RFMs and BAPIs in ABAP.

All RFMs (hence also all BAPIs) can do whatever they want in the SAP system. RFMs can retrieve information and return it to the client as well as update the database. Typical BAPIs used in a web sales solution would be Customer.GetDetail, to retrieve information about a customer, and SalesOrder.CreateFromData, to create a sales order for a customer.


IDocs were originally invented to support Electronic Data Interchange (EDI) in a generic fashion, without the need to understand the idiosyncrasies of EDI standards like EDIFACT or X.12. The concept was then generalized into Application Link Enabling (ALE), which allows SAP and other SAP or non-SAP systems to exchange information. IDocs are business messages that are processed asynchronously. SAP as well as non-SAP systems can send and receive IDocs. IDocs are used to update information in the target system. There are no return parameters, so IDocs cannot be used to immediately return information to the sender (client). Since the sender does not even know whether the IDoc could be processed successfully, the receiving system needs to have workflow capabilities to deal with errors. Workflow is easily configurable in ALE. Non-SAP systems have to provide equivalent capabilities.

IDocs are based on a hierarchical segment structure. The syntax for each IDoc type is defined in the SAP system.

Non-SAP systems can subscribe to information in SAP and automatically receive appropriate notifications (IDocs). An example would be a web sales application that keeps a replicated database with customer information in order to avoid constant BAPI calls to retrieve that information. After the subscription has been set up and the current customer information has been downloaded, the application would receive IDocs whenever a customer has been added, deleted, or changed.

The same application could also use IDocs instead of BAPIs to create sales orders, but due to the asynchronous nature of IDoc processing and the fact that no information is returned, the application could not tell its user whether the sales order creation succeeded, what the sales order number is, etc.

IDocs can be transmitted in a variety of ways. The most common one is a special form of RFC, called transactional RFC (tRFC). More about this later in this article.

Customers can create their own IDoc types or extend existing ones.


While BAPIs and IDocs are mainstream interface technologies, interfaces based on the Dynpros (screens) of SAP transactions should only be used in customer projects when no other option exists. (An exception is any web application based on the Internet Transaction Server (ITS). But before writing new ITS applications you should check the exciting capabilities of SAP's Web Application Server!)4

Updating the SAP database by feeding data into the screens of an SAP transaction has huge maintenance implications. Whenever the layout of a screen changes (such as new mandatory fields being added, or fields being moved from one screen to another one) you have to modify your interface programs. Achieving release-independence using Dynpros is impossible.

BAPI or IDoc or Dynpro?

In many non-trivial applications, you will combine BAPIs and IDocs. Use BAPIs for data retrieval (e.g., the delivery status of a sales order) and updates (e.g., sales order creation). Use IDocs for keeping replicated databases up-to-date (e.g., a customer database).

Applications without any user interface will probably use only IDocs. This is especially true if information arrives from another system asynchronously (as in a queuing approach) and needs to be forwarded to SAP. Using IDocs means that the sender does not have to worry about application error handling, since the properly configured workflow in ALE will take care of this.

Dynpros should be considered as an interface technology only if no BAPIs and IDocs exist and it would be too expensive and/or time-consuming to build new ones.

Remote Function Call (RFC)

RFC is the SAP protocol for Program-to-Program communication. It is bi-directional, which means that you can write client programs that call a function (an RFM) in SAP as well as write a server component that gets invoked from within an SAP component (like R/3).

There are three flavors of RFC for different purposes:5

  • Synchronous RFC (sRFC)

  • Transactional RFC (tRFC)

  • Queued RFC (qRFC)

Normal client applications use Synchronous RFC. The client calls an RFM and gets the results (the export parameters) back. This allows the client to check the return code from the RFM and use the data returned by the RFM (e.g., the sales document number of a created sales order).

Transactional RFC was invented primarily for IDocs. No parameters are returned to the client, which makes sense since IDocs are processed asynchronously anyway. The advantage of tRFC for IDoc transport is that the protocol guarantees that any message (IDoc) is only processed once, even if the client or server fails in the middle of the communication.

Queued RFC is a very recent, improved version of tRFC which has two major benefits: it guarantees the sequence of the processing of messages within a given queue, and it allows the administrator to limit resource consumption of incoming messages.6 Whenever possible, you should use qRFC instead of tRFC.

How do you develop RFC-enabled applications?

ABAP supports RFC very nicely, which makes it easy for ABAP developers to invoke functionality in other SAP or non-SAP components.

For non-SAP components, there is a library called the RFC Library (RFCLIB), which is available on all SAP-supported platforms, including Win32 and Linux.7 Developers can use this library in all programming languages that support the C calling conventions, but usually only C and C++ developers use the native library. For everybody else, there are…

RFC-Based Middleware Products from SAP8

Currently, there are three recommended middleware products for developers of non-SAP RFC-enabled applications:9

  • The SAP Java Connector

  • The SAP DCOM Connector

  • The SAP ActiveX Controls

The SAP Java Connector (JCo)

This product is a state-of-the-art, high-performance encapsulation of the RFC Library that supports all features of RFC. You can build desktop and web applications, client and server components, and use all three flavors of RFC. JCo allows you to invoke RFMs as well as to send or receive IDocs. If you have a choice of programming language, I recommend that you use Java and JCo. JCo has a very consistent architecture, supports multiple platforms, and is a lot of fun to work with. You can download the product from The BIT526 training class (formerly known as CA926) teaches you all aspects of using JCo.

The SAP DCOM Connector

The SAP DCOM Connector (together with its cousin, the SAP COM4ABAP component) can be used to build RFC-enabled client and server applications on Microsoft platforms. Visual Basic and other COM/DCOM-enabled development environments (e.g., Visual C++, ASP, Borland Delphi) can be used to access the SAP DCOM Connector. Due to its design, the SAP DCOM Connector supports higher-volume web servers based on Microsoft IIS.

Developers using the SAP DCOM Connector generate proxies for the RFMs they want to invoke. These proxies facilitate development because the methods and their parameters are visible within the development environment (IntelliSense). These same proxies need some administrative effort, though, since regenerated proxies will have different GUIDs than the original ones, which means that your client programs will need to be recompiled as well. Nevertheless, in almost all cases, the SAP DCOM Connector is the best choice if you are building applications exclusively for Microsoft platforms, and do not like Java for whatever reason.

The SAP DCOM Connector (as well as the SAP ActiveX Controls discussed next) are thoroughly covered in the BIT525 training class (formerly known as CA925).

The SAP ActiveX Controls

These client-side-only controls are also for the Microsoft platforms. They should not be used to build web applications since they were designed for a desktop scenario. Since the SAP DCOM Connector offers all the functionality of the BAPI and Functions controls, the only reason for using the SAP ActiveX Controls in new projects would be that you do not want to (re)generate proxies. Both the SAP DCOM Connector and the SAP ActiveX Controls can be installed from the SAPGUI (Presentation) CD.

The SAP Business Connector

More and more business transactions are executed over the Internet, using XML as the container format. The SAP Business Connector allows you to connect an SAP system to any XML-compliant system in your intranet or across the Internet. In many cases, no programming is required; you will just have to map between the SAP format and the external XML format. A suitable mapping tool is included in the product. SAP Business Connector "speaks" sRFC and tRFC and can be used to send or receive IDocs as well as invoke all RFMs.

You can download the product from

BIT530 (formerly known as BC635) is the SAP training class for the Business Connector.

Obsolete RFC-Based Middleware Products from SAP

In the introduction I mentioned that SAP has put a lot of effort into making its products as open as possible. Some of the middleware components released in the past should no longer be used, though. OSS Note 0423522 lists those components and the suggested replacements. You should not start any new projects with the components listed there as obsolete. Since the SAP Automation GUI Interface, which was used to invoke Dynpros from Microsoft platforms, is amongst the obsolete components, the question arises as to how you can drive SAP transactions from outside SAP. The answer is very simple: write an RFM (in ABAP) that calls the transaction and invoke this RFM using any of the approaches outlined above.

If you have any further questions on any of the topics discussed in this article, contact SAP or send me an e-mail at or For more information on the aforementioned training classes, contact your local SAP country organization.

1 Integration with SAP Business Workflow is not discussed, since I am not really qualified enough to do it justice.

2 More about RFC later in this article.

3 Cf. "Currencies and Currency Conversions in BAPI Programming" (September/October 2001), "Everything a BAPI Programmer Needs to Know About the Business Object Repository" (January/February 2001), and "Transaction Handling in SAP R/3 - What Every Programmer Needs to Know" (July/August 2000).

4 See "From 'SAP Basis' to 'SAP Web Application Server' - It's Much More Than Just a Name Change!" by Franz-Josef Fritz in the July-September 2001 issue of SAP Insider.

5 A fourth flavor, called Asynchronous RFC (aRFC), is only available for ABAP-to-ABAP communication.

6 For details on this, please refer to the SAP documentation.

7 Refer to the SAP documentation for a complete list of supported platforms.

8 Several non-SAP products are available as well, but I do not have the space to discuss them in this article.

9Also see the discussion of the SAP Business Connector below.

Thomas G. Schuessler is the founder of ARAsoft (, a company offering products, consulting, custom development, and training to a worldwide base of customers. The company specializes in integration between SAP and non-SAP components and applications. ARAsoft offers various products for BAPI-enabled programs on the Windows and Java platforms. These products facilitate the development of desktop and Internet applications that communicate with R/3. Thomas is the author of SAP's BIT525 "Developing BAPI-enabled Web Applications with Visual Basic" and BIT526 "Developing BAPI-enabled Web Applications with Java" classes, which he teaches in Germany and in English-speaking countries. Thomas is a regularly featured speaker at SAP TechEd and SAPPHIRE conferences. Prior to founding ARAsoft in 1993, he worked with SAP AG and SAP America for seven years. Thomas can be contacted at or at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!