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
- BAPIs (Business Application Programming Interfaces): BAPIs are actually
a special case of RFC2-enabled Function Modules
- IDocs (Intermediate Documents): IDocs were invented originally to
- 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
- 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 http://ifr.sap.com,
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
you know that there are exceptions to all these rules, but most BAPIs
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
- 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
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 http://service.sap.com/connectors.
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
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 http://service.sap.com/connectors.
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
or email@example.com. For more information
on the aforementioned training classes, contact your local SAP country
Integration with SAP Business Workflow is not discussed, since I am
qualified enough to do it justice.
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
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.
A fourth flavor, called Asynchronous RFC (aRFC), is only available
for ABAP-to-ABAP communication.
For details on this, please refer to the SAP documentation.
to the SAP documentation for a complete list of supported platforms.
Several non-SAP products are
available as well, but I do not have the space to discuss them in this
see the discussion of the SAP Business Connector below.
Thomas G. Schuessler is the founder of ARAsoft (www.arasoft.de),
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 firstname.lastname@example.org
or at email@example.com.