[ Team LiB ] Previous Section Next Section

What Is JCo?

SAP, recognizing the power of Java, first released Java connections with a CORBA environment that worked with already-released connection technology for C and Visual Basic programming. This initial product was buggy and incredibly frustrating to work with. In late 2000, SAP announced JCo, a JNI-based solution that enabled Java programmers to work with the same technologies they're used to. JCo worked much better than the CORBA version, which required the IDL interfaces to be regenerated every time the interface changed within SAP, whether or not it was used in the Java application. JCo enables Java programs to call SAP remote function call–enabled functions; conversely, JCo also enables SAP to call Java programs. JCo works with any SAP system after 3.1H and is available for many platforms, including Windows and Linux.


SAP JCo should not be mistaken for the J2EE-CA resource adapter for SAP. The first has a proprietary interface that is widely used. The second is in beta form and was not recommended for production environments at the time of this book's release. The resource adapter for SAP is covered in Chapter 31, "Legacy Integration with the J2EE Connector Architecture," as an example of a current J2EE Connector Architecture. The resource adapter has a standard interface, but came out much later, so it's not as common. In the future this could change.

Remote Function Call

Any realtime communication by SAP systems to the outside world is done through remote function calls (RFCs). There are three kinds of RFCs: synchronous, transactional, and queued. A Java program normally attaches to a synchronous RFC.

ABAP can be used to write different kinds of programs in SAP. One kind of program is a function module. A function module that's RFC-enabled can be called from an external source. SAP has delivered several thousand RFC-enabled function modules, including business application programmer interfaces (BAPIs) that encapsulate the SAP internal business process and enable external systems to interface to it. BAPIs are technically constructed the same as RFC-enabled function modules, but are grouped together in the SAP business object repository (BOR) and have some additional features for organizational purposes. As far as a Java programmer is concerned, when connecting to SAP through JCo, a BAPI and an RFC-enabled function module are the same. BAPIs and RFC-enabled functions can have two different states:

  • Released— The function module has been released for customer use, and SAP promises not to make major changes to the function.

  • Not Released— The function module is not ready for production-level applications, and SAP reserves the right to make changes as necessary.

It's not uncommon to use unreleased RFC-enabled functions. Just beware of problems that can arise when SAP administrators apply support Hot Packs that fix bugs and provide extended functionality between releases. When that happens, a system that worked one minute can be broken the next.


In fact, even released functions can sometimes be changed and require updates on the Java side. This happens infrequently, but when it does, problems can arise in external systems. If this occurs, be sure to contact an SAP Basis person to find out what the Hot Pack changed.

SAP Data Handling

RFC-enabled function modules use three different types of data:

  • Import parameters— Parameters that are being sent into the function module before processing

  • Export parameters— Parameters that are being sent back to the calling program after processing

  • Table parameters— This type can be sent in and received back

Import and export parameters can be a field or a complex structure. A field is the smallest abstraction of data for JCo, whereas a structure is a set of ordered fields that is equivalent to a row in a table. A table is a structure with multiple rows.

Each import and table parameter can be specified as either optional or mandatory within the function module configuration. Export parameters are always optional.

SAP Data Dictionary

One of the best features of SAP is the separation of data from the actual database native data types. The separation takes place in the SAP data dictionary. Each field value in a parameter is based on either a native SAP data type or a data element in the data dictionary. Each element is dependent on either a built-in data type or a domain. A domain stores information such as the SAP native data type, length, number of decimals, output length, conversion routine, and check table.

The conversion routine and check tables are specific to SAP. Conversion routines convert data from the internal format SAP stores to an external format for displaying the data. Unfortunately, this isn't handled automatically within RFC calls. Programmers have to convert data on the inbound to make sense within SAP. For instance, the DOC_TYPE field is used in the SAP order type field within BAPI_SALESORDER_SIMULATE in the ORDER_HEADER_IN structure.

A standard SAP order type is OR. Most people would incorrectly assume that populating it with OR would cause a standard order to be created. Actually, an error will be thrown because the internal type TA is assigned to OR, and a conversion routine converts it from OR to TA when it's displayed within SAP. Several conversions might take place, depending on the domain.

Help values are the possible entries for a field. They're very helpful in SAP because most fields are based on codes that must be correctly entered. Help values could be useful when programming outside of SAP, but these values are normally restricted for users in a Web application because such users don't understand all the SAP codes.

There are BAPIs in SAP that convert values in and out of SAP and get the help values for specific fields. These are mentioned later in this chapter in the "Useful BAPIs and RFCs" section.

    [ Team LiB ] Previous Section Next Section