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.
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
However, you should only use a single server connection for debugging a Web Dynpro application.
6.
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.
7.
Define the security
settings
You 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).
Note that you have to make other settings to activate the Secure Network Connection on your Java Engine.
8.
Summary of the
defined parameters
The 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.