Skip to end of metadata
Go to start of metadata

SAP Screen Personas

Scripting Approaches to Solve Issues in Tab-Merged Screens

SAP SCREEN PERSONAS KNOWLEDGE BASE - by Clemens Gantert , Regina Sheynblat , Bulcsu Szasz , Sebastian Steinhauer


This article addresses typical problems that may arise when a screen contains tab-merged controls. It shows scripting strategies to resolve these problems.


Tab-merged screens often cause problems during runtime. This article provides strategies and sample scripts to resolve the following common tab-merging scenarios:

  1. Controls taken from a sub-screen that is not always visible, e.g. a collapsible container that is not always open.
  2. Controls taken from a tab that sometimes shows a popup that prevents tab-merged screens from rendering properly
  3. Controls with input validation that if validation fails prevents the tab-merged screen from rendering properly.

Tab-Merged and Proxy Controls

Tab-Merged controls are controls that are moved out of their original tab. Typically they are moved to a different tab of the same tab strip or the user area, but in principle they can be moved anywhere, in special cases into a tab of a different tab strip.

In this article, the term “proxy control” is used for controls that are moved from their original container to another location on the screen and the original container of the control isn't a tab, nor are any of its surrounding containers tabs. For instance, moving a field from a group box to the user area turns it into a proxy control.

There are two key rules that must be met for the system to be able to render screens with proxy and tab-merged controls:

  1. For all proxy controls the original container from which they were moved must be "present in the current screen state". "Present in the current screen state" means when you switch from your current flavor to the "Original Screen", then the control that was turned into a proxy must be visible.
  2. For tap-merged controls, the system must be able to activate every tab from where tab-merged controls were taken. So, if you switch from your current flavor to the "Original Screen". you must be able to select every used tab manually and then go back to tab from where you started without having to manually close popups or correct failed field validations.

Scenario 1: Proxy Controls taken from Collapsible Container

The Create Purchase Order transaction ME21N provides a real-life example of "collapsible containers". By the way, there is no control type "collapsible container", it is just a name for a design pattern where part of the screen (a subscreen) is not always visible, but can be toggled between a visible and an invisible state by typically a button, in rare cases by a menu item.

Below is a screen shot of ME21N with the Header, Item Overview, and Item collapsible containers closed.

ME21 with the header collapsible container opened (Note the tab strip in the header container):

ME21N with a flavor applied. The flavor moved some fields from the Delivery/Invoice tab and from the Org. Data tab to the user area. Header container toggle button as well as the entire sub-screen container are hidden.

The goal is to have a script that ensures that the container is open at all times. Here are a few tips for creating such a script:

  1. The script typically consists of a test of whether or not the container is visible or not and if the container is not visible, then the script performs an action to open the container.
  2. You can use method session.idExists() to test if a container is open. The idea is that if a control that resides inside the container "exists", then this means that the whole container is open. Make sure to test for a control that always exists if the container is open. In the ME21N example, I am using the tab strip inside of the header container to test if the header container is open, as opposed to for instance a field within any of its tabs, which may not be the selected tab even though the container is open.
  3. onLoad and onAfterRefresh are good event handlers to attach the script to because proxy processing is executed after the onLoad and onAfterRefresh script have finished. In many cases you can just use your script as onLoad script. Some applications including ME21N, however, open and close containers dynamically for instance whenver client window is resized or when a new item is added. Therefore it is necessary to attach the script to the onAfterRefresh event.

onAfterRefresh script to open header container

// does the tab strip in the header container exist?



    // if not, press the header button to open the container




Scenario 2: Screen not rendered properly because Proxy Processing stopped by popup screen

Popups stop tab merging because as long a popup is open the underlying tab cannot be changed which is necessary to render the screen.

From a tab merging perspective, the question is if only a user can provide the data or input to close the popup or can a script produce this data automatically and close the popup instead of the user.

Let's try to answer this question for some typical popup types:

  1. F4 input helps - You want the user to enter search criteria and select a value. This cannot be closed automatically via a script.
  2. An application collects key information for a new object or item in a popup before the respective object or item is created. Depends on the data collected. Most likely, this popup cannot be closed by a script because at least some data has to be provided by the user.
  3. Error, warning and information popups, for instance due to input validation. In many cases, theses can be closed by a script and the information in the popup can be shown in a status bar message instead.

The scenarios where the popup that can be closed automatically can be solved by use of onMergeError event handler script. See Scenario 3 for more information on this event.

For the scenarios where displaying the popup is necessary, for instance an F4 help popup, we want to point out that specifically the SAP GUI for HTML shows some quirks.

Below is a screenshot of the Change Equipemnt transaction IE02 with a tab merged flavor applied. It shows only one tab. The highlighted Location field is originally from a a hidden Address tab.

Below is the same transaction and flavor after opening the Location field's F4 help. Note that beneath the F4 help window, the previously hidden Adress tab has become visible and the Location field has moved to its original position. The SAP Gui for Windows and Java may display this scenario correctly, but the SAP GUI for HTML does not. Unfortunately, there is no workaround and the ITS kernel team currently has no technical way to fix this in a higher release.

Fortunately, after selecting a value from the F4 help, tab merging resumes normally and the flavor is rendered correctly again:

Scenario 3: Screen not rendered properly because Proxy Processing stopped by failed input validation

Failing input validation is another common cause for proxy processing to fail. When an invalid value is entered into an input field – in most cases this is a field with an input/F4 help – then the application notifies the user and asks to correct it. Some applications show an error message in a message container, but allow a user to change tabs and continue editing data and only require all entries to be valid before the corresponding business object can be saved (e.g. User Maintenance transaction SU01).

However, most transactions show an error message in the status bar at the bottom of the screen or a popup. In case of a popup, the user must close the popup but the application is still in an error state which means many or all other fields may be blocked from entering data into them, but most importantly, the application won't let the user open any other tab until the wrong entry is corrected. Examples transactions for this type of input validation are: VA01/02, ME21N, IE01/02 and many others. The latter type of transactions cause problems when an input field that can cause such an input validation error is used in a tab merging. Let's take a look at the two case because the occuring "symptoms" are quite different:

Case 1: Fields merged outside of tab strip: The field is moved from its tab outside of its tab strip, for instance to the user area. In this case, if an input validation fails, subsequent fields that are taken from other tabs are not shown. The KB article TabMerging and blocking input validation illustrates this case along the example of the Sales Order transaction VA01. It also provides an approach on how to solve this problem without scripting. Alternativley the scripting approach using the onMergeError event which is described below can be employed.

Case 2: Fields from many tabs are consolidated into fewer tabs: The field is moved from its tab to a different tab of the same tab strip and then its original tab is hidden. If the input fails, the hidden tab from which the field was taken becomes visible. In the SAP Gui for HTML on kernel releases lower than 7.49 a user was completely stuck in these situations because the system wouldn't let you switch to a different tab before the field value was corrected, but the user couldn't change the field value because the field was not visible because it was moved from the original tab which is currently active and only visible in a tab tab that couldn't be selected. Fortunately, in kernel releases 7.49 and higher this was solved and user has the ability to see the original tab with all its original fields so that he can correct the wrong entry and tab merging resumes.

Let's take a close look of the latter case, through the use of the Equipment Maintenance transaction IE02.

Below is a screenshot of the IE02, no flavor applied.

If a wrong location is entered, then an error message is shown in the status bar at the bottom of the screen, most of the other fields on the screen become read-only, and it becomes impossible to switch to a different tab (see screenshot below).

Below is a screenshot of IE02 with a flavor applied. This flavor moved some fields from the Location tab were moved to the General tab and all tabs except for the General tab were hidden.

If you now enter a wrong value, the proxy processing is interrupted and the screen is displayed with only some flavor changes applied. The previously hidden Location tab is visible and active and it shows the field that were moved to the General tab (see screenshot below). The user can correct the wrong data after which the flavor is displayed correctly again. However, this is not ideal, because it can be very confusing for user when the UI changes so dramatically because of an input error.

Resolution with GuiTabStrip.onMergeError script

This problem can be overcome by using onMergeError script. The event GuiTabStrip.onMergeError was introduced in the SAP GUI for Html with kernel 7.49. The associated event handler is called when a problem situation occurred during the processing of a tab-merged screen. Typically, the tab merging processing is "stuck" on a specific tab and normally cannot continue without user intervention. The event handler script can resolve the problem without user intervention. The handler script gets to parameters:

                source    the tabstrip to which the handler script is attached

                tab           the tab in which tab merging processing is stuck.

onMergeError script checking for input validation errors

 var sMsg = session.findById("wnd[0]/sbar").text;

session.findById("wnd[0]/usr/tabsTABSTRIP/tabpT\\02/ssubSUB_DATA:SAPLITO0:0102/subSUB_0102A:SAPLITO0:1050/ctxtITOB-STORT").text = '';

session.utils.alert("User validation error: "+sMsg);

Note: In an earlier version of this article it was mentioned that the error message could be displayed in the status bar using the following script:

session.findById("wnd[0]/sbar").setMessage(sMsg, "E");

Unfortunately, this is not working with current kernel releases. Therefore, we now recommend the usage of session.utils.alert().

If you enter a wrong field value the result can be shown in below screen shot. The same error message is shown in the status bar, but the field is cleared now.

Use at Your Own Risk!

Wouldn't it be nice if we could show the wrong data in the input field? There is a way by writing the value directly into the UI control after the screen is rendered.

 This will only work in the SAP Gui for HTML. The script below directly manipulates an input control through the internal Unified Rendering (UR) library (aka Lightspeed ) and this manipulation is attached to an internal UR life cycle event. This approach could cause unforeseen and hard-to-detect side effects with the client (in current and future releases of the kernel).

onAfterRefresh script writing the wrongly entered data back into the field

// display field error

if (session.utils.get("fieldError")){

    var oError = JSON.parse(session.utils.get("fieldError"));

    session.utils.put("fieldError", null);

    session.findById("wnd[0]/sbar").setMessage(oError.errorMsg, "E");


    var oLS = sap.its.rootLS; // lightspeed instance might also be available at global its._ucf_ls


    var oHandler ={

            openAfterUpdate: function() {

                  oLS.detachUpdateComplete(oHandler, "openAfterUpdate");

                  var oControl = oLS.oGetControlByCustomData("SID", oError.systemFocus);





    oLS.attachUpdateComplete(oHandler, "openAfterUpdate");


With the above altered onAfterRefesh script the error message is displayed and the input field shows the wrong value.

Related Content

Related Search Terms:

SAP Screen Personas, Tab Merging, Proxy Processing, onMergeError

Related SAP Notes/KBAs

TabMerging and blocking input validation