jcosapjco3sap-r3

SAP JCo client vs server


We are trying to communicate with SAP R/3 from a standalone java application We will use the JCo 3.0 libraries for this.

From the documentation I understood that there are 2 ways to connect with SAP.

  1. as a JCo Client
  2. as a JCo Server

At first I was convinced that our application would need to connect as a JCo client. But I am starting to doubt.

Our application sends data. (e.g. update of order status) But our application also receives data (e.g. SAP pushes changes to the master data - MATMAS).

So, does it need to be a client or a server ?


Solution

  • There is no JCo Client in the JCo 3.0 API model but only JCoDestinations instead which replaced the old JCO.Client from the 2.1 API model.

    And the 2 ways to connect to SAP via the RFC protocol are:

    1. Inbound RFC communication (as an RFC client / Java calls ABAP)
    2. Outbound RFC communication (as an RFC server / ABAP calls Java)

    For inbound RFCs you need to use a JCoDestination for executing a remote function module at ABAP side. For outbound RFCs you need to register a JCoServer at the SAP gateway which will then receive incoming requests from ABAP side in order to process a remote function module at Java side. In both communication directions there is a request and potentially also a response to this request, so the data flow is in both directions for inbound and outbound RFC communication. Inbound and outbound just distinguishes who initiates the RFC call.

    And regarding the JCoServer, you usually also need to define some JCoDestination as well for a repository, because this is needed by a default JCoServer for querying required RFC metadata from an ABAP back-end. Without such a JCoRepository, a JCoServer would not be able to interpret the incoming RFC request data. So in a typical JCo server scenario you need both: a JCoServer and a JCoDestination (for the server's JCoRepository).

    You can use the same configuration for the JCoDestination for both use cases (client calls and repository queries), but SAP recommends to define separate configurations which is more flexible regarding the definition of connection pool sizes and allows separate RFC authorizations for both use cases.