Creating JavaConnector (JCo) Destinations

If you are using an adaptive RFC model in a Web Dynpro application, two JavaConnector (JCo) destinations are required. The application receives the metadata over the first connection, and application data is supplied to the Web Dynpro application over the second connection.

When you deploy a Web Dynpro application that uses an adaptive RFC model, the required JCo destinations are created in the development component containing the RFC model.

You can, however, also use the Web Dynpro Content Administrator to define additional JCo destinations that are not deployed in a development component, irrespective of the Web Dynpro application. These JCo destinations are known as system-defined JCo destinations.

The data for JCo destinations is stored in the System Landscape Directory (SLD).

• You have administrator authorization on the Java Engine and access to an SLD.
• The Web Dynpro Content Administrator is running.

1. Choose Create JCo Destination. Either copy the data required for the JCo destination from an existing destination, or define a new connection with new data.
2. To define general data, create a logical name for the JCo destination. Alternatively, you can specify a client.
3. Specify the configuration of the JCo pool for a JCo destination.
   Note

   At runtime, the JCo connection is implemented with a pool. This pool is a set of client connections for a specific JCo destinations. The pool can automatically generate new connections for an SAP system and provides methods to return the connections to the pool if they are not needed any more. It also checks periodically which connections are no longer used by the application and can therefore be closed.To minimize the use of resources, you can define the maximum number of connections that can be contained in a pool by using the option Maximum Pool Size. The pool keeps as many JCo connections open as you defined for the maximum pool size and these connections do not have to be newly created. You can reuse these connections any time. The JCo pool can, however, contain more connections than you defined for the Maximum Pool Size. This number of connections is specified by the option Maximum Connections. This is the maximum number of connections that can be set up at runtime. If the number of Maximum Connections is higher than the number of Maximum Pool Size, the JCo connections that are not needed are immediately closed.If the application needs more connections than defined for Maximum Connections, the required connections are sent to a queue and can only be opened when other JCo connections are closed.

4. Define cluster

   Assign the JCo destination to a Java Engine cluster. A cluster means a distributed system of the Java Engine Dispatcher and further server elements. This system identifies the client as one unit. By default the locally installed Java Engine is selected.

5. Define the data type and connection type

Select the data type for the JCo destination. The destination type for data type Dictionary metadata can only be a load-balanced connection. You therefore cannot select a single server connection.

• There are two destination types available for data type Application data.

You then define the destination type. It can be one of the following:

• Load-balanced connection
• Single server connection
  Note

  However, you should only use a single server connection for debugging a Web Dynpro application.

1. Define the application server or message server.Below you can define the application or message server type, depending on the selected connection type. If you are using a SAProuter, you can also define the SAProuter string in this step. If you selected connection type Load-balanced connection, you must define a message server.
2. Define the security settingsYou have to take security matters into consideration and define the security settings when you specify a JCo destination. You first select the required authentication method for user authentication.
   • If you select User/Password, you must define a user and the corresponding password. This authentication method is used to define JCo destinations for metadata. The user is predefined for authentication method User/Password, and cannot be changed. This user is a technical user who does not need dialog authorization. The name and password assigned to this user must be known in the backend. The authorizations for this user must be set in the backend so that this user can access all DDIC function modules.
   • If you select Ticket, ticket authentication is expected and you need not define a user and password.
   • The same is true for Client Certificate (X509). You need not define a user and password here either.

You also have to make the settings for Secure Network Communication (SNC).

1. Summary of the defined parametersThe last step of the wizard gives you an overview of the defined parameters. To change parameters, navigate back to the location to be changed with Previous and make the corresponding changes.