There are different connection options that AS Java can use for an Enterprise Information System (EIS). The type of connection option also depends, for example, on the EIS. As examples, we will mainly take a look at AS Java or AS ABAP systems as the EIS in this lesson.
AS Java can open outbound connections directly from an application or the connection can be established by a service. One of these services is the destination service, which we will take a closer look at in this lesson. Direct connections of applications to an EIS are covered in the appendix of this unit; the type of connection depends on the corresponding adapter. Applications can use connections to an EIS via services. Likewise, services can use the connections of other services.
The destination service can administer both HTTP and RFC connections to an EIS. Connections to SAP systems with AS ABAP are mostly of the type RFC, whereas connections to an SAP system with AS Java are mostly of the type HTTP. In an SAP system with AS ABAP and Java (Dual-Stack), the type of connection will depend on whether the connection is opened primarily for AS Java or AS ABAP. But be careful: Dual-Stack systems are not supported as of SAP NetWeaver release 7.5. After the installation, some entries (for example, for the connection to the SLD) were already created in the destination service. You can create and maintain destinations in NWA under Configuration → Infrastructure → Destinations. You define the communication type HTTP or RFC when you create a new destination. In a connection of the type HTTP, the connection to the EIS and the service that is to be addressed is determined via a URL. If the EIS is AS ABAP that is to be addressed via HTTP, SID and language can be defined in the destination data or client of the target system. In the Logon Data, for example, different authentication mechanisms, such as "entering user and password", " X.509 certificate", "assertion ticket", "logon ticket" or "user mapping" can be set up.
Hint
With regard to the security guidelines, you should check whether you can use user/password as an authentication method or better still another authentication method, "assertion ticket" for example.
In connections of the type RFC, the target server (Target Host), instance number (System Number), SID and data with regard to the gateway are specified. RFC connections always require a gateway through which communication takes place. An AS ABAP system is usually involved in an RFC connection. Since each AS ABAP instance contains a gateway, this is used for RFC communication. As of AS Java 7.10, each AS Java Central Services instance contains an RFC gateway, which can also be used for RFC communication.
The data with regard to the gateway includes the Gateway Host on which the gateway runs (in most cases, it is identical to the target server specification if we are talking about an AS ABAP instance) and the Gateway Service that usually runs on port 33<instance_number> or can be specified as sapgw<instance_number> (for example, this is port 3310 or sapgw10 for instance number 10 of the target instance). You can also switch between different authentication mechanisms in the logon data. If the RFC trace is activated, trace files of the type jrfc<process ID of the server process>_<Nr>.trc as well as the developer traces (dev_jrfc.trc) are created at operating system level of the instance in the server directory.
The JCo RFC Provider service is responsible for incoming RFC connections. RFC communication takes place mostly with SAP NetWeaver AS ABAP systems. Since RFC communication takes place via a gateway, the gateway of the AS ABAP instance is mostly used.
AS ABAP is the initiator of RFC communication to AS Java. The JCo RFC Provider in AS Java receives the data; therefore, the connection between the JCo RFC Provider and the gateway must already be established. You can maintain the connection to the gateway in the NWA of AS Java under Configuration → Infrastructure → Jco RFC Provider. You must start the connection to the gateway so that AS ABAP can use it for communication to AS Java. The connection for the gateway is established under the Program ID (the name of the JCo RFC Provider). An RFC destination of connection type "T" (maintained in transaction SM59) must be created in AS ABAP for communication; the Program ID (name) of the JCo RFC Provider is specified as a "Registered Server Program" for this. The name of the RFC destination in AS ABAP may differ from the program ID; for reasons of clarity, however, the same name for the program ID and the RFC destination is usually chosen. The gateway data, used to run the communication, is specified in the server configuration for the JCo RFC Provider; the number of parallel connections that should be possible for AS Java via this destination is also specified (field Server Count). If the option Local JCo Servers is selected, then only one server process is responsible in the system for the communication; this server process establishes the number of connections to the gateway configured in Server Count. If the option Local JCo Servers is deactivated, then each server process opens the number of connections to the gateway configured in Server Count.
The data of AS ABAP system that is to use this communication path is specified on the tab page Repository Configuration. If the checkbox Use RFC Destination is not selected, then the data for AS ABAP system is maintained on this tab page. If the checkbox Use RFC Destination is selected, then a destination that was maintained with the destination service is entered and the connection data stored there is used. However, in this case also, the Program ID of the JCo RFC Provider is registered in the gateway.
Of course, the data of the same gateway must be maintained in AS ABAP for the RFC destination, as with the JCo RFC Provider or the destination service.