Skip to Content

Web Dynpro Best Practices: How to Configure the JCo Destination Settings


Using the adaptive RFC model to get access to an SAP R/3 backend within a Web Dynpro application needs the configuration of JCo destinations. To get best performance and optimzed resource consumption (especially on systems with heavy user load), you have to make sure that these JCo destinations are configured correctly.

For general documentation about configuration of the JCO destination settings, please consult the following guide in SDN:How to use the Web Dynpro Content Administrator

The following weblog explains the details.

General Information

The JCo destination parameters depend on the way the Web Dynpro application has been designed and how it is used (e.g. one user works with one app in one window, with multiple apps in multiple windows, or, in the case of the portal, multiple apps in one window). Therefore, there is no general answer. Also, it depends on how the user is authenticated (SSO Ticket or defined user). 

We will now discuss the case in which the SSO ticket version is used. This is the standard configuration in production systems, whereas typically, defined users are used in test and development systems. The following assumes a production system only (using SSO ticket authentication). Also, the following recommendations are only valid for application data destinations (not for metadata destinations). At the end, you will also find a recommendation for metadata destinations. 

Parameter Maximum Connections

Basically, the administrator of the system has to determine, what the maximum amount of connections per user should be. This needs to be determined for each Application Data destination (also called logical system).

The information needed to determine this is:

  1. Which Web Dynpro applications will be used by a user or role?
  2. For each of these applications, determine which application data destinations (or logical systems) are required.
  3. Each application should specify, whether it only uses a single connection to the backend, or whether multiple connections are required. By default, each app uses one connection.
  4. How many applications can be launched simultaneously in a single user session?

With this information, the proper settings can be determined for each application destination.


1a) User in role ‘manager’ requires 3 different applications, let’s say ‘App A’, ‘App B’, ‘App C’
1b) User in role ’employee’ requires 4 different applications, let’s say ‘App C’, ‘App D’, ‘App E, ‘App F’

2+3 a) ‘App A’: 1 Destination: ‘WD_LISA_MODELDATA_DEST’      Max Connections required per App Instance: 1 (default)
2+3 b) ‘App B’: 1 Destination: ‘WD_MONA_MODELDATA_DEST’   Max Connections required per App Instance: 1 (default)
2+3 c) ‘App C’: 1 Destination: ‘WD_LISA_MODELDATA_DEST’      Max Connections required per App Instance: 2
2+3 d) ‘App D’: 1 Destination: ‘WD_LISA_MODELDATA_DEST’      Max Connections required per App Instance: 1 (default)
2+3 e) ‘App E’: 1 Destination: ‘WD_LISA_MODELDATA_DEST’      Max Connections required per App Instance: 2
2+3 f) ‘App F’: 2 Destinations: ‘WD_LISA_MODELDATA_DEST’    Max Connections required per App Instance: 2, ‘WD_MONA_MODELDATA_DEST’    Max Connections required per App Instance: 1 (default)

4a) User ‘manager’ can open up to 3 browser windows and uses the 3 different page configurations:


  •   – Page ‘M1’: ‘App A’ and ‘App B’  => 1 Connection for ‘WD_LISA_MODELDATA_DEST’; 1 Connection for ‘WD_MONA_MODELDATA_DEST’      
  • – Page ‘M2’: ‘App B’ and ‘App C’  => 2 Connections for ‘WD_LISA_MODELDATA_DEST’; 1 Connection for ‘WD_MONA_MODELDATA_DEST’       
  • – Page ‘M3’: ‘App C’                   => 2 Connections for ‘WD_LISA_MODELDATA_DEST’

4b) User ’employee’ can open up to 1 browser window and uses the 5 different page configurations:

  •      – Page ‘E1’: ‘App C’                   => 2 Connections for ‘WD_LISA_MODELDATA_DEST’
  •       – Page ‘E2’: ‘App C’ and ‘App D’  => 3 Connections for ‘WD_LISA_MODELDATA_DEST’
  •       – Page ‘E3’: ‘App C’ and ‘App E’  => 4 Connections for ‘WD_LISA_MODELDATA_DEST’
  •       – Page ‘E4’: ‘App C’ and ‘App D’ and ‘App E’ => 5 Connections for ‘WD_LISA_MODELDATA_DEST’
  •       – Page ‘E5’: ‘App F’                   => 2 Connections for ‘WD_LISA_MODELDATA_DEST’; 1 Connection for ‘WD_MONA_MODELDATA_DEST’


For each user and destination, determine the page requiring the maximum number of connections and multiply with the maximum number of concurrent browser windows:

   User ‘manager’, ‘WD_LISA_MODELDATA_DEST’ : 2 Connections x 3 (browser windows) = 6
   User ‘manager’, ‘WD_MONA_MODELDATA_DEST’ : 1 Connections x 3 (browser windows) = 3

   User ’employee’, ‘WD_LISA_MODELDATA_DEST’ : 5 Connections x 1 (browser windows) = 5

   User ’employee’, ‘WD_MONA_MODELDATA_DEST’ : 1 Connections x 1 (browser windows) = 1

Result: The maximum number of connections of each destination multiplied with a safety factor of 2 is the minimum number  to use for the parameter “maximum connections”

   ‘WD_LISA_MODELDATA_DEST’ :    6 x 2 = 12 connections
    ‘WD_MONA_MODELDATA_DEST’ :  3 x 2 = 6 connections

Remark: the parameter “maximum connections” can be reduced, if the number of connections per user is to be limited. But this may lead to severe error messages in the applications and is typically not the ideal way to improve performance or scalability. Use the parameter “PoolSize” instead!

Parameter Maximum Pool size

The parameter Maximum Pool Size is used to specify how many connections should be left open for the current user, even if they are not being used actively. 

A pooled RFC connection is allocated much faster than a new connection. Therefore, increasing the pool size will optimize the time needed to get a new connection. On the other hand, if a connection is pooled, it is not available for other users. Typically, ABAP backend systems define an upper limit for the number of RFC connections. Therefore, if this number has been fully allocated by pooled connections, then new users requesting a new connection may not succeed, because of the maximum number of connections allowed by the ABAP system having already been consumed.

It is therefore necessary to weigh off, what the scalability requirements for the J2EE system as well as the ABAP backend systems involved are. This value can also be further optimized in combination with the property Connection Timeout. (See further below for more details.)

Typically, the maximum pool size is kept very low and may even be set to 0. In case you have substantially less concurrent J2EE users than the number of concurrent RFC connections to an ABAP system, then the pool size can be increased to improve performance.


  • ABAP backend system ‘LOU’ allows 500 simultaneous RFC connections 
  • ABAP backend system ‘VRE’ allows 300 simultaneous RFC connections 
  • from the above calculation:     – 6 connections to ‘WD_LISA_MODELDATA_DEST’ are possible per user     – 3 connections to ‘WD_MONA_MODELDATA_DEST’ are possible per user  – under the assumption that the two destinations point to different ABAP backends, then a calculation must be made for each ABAP backend     – ‘WD_LISA_MODELDATA_DEST’ => System ‘LOU’ => concurrent J2EE users: 30 multiplied with nr. of connections (6) = 180, with 500 allowed => poolsize ~ 2     – ‘WD_MONA_MODELDATA_DEST’ => System ‘VRE’ => concurrent J2EE users: 30 multiplied with nr. of connections (3) = 90, with 300 allowed => poolsize ~ 3  – under the assumption that the two destinations point to the same ABAP backends, then a calculation must be made only for one ABAP backend     – ‘WD_LISA_MODELDATA_DEST’ => System ‘LOU’     – ‘WD_MONA_MODELDATA_DEST’ => System ‘LOU’        => System ‘LOU’ => concurrent J2EE users: 30 multiplied with nr. of connections (6+3) = 270, with 500 allowed => poolsize ~ 1

These are the minimum values possible. They can be increased if the parameter connection timeout is decreased appropriately.


Parameter Connection Timeout

The connection timeout defines how long the pool waits (in seconds) before a destination, which is in the range between 1 and the maximum pool size, is closed by the pool. This allows closing pooled connections after a certain amount of time if the user is no longer active. A typical value here is 10 – 30 seconds. After this time, the additional time needed to fetch a new connection is generally not noticeable by a user of a Web Dynpro application.


Parameter Maximum Wait Time

The maximum wait time defines how long you can wait (in seconds) before you get an exception after trying to get a destination although the maximum destinations are open. In a high user load scenario, it makes sense to increase this number appropriately (20-60); otherwise, the request may timeout very fast because no new RFC connection can be acquired. In low user load scenarios, this number can typically be reduced to a very low number (1-5 seconds), because waiting generally will not lead to success => the error message should be issued as fast as possible.


General Remark

All of the above numbers are highly dependent on the system landscape as well as the user load as well as the number and connection demand of deployed Web Dynpro applications. Therefore, the examples above only illustrate the process used to obtain the optimal values. Therefore, your personal judgment should also be taken into account when determining the final values.


User Authentication is Defined user

In case you are in a test or a development scenario, then it is often necessary to use a specific ABAP user, regardless of which user is currently logged onto the J2EE engine. In this case, you specify a defined or named user. In this case, the maximum connections as well as the pool size as determined above must be multiplied by the number of concurrent users expected. Here are some typical values for this scenario (again, these numbers must be adapted to your landscape!):

  • Maximal Pool Size      50        
  • Maximum Connections      100        
  • Connection Timeout      10        
  • Maximum Wait Time      10      


Metadata Destinations

Because this configuration is not used directly by an application, but rather by the AdaptiveRFC framework, this configuration is typically straight-forward and should be set as follows:

  • Maximal Pool Size      1        
  • Maximum Connections      5        
  • Connection Timeout      60        
  • Maximum Wait Time      10      
You must be Logged on to comment or reply to a post.
  • Hi,
    Very good blog..!!!
    I have one problem regarding JCo connection. I did post problem on Forum but did not get any reply.
    On my development server JCo creation takes very long time, while it takes very less time on quality and production server for same application.
    Can you give idea why it takes such long time... or what could be the reason for this...

    Jigar Oza

  • Based on various SAP documentation, for optimization purpose, it is recommended that Model objects in the same application share the same JCo connection by calling setConnectionProvider() method.

    For example, my application will have 4 Model objects (M1, M2, M3 and M4)that will make RFC calls to the same  R/3 back-end.

    My understanding is that only one JCo destination (ie 1 JCo pool) should be used; also, in order to use the same JCo connection, setConnectionProvider() method should be called. However, I would like to see some more complete codes snippets that implement that concept in  "real world".

    Instantiation of M1?
    Instantiation of M2?
    Instantiation of M3?
    Calling setConnectionProvider() by M2?
    Releasing the connection to the pool? (also, is it needed)?

    Also, I have the following question: what can be the drawback(s) of the connection sharing strategy if the application has several model objects (example 10 model objects)?

    • Hi Hortense

      The code snippets you require are as follows.

      First, instantiate the model using the static class WDModelFactory.  For instance:

      FlightModel fMod = (FlightModel)WDModelFactory.getModelInstance(FlightModel.class);

      Now that the model itself has been instantiated, the next step is to instantiate the individual model objects that represent the ABAP funtion modules.  For instance:

      flightBapi = (Bapi_Flight_Getlist_Input)fMod.createModelObject(Bapi_Flight_Getlist_Input.class);

      The instantiated model object can now be used directly to invoke the ABAP functionality (as long as the correct parameters have been supplied of course!)

      If you have several models that all connect to the same backend ABAP system, then the coding to cause models to share JCo connections is as follows:

      Model_1 m1 = (Model_1)WDModelFactory.getModelInstance(Model_1.class);
      Model_2 m2 = (Model_2)WDModelFactory.getModelInstance(Model_2.class);
      Model_3 m3 = (Model_3)WDModelFactory.getModelInstance(Model_3.class);

      Since all these models share the same logical destination, and have been instatiated by the same user in a single application, it does not matter which model instance is used as the reference.  If we assume that model instances m2 and m3 will use m1's connection, then the coding is simply:


      That's all there is too it.

      Connections do not need to be explicitly released back to the pool.  This happens automatically when the application shuts down.

      Alternatively, if your application fits the following criteria, then you should consider changing the model instances scope type from APPLICATION_SCOPE to TASK_SCOPE.

      o  Your application will be run simultaneously by a very large number of users.
      o Those users will typically have long time intervals between server round trips.
      o JCo connections are not needed every time there;s a server round trip.

      Changing the scope type of the model instance means that the JCo pool will only exist for the duration of the server round trip.  After that, the pool is destroyed.

      Although this means that potentially, a new JCo pool must be recreated every time there is a server round trip, the processing cost involved could well be much smaller that the cost to the backend system of having to hold a large number of JCo connections open that will only be used intermittently.

      This is a situation where you need to consider what impact the application's concurrent user population will have on the backend system.

      You shoudl also consider the type of backend functionality being used because if a single ABAP session is required in the backend system in order to process multiple RFC calls, then you will be forced to keep the scope type set to the default va;lue of APPLICATION_SCOPE.

      Please also see the eLearning presentation on this topic:

      Hope that helps

      Chris W