!--a11y-->
Setting up a Web Dynpro Application for a
Logon Ticket 
You want to configure a Web Dynpro application that receives data from a SAP system with an adaptive RFC model so that it logs onto the SAP system with the user’s logon ticket.
If you use an adaptive RFC model in a Web Dynpro application, two JCo destinations are automatically created in the Web Dynpro Content Administrator. You must maintain these JCo destinations with this tool.
· With the first connection, the Web Dynpro application receives the metadata that is not user-specific and that is therefore the same for all users. It must be available to all users.
· With the second connection, the Web Dynpro application receives the application data, which is normally user-specific.
The JCo destinations for an adaptive RFC model have the following default names:
· WD_MODELDATA_DEST for application data
· WD_RFC_METADATA_DEST for metadata.

When you create JCo destinations, you can also give them different names. When the data for further adaptive RFC models is loaded from other SAP systems, you may not use the default names; you must define unique names for the JCo destinations.
The JCo destinations are displayed in the Web Dynpro Content Administrator when you select the corresponding development component or local Web Dynpro application in the Browse and Search Area.
You have administration permission for the J2EE Engine or SAP Enterprise Portal.
You set up the SAP system so that the logon tickets that are sent by the Web Dynpro application are accepted. These logon tickets can be issued by either the J2EE Engine on which the Web Dynpro application was deployed or another system, such as an SAP Enterprise Portal. For more information see Configuring the SAP Web AS ABAP to Accept Logon Tickets from the J2EE Engine.
...
1. Open the Web Dynpro Content Administrator from the URLs
a. directly with the URL http://<YourHost>:50000/webdynpro/dispatcher/tc~wd~tools/explorer
b. from the home page of the J2EE Engine with the following URL http://<YourHost>:50000/webdynpro/welcome by choosing Content Administrator.
2. Or in the top-level navigation of SAP Enterprise Portal select Content Administration ® Web Dynpro ® Web Dynpro Content Administrator.
3.
Select the required
development component or local Web Dynpro application in the corresponding
level in the Browse and Search Area. The first level local contains all the locally deployed Web Dynpro
applications. The second level contains all the development components and is
called by the vendor name, for example sap.com. On the JCO
Connections tab page
select the JCo destination you want to maintain and choose Edit.

4. A wizard with which you can define the JCo destination in individual steps opens.
a.
Define the general
data
At runtime the JCo connection is implemented with a JCo pool. You must define
the largest possible pool size. This is the maximum number of connections that
can be set up at runtime. You also define the client.
b.
Define the message server
You can define the message server below. If you are
using a SAProuter, you can also define the SAProuter string in this step. For
more information about the SAProuter, see the SAP Library under SAP NetWeaver
® Security
® SAPNetWeaver Security
Guide ®
Network
Infrastructure ®
Firewalls ®
SAProuter.
c. Define the security settings
You have to take security matters into
consideration and define the security settings when you specify a JCo
destination.
You select the required authentication method for user authentication.
If you select User/Password, you must define a user and the
corresponding password.
If you select the value Ticket, ticket authentification is expected.
The same is true for Client Certificate (X509). You need not define a user and password here
either.

To define the JCo destination for application data, select authentification method Ticket. The user’s logon ticket is sent to the SAP system.
To define the JCo destination for metadata, select authentification method User/Password. The data that is relevant for all users is now available. Since this authentification method technically only sets up a connection, resources can be saved, thus increasing performance.
d. Overview of the defined parameters
5. End the wizard with Finish.
6. Then perform the same steps for the second JCo destination. The order in which you process the JCo destinations is of no importance.
You maintained the necessary JCo destinations for an adaptive RFC model. If data is loaded from the backend for the user of the Web Dynpro application that contains this model, the user is logged on with Single Sign-On with logon ticket.
