Using Controls in a WAN 

When you use controls in your programs, you place an extra load on the communication channel between the frontend and backend.  In a LAN, and particularly in a WAN environment, this can be a critical factor. 

The problem is alleviated somewhat by buffering mechanisms (see also Automation Queue). Use these points as a guideline to using controls in a WAN.

The documentation for the individual controls also contains more specific notes about using that control in a WAN.

Using CL_GUI_CFW=>FLUSH

The method CL_GUI_CFW=>FLUSH synchronizes the automation queue and the ABAP variables in it.  Calling it often generates a synchronous RFC call from the application server to the frontend.  To optimize the performance of your application, you should call this method as little as possible. 

It is often a good idea to read all control attributes in a single automation queue (for example, at the beginning of the PAI) and retrieve them in a single synchronization.  You should, in particular, do this when you read attributes that are not necessary in your event handlers or the PAI/PBO cycle.

You do not need to include a "safety flush" at the end of the PBO to ensure that all method calls are transported to the frontend.  A flush at the end of the PBO is guaranteed.  Consequently, you cannot construct an automation queue spread over several screens.

There is no guarantee that an automation queue will be sent when you call CL_GUI_CFW=>FLUSH. The queue recognizes whether it contains any return values. If this is not the case, it is not sent.

If you have a queue with no return values, and want to ensure that it is synchronized, you can use the Control Framework method CL_GUI_CFW=>UPDATE_VIEW. You should only use this method if you absolutely need to update the GUI.  For example, you might have a long-running application in which you want to provide the user with regular updates on the status of an action. 

After you have read the attributes of a control, the contents of the corresponding ABAP variables are not guaranteed until after the next flush.  The contents of the ABAP variables remain undefined until this call occurs.  In the future, there will be cases in which this flush is unnecessary.  They will be recognized by the automation queue and the corresponding flush call will be ignored. 

Creating Controls and Passing Data

Creating controls and passing data to them is normally a one-off procedure, which in comparison to using normal screen elements can be very runtime-intensive. You should therefore not use any unnecessary controls, or pass unnecessary data to the controls that you are using. 

A typical example is a tabstrip control with several tab pages.  If the pages contain controls, you should consider using application server scrolling instead of local scrolling, and not loading the controls until the corresponding page is activated by the user.  The same applies to passing data to the controls on tab pages.

If you want to differentiate between LAN and WAN environments when you pass data to a control, you can use the function module SAPGUI_GET_WAN_FLAG. In some applications, you may need to pass different amounts of data or use a complete fallback in a WAN application.  The environment affects, for example, the number of same-level nodes that you can transfer to a tree control without having to introduce artificial intermediate levels.

Unlike screen elements, controls only have to be created and filled with data once.  From a performance point of view, this means that they become more profitable the longer they exist.  In applications that are called repeatedly, and therefore initialized repeatedly, controls can have a negative effect on performance. In applications that use the same screen for a long time, on the other hand, you may find that using controls results in improved performance. 

You can always use the performance tools to check the advantages and disadvantages in terms of network load that using a control brings.