Introduction
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:
- Which Web Dynpro applications will be used by a user or role?
- For each of these applications, determine which application data destinations (or logical systems) are required.
- 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.
- 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.
Example:
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'
Calculation:
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.
Example:
- 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
