Tips & Tricks - Polling


This workshop demonstrates how you can deliberately replace the content of a page in just a few minutes using the Intrexx polling mechanism - and only when this is actually required. It is aimed at readers with some programming experience. It is a common requirement that parts of a page (e.g. one or more tables) should be updated when changes are made to the underlying data records. This is especially the case when these are pages that are shown on shop floors, for example:

  • Andon board

  • Kanban board

  • Bulletin board

  • Packaging regulations

  • Up-to-date information about manufacturing steps at a machine

  • Dashboards

and many other use cases. The function is required when the portal is not directly operated by employees but when a highly-visible screen needs to be refreshed automatically. Developers usually take the approach of reloading the entire displayed page with all of its elements in these cases. However, this creates unnecessary workload for the server because you do not always need to refresh all of the content. This approach can lead to long and increased loading times for many procedures.

Example files

The example files "70-test-polling.xml" (Spring configuration) and "" (application and process) can be downloaded here.


Intrexx provides a functionality that enables a number to be queried on the server. This number is connected to a key.

Example: "testKey": 15

When a data record is changed and you want to force a refresh, you can increase this number using an Intrexx process. The browser page requests this value at a predefined interval. As soon as the value changes, the polling mechanism calls up a function defined by you. Here is the sequence:

"testKey": 15 -> Change to data record is triggered -> Process reacts and changes the value: "testKey": 16 -> Polling is triggered: Reload content

The advantage of this method is that the request of the polling endpoint only takes about 4-5 milliseconds. However, reloading the entire page would take much longer - up to 100 times longer with a lot of content.


Definition of the polling endpoint

The polling endpoint is a Java class with the name "JsonUsnPollingEndpoint". The polling endpoint is a Java class with the name "JsonUsnPollingEndpoint". It has the property of returning the value to the client in a JSON structure. To do so, proceed as follows:

  1. Create a file with a name (as unique as possible) in the portal directory internal/cfg/spring (e.g. 77-mytestpolling.xml). Create a file with a name (as unique as possible) in the portal directory internal/cfg/spring (e.g. 77-mytestpolling.xml). This is insignificant in the case of polling.

  2. Copy the following content into this file:

    <?xml version="1.0" encoding="UTF-8"?> 
    <beans xmlns="" xmlns:xsi="" xsi:schemaLocation="">
    <!-- Polling endpoint configuration --> 
    	<bean class="de.uplanet.lucy.server.polling.PollingEndpointConfigurator">		
    		<property name="endpointName" value="testKey" />		
    		<property name="endpoint">			
    			<bean class="de.uplanet.lucy.server.polling.JsonUsnPollingEndpoint" /> 
  3. Then save the file.

  4. Restart the portal service so that the new polling endpoint is active.

Increase the value in the polling endpoint via a process

To do so, proceed as follows:

  • Create a new process.

  • Create a data group event handler that responds to your application.

  • Add a Groovy script action. The value of the polling endpoint is increased with the following script:

    import de.uplanet.lucy.server.polling.PollingService;
    def endpoint = PollingService.getInstance().getEndpoint("testKey")
    if (endpoint) 

Polling JavaScript in the application

Now the following JavaScript needs to be added to your application for the polling. The page that should be refreshed needs to call the function "startPolling()" in the onLoad event. The function stopPolling() needs to be called in the onUnload event. The developer's task is to bring the checkReload() function to life. Currently, only a notification will be shown in the browser when a change has been made.

* Is called in the onload of the page. 
* Initializes the polling process 
* key: This value (in the example "testKey") is defined initially and must be used for the 
* Bean-Propertys. The polling EndPoint used will then be checked accordingly .
* success (optional): In case of deviation of the value the method checkReload() is called. 
* error(optional): If an error occurs while reading the value from the EndPoint, the 
* errorOnPolling() method is called in this example. 
* id: With this Subscriber-Id the polling works internally. So können z.B. zu einem 
* For example, multiple polling requests with different subscriber
* polling requests with different subscriber IDs can be started for an identical key. 
* Furthermore, it is thus also possible to dynamically adjust the polling interval (e.g. 
* little changes: slower) 
* millisec: Polling Interval in milliseconds, in the example 5000 
* @method startPolling 

function startPolling()
		key: "testKey", 
		success: function(){ 
		error: function(){
		id: "testId",
		millisec: 5000 

* Stops polling and should always be called in the OnUnload of a page 
* @method stopPolling 

function stopPolling()
	unregisterAjaxPolling("testKey", "testId"); 

//In this example the table is reloaded on the overview page 

function checkReload()

	alert("Page should be reloaded."); 
	return true; 

// In this example, a notification window is displayed. 

function errorOnPolling()
	Notifier.status.notify("Text: Error on retrieving reload information", "Titel: Polling", "ID: MyId"); 

Polling should always be used sparingly because it adds to the server workload. Choose your intervals carefully.