The Business Application Programming Interface (BAPI) is a powerful data access engine, and SAP offers you a formidable toolkit that will put it to work for you. But thoughtful consideration of the peripheral technologies will make your BAPI bridge into SAP more effective, which in turn makes your application more elegant and effective.

When creating a BAPI to service an SAP application, you have a great deal to consider. Part of the point of SAP is to bring together a multitude of technologies and tie them into a single, cohesive, dynamic system. It’s easy to get lost in the magic of seeing business processes evolving before your eyes and to let details slip where differences in technologies are concerned.

BAPIs are remote function calls (RFCs) that post and retrieve business objects (such as sales orders and customer records) in interaction with SAP, from outside applications. They’re easy to create and configure, but there are many possible platforms for the applications that call them. A consultant must give some forethought to the available technologies when considering the use of BAPIs in the application.

What language will you use?
You have many choices available to you in creating your SAP-interactive application. Java is probably the standout, though some SAP environments have in-house SAP expertise, making the SAP language ABAP a popular choice. Visual Basic and C++ are also acceptable languages for SAP apps.

How do these applications tie in? Through an SAP/Microsoft utility called the DCOM Component Connector. With this utility, any language that is COM-compliant may be interfaced with ABAP.

For long-term applications, especially with SAP, ABAP may be the best choice. Why? Because no intermediate bridge per se is required to interface applications with SAP. In an ABAP application, all function modules may be SAP-internal (depending on your design). The extra steps required by SAP to accommodate remote function calls can go away. It’s simpler, and there are fewer points where transactions can break down.

What about Java? It’s a great choice because there’s a rich body of Java-based SAP technology in place already. Moreover, consider that BAPIs are, in essence, remote function calls. Java is a prominent choice due to its accommodation of both synchronous and asynchronous communication, enabling a large range of BAPI database interactions.

There’s a less complicated solution called the Internet Transaction Server. It works with Web browsers and facilitates simple SAP-interactive functions, such as reporting and RFCs. It’s an SAP product, and it is ABAP-based. You can mingle it with HTML, which is convenient. But you’ll need to do manual HTML generation to use it, and you’ll need a Windows NT server.

You can also generate object-oriented GUIs for a SAP interface. When you do this (in C++ or Java, or possibly Visual Basic), you’re basically replacing a standard SAP screen with an application-specific substitute. This is fine—it’s easy and convenient; but remember that if you do this, you’re locked into SAP’s screen sequence, so an upgrade in SAP means changing this application to match.

Who’s talking to whom?
The pattern of dialogue between the application and SAP is an important factor to think about when choosing your platform. Consider that in a two-way communication—where either SAP or the application may act as client, (e.g., either side may call the other)—you’ll get the best result if you use a BAPI to do the call, which is by definition an RFC, regardless of direction.

The flip side of this consideration is that if SAP will always be the server, and the application will always be the client, you really don’t need a BAPI to be the interface. In that scenario, SAP will accommodate whichever interface is convenient, and you may use some generic technology that you already have available for some other use. (Consider, however, that continuity in the design of your SAP-interactive apps will be of service to consultants down the line, so you may wish to use BAPI as your interface even if other options are available.)

Who’s going to look after it when you’re gone?
This is always a consultant’s concern, but it’s easy to overlook amid the newness of SAP applications from your client’s point of view. When designing the application, take into consideration what the in-house staff knows about interfaces.

For example, are the SAP-interactive applications that are already in place strictly RFC-driven? If so, the BAPI is your best choice for interfacing, and an RFC-friendly language (Java) is the platform you want. On the other hand, some shops have invested in the SAP product Business Connector, an XML-based interface product, and if the in-house staff knows this product, perhaps you’ll wish to go with it, as well.

It’s an odd time to be working in SAP R/3, as the massive explosion of implementations during the past six years settles into maintenance and growth. It’s a time when efficiency and experience are at a premium, and you must be more than a technician. Think carefully about your client’s environment and how best to build on what’s already there, and your BAPI applications will shine.