Using Controls in a WAN
Use
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. 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 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.
If the queue has no return codes, and it has to be synchronized, the Control Framework method CL_GUI_CFW=>UPDATE_VIEW can be used. Only use this method if the GUI absolutely has to be updated. This could be the case in long-running applications where the user needs to be given 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.