Show TOC

Function documentationSAP Java Connector Locate this document in the navigation structure

 

SAP provides the SAP Java Connector (SAP JCo) to enable communication in the SAP NetWeaver Application Server between the ABAP and Java stacks. SAP JCo can be used for the internal communication of SAP NetWeaver Application Server, where the ABAP personality and AS Java interact using SAP JCo.

Note Note

Applications should move to Java Resource Adapter (JRA), which is the Java Connector Architecture encapsulation of JCo. The JCo RFC provider has been deprecated with Release 7.10.

End of the note.

You set up the JCo by registering AS Java as an RFC server to an SAP Gateway. This method, which is based on Remote Function Call (RFC) works in both directions:

  • Inbound

    Java calls BAPIs and RFC-enabled Function Modules (RFM) on the ABAP side and acts as a client.

  • Outbound

    ABAP calls functions on the Java side that acts as a server.

Calls from the SAP system are processed by the JCo RFC provider service of AS Java. It dispatches the call to a stateless session bean, which is registered in the Java Naming and Directory Interfaces (JNDI). Following the naming convention, the JNDI name used is identical to the name of the SAP function module. To parse the function calls from the SAP system correctly, the JCo needs access to an SAP system repository.

Features

The following graphic shows how you can configure the JCo for high availability.

This graphic is explained in the accompanying text.

Scenario for JCo
  1. On startup of the JCo RFC provider service (that is normally the startup of AS Java), the service:

    1. Connects to the SAP system repository

    2. Registers itself at the gateway with a defined name.

      It is possible to register under different names and at different gateways. But note that there is only a 1:1 relation between a name and a particular gateway. This has implications for high availability that are discussed below.

  2. An SAP system calls a function for the registered RFC destination. The function has to be defined in the repository.

  3. The gateway forwards the call to the JCo RFC provider.

  4. The JCo RFC provider looks in the JNDI for the Enterprise JavaBeans (EJB), which is registered under the same name as the function module in the SAP system.

  5. The JCo RFC provider calls the method processFunction(JCO.Function) of the EJB.

  6. The results of the call are passed to the gateway.

  7. The gateway passes the results back to the SAP system.

Relationship of Gateway to JCo

The JCo RFC provider service can register under one name to one particular gateway. To register to the same gateway with a second server, another name has to be used.

In the SAP system, you can configure an RFC connection under one name for one particular external program that has to be registered at the gateway. Optionally you can specify a particular gateway for the connection.

Within a Java cluster, all Java servers configure the JCo RFC provider service identically. This means that a particular program registration is valid on all servers and points to the same gateway, as shown in the graphic below. The gateway balances requests between different servers that are registered under the same program name.

This graphic is explained in the accompanying text.

Java Servers in a Cluster

If one Java server fails, the RFC connection still works with the other server in the cluster. However, if the gateway fails, the RFC connection no longer works, because a particular program name can only be registered at one particular gateway.

You can set up the gateway in one of the following ways:

  • Each SAP instance has its own gateway service, sapgw<systemnumber>, where external programs can be registered.

  • With the standalone SAP Gateway, you can install the gateway service separately from the SAP system, for example, on the same host as the Java server(s). In this case, the SAP system can access each external gateway under a different RFC connection.

Note Note

Choose the gateway setup that best fits your application scenario. When you use an option with different RFC connections, the ABAP application has to be aware of this.

End of the note.