Select language:

Procedure documentation Configuring the Polling Mechanism 


For security reasons, the Internet imposes certain limitations on server-client interactions; for example, a server cannot initiate contact with a client, unless the client first sends a request to the server. To overcome this restriction in the Collaboration environment, a polling mechanism was developed to support certain components, such as RTC. Polling enables clients (portal end users) to interact with one another using the RTC server as an intermediary point of contact.

Polling is necessary to facilitate communication between clients and to control a wide range of events in the Collaboration environment. RTC uses the Real-Time Messaging Framework (RTMF) as an infrastructure for transferring messages between clients and servers in the portal environment. Clients are connected to the RTMF server through an RTMF client running in a hidden frame in their portal browser. For information on activating the RTMF client, see Configuring the Masthead for Collaboration.

Examples of events controlled by RTMF:

  Instant messaging.Messages are sent from user to user via the Portal server. The sender’s message is stored in the server, and from there the targeted recipient picks it up. See figure below for an example.

  Session invitations.Portal users send invitations to other users to join application sharing sessions. The session host’s invitation is stored in the Portal server, and from there the targeted participants pick it up. Each participant’s reply is sent back to the host via the RTC server in the same manner.

  Availability status. The presence of active users in a session is also monitored by the polling mechanism via the RTC server.

  Session-specific tasks. For example, during an application sharing session, a participant’s request to take control of the host’s cursor and the subsequent response by the host is also controlled by the polling mechanism via the Portal server.

  Online/offline status. Via RTMF, the Portal server tracks which users are logged on.


RTMF does not affect the Application Sharing Server. The streaming of data in an application sharing session is managed solely by the Application Sharing Server.

Every RTMF-based client sends an automated request to the RTC server every number of seconds to check if messages, events, requests, or invitations have been sent to it. The time between each check is commonly referred to as the polling interval. The polling mechanism, if not configured properly, has the potential to generate load on the Portal server as the total number of users increases.

This graphic is explained in the accompanying text

The figure above illustrates two clients communicating through instant messaging. The events are logged chronological from top to bottom. In this example, each client polls the Portal server, via the RTMF, at regular 3 second intervals.



The procedure below describes how polling is activated per user at runtime, how to configure the polling interval, and what to consider in order to vary and limit the load generated by the polling mechanism. You choose the polling policy which best suits your environment, and then configure the parameters relevant to that scenario. 

You need to configure the polling settings so that the system does not become overloaded, but at the same time, in a way that end users do not notice a major decrease in performance over time. Keep in mind that the greater the polling interval, the less frequently users will receive updates.



  You have installed the SAP NetWeaver Collaboration component.

  You have access to the Collaboration Launch Pad Administration component in the portal. By default, this component is assigned to the Content Administration role.





  1.  In the portal, navigate to Content Administration Collaboration Content Collaboration Launch Pad Administration. Then, under Related Links, choose Configure Real-Time Collaboration RTC Engine RTCEngine.

Alternatively, you can navigate to System Administration System Configuration Collaboration. Then, under Folders, navigate to Collaboration Real-Time Collaboration (RTC) RTC Engine   RTCEngine.

  2.  Define how the polling mechanism is activated for each user at runtime as follows:

  Deselect the StateBasedRTC checkbox (default setting): Polling always takes place, regardless of the availability status set by the user.

  Select the StateBasedRTC checkbox: Polling only takes place when a user sets the availability status in the Collaboration Launch Pad to Auto-Detect Status. For any other status, polling for that user does not take place.


Be aware that if polling does not take place, none of the events controlled by RTMF are activated for that user. For example, a user will not receive any instant messages, events, requests, or invitations.

  3.  In the PollingPolicy drop-down list, choose the type of polling you want to implement, and then configure the relevant parameters, as described in the following table (to edit a parameter, select its checkbox and then click Edit):


Certain parameters are tagged as advanced parameters. To display advanced parameters with the basic parameters, you need to switch the view of the configuration editor. See Normal and Advanced View in the Configuration iView.

Polling Policy


Detailed Description and Configuration*

Constant Interval
fixed polling interval)


The polling interval is fixed and is set in units of seconds. The default polling interval is 3 seconds. The minimum value is 1 second and the maximum value is 120 seconds.

This means that the intermediary server contacts the RTC server every 3 seconds, no matter how many users are using the system. High numbers of concurrent users may cause the polling mechanism to overload the system and users will be likely to notice a reduction in performance.

You define the fixed portal interval in the PollingIntervalBasis parameter, in units of seconds.

Linear Interval
(incremental polling interval based on number of concurrent users*)


This option enables you to increase the polling interval linearly in increments of 1 second for every n-number of concurrent users. You define the n-number of users in the PollingIntervalUsersStep parameter, in units of users.

The default value is 30 users. The minimum value is 10 users.

The initial polling interval is the value defined for a fixed interval (PollinIntervalBasis). You cannot modify the increment value; it is always 1 second for every n-number of concurrent users you define.

For example, if the initial polling interval is 3 seconds and is increased by 1 second every 100 users, the polling interval will be 5 seconds when 200 concurrent users are using the system.


With this option you are unable to limit the number of hits the RTC server receives per second (see Constant HPS in this table). Performance is likely to be an issue with a larger number of users. 

Maximum HPS
(dynamic interval based on a maximum hits* per second (
HPS) ceiling)


This option enables you to set a maximum fixed hits per second ratio which the RTC server must not surpass, thus limiting the load on the server generated by the polling mechanism.

hits per second (HPS) ratio = [number of concurrent users] / [polling interval time])

If the hits per second ratio at any given time is less than the maximum value you defined, the Linear Interval policy will be enforced (see above). However, if the system detects that the hits per second ratio has been reached at any given time due to an increased number of concurrent users, the RTMF automatically changes the polling interval time accordingly to maintain the maximum hits per second ratio defined by you.

The hits per second ratio is reciprocally related to the polling interval; when comparing a given hits per second ratio, the higher the number the concurrent users, the greater the polling interval time needs to be, while a lower number of concurrent users reduces the polling interval time.

For example, if the maximum hits per second ratio is 100 hits/second the polling interval will be no more than: (i) 2 seconds for 200 concurrent users, and; (ii) 5 seconds for 500 concurrent users.

You define the maximum hits per second ratio in the PollingMaxHPS parameter, in units of hits (users) per second.

* A “user” is defined as portal user running an active RTMF client; in other words, a user does not necessarily need to be actively running a Collaboration-based application in order to be part of the above calculation. A “hit” is defined as a single polling request generated at a given time by a user.


For information on configuration additional parameters in the RTCEngine topic, see Configuring Maximum Numbers of Sessions and Users Allowed.