Skip to Content
Technical Articles
Author's profile photo Martins Buka

Implementing tab merging with SAP Screen Personas Profiler

What is the Profiler?

The Profiler is a diagnostics tool that is released with the SAP Screen Personas Service Pack 14. It captures all user and script interactions with classic SAP GUI transactions rendered in Slipstream Engine and displays underlying activities which take place in response to the given interaction. The Profiler can be used to measure the performance of the Slipstream engine for any given user interaction as well as to identify and debug scripting and tab merge errors.

The Profiler shows how end-user and script actions, e.g., script button press, are translated to further activities and requests that are submitted to the ABAP backend system. That enables flavor designers to identify potential issues with the solution performance or domain logic. This is particularly useful when SAP Screen Personas is used to automate manual user actions via scripting or in tab merge scenarios. In this article, I will show how the Profiler can be used as an aid to help you implement tab merging.

Example Scenario

As an example, I will use a flavor created for Create Purchase Order DYNPRO transaction (ME21N). The flavor contains the following changes applied to the original screen of ME21N:

  1. All controls are hidden, except the Header tab strip, the Vendor input field and its label.
  2. Two custom group boxes are created and placed in the user area: Delivery/Invoice and Org. Data.
  3. All tabs from the Headers tab strip are hidden, except Delivery/Invoice, Communication and Org. Data.
  4. The Exchange Rate label and the corresponding input field are moved from the Delivery/Invoice tab to the Delivery/Invoice group box.
  5. The Purch. Group label and its input field are moved from the Org. Data tab to Org. Data group box.


Figure 1. Customized screen in transaction ME21N

Understanding How the Tab Merging Works

To better understand how the tab merging works, let’s look at what happens behind the scenes when a user performs an action on off-screen controls (controls that are moved to the user area from currently inactive tabs).

To demonstrate this, we need to do the following:

  1. Open the Profiler and start recording

    Figure 2. Opening the Profiler and starting recording.

  2. Fill two off-screen (Exchange Rate and Purch. Group) and one on-screen (Vendor) input field with valid values (Figure 3). And press ENTER key.


    Figure 3: Filling valid values for off-screen controls

  3. Finally, switch to the Profiler to explore the recorded activities.

Exploring Captured Activities

By looking at the Process submit actions activity details we can see which manual user actions were processed by the SAP Screen Personas client.


Figure 4: Process submit actions activity details view

Figure 4 shows that there was a single submit action (ENTER key press) that triggered synchronization with the back-end and three subsequent set value actions for three different input fields (Exchange Rate, Purch. Group, and Vendor).

User Action on an Off-screen Control

As there are the two actions for off-screen controls Set value for “Exchange Rate” and Set value for “Purch. Group”, the SAP Screen Personas client adds additional actions to the batch to activate the screen state which contains the target off-screen control. These additions are visible in the Activate actions activity details view.


Figure 5: Activate actions activity details view

Figure 5 shows that three tab select actions were added to the batch.

  1. Select “Delivery/Invoice” tab action is added before set value action for Exchange Rate input field because this field in the back-end is only accessible when the tab is selected.
  2. Select “Org. Data” tab action is added before the set value action for Purch. Group input field for the same reason.
  3. Select “Communication” tab action is added to get back to the originally selected tab in the client.

As you can see the SAP Screen Personas client manages tab selections to facilitate actions on off-screen controls.

By looking at Submit actions details view under Process submit actions activity we can see that the activated batch is sent to the back-end (Figure 6).


Figure 6: Submit actions activity details view for activated actions

Collecting Off-screen Controls

After the user actions are submitted to the back-end, the Personas client tries to collect off-screen control states from the back-end. Information about the collected controls and the collection state is visible in the Collect off-screen controls activity details view (Figure 7).


Figure 7: Collecting off-screen controls

Submit actions activity details under Collect off-screen controls activity displays a list of actions that are sent to the back-end to fetch off-screen control states (Figure 8).


Figure 8: Submit actions details view for off-screen control collection

After the off-screen control states are collected from the back-end, the Merge off-screen controls activity is executed to merge retrieved control states into the screen state (Figure 8).

Debugging Tab Merge Error

To demonstrate the tab merge error situation, I will do the following:

  • Change Exchange Rate input field value to 999.
  • Change Purch. Group input field value to 003.
  • Press ENTER.


Figure 9: Screen state after merge error

Figure 9 shows that after the refresh, Purch. Group input field value was not changed and there is no information on the screen that would identify the reason for rejection.

Let’s look at the Profiler output and see if there is anything that can be used to resolve the merge error situation.


Figure 10: Failed submit actions

By looking at Submit actions activity details under Process submit actions activity it is visible that two actions (Select “Org. Data” tab and Set value for “Purch. Group” input field) have failed (Figure 10). It becomes clear that the value set for the off-screen input field Purch. Group failed because the previous attempt of the tab select was not successful. To see more details, we need to expand the first failed action (Figure 11).


Figure 11: Failed action details

By looking at Select “Org. Data” tab action details it is visible that the action failed because of the warning message in the back-end status bar “W: Exchange rate 999 differs…” (see figure 11 Reason for failure property). This warning blocked the first tab select but it was erased by the next flushing action (Fire “ENTER” key). To confirm this, you can execute all actions listed in Submit actions details view manually.

And, here we go, we have found the actual reason behind the tab merge scenario.

Handling the Tab Merge Error

The simplest solution for this tab merge error situation is to make sure that the warning message is displayed to the user. We can achieve this by employing two lifecycle events in SAP Screen Personas: onStatusMessage and onFinalize.

For onStatusMessage event we can create a script that captures the status bar messages in tab merge error situations and saves them to the session store. The following script should do the trick:

for (let i = 0; i < messages.length; i++) {
    var msgText = messages.elementAt(i).message;
    var msgType;
    // Extract message type from the message.
    if (msgText[1] === ':') {
        msgType = msgText[0];
        msgText = msgText.substring(2);
    session.utils.put('status-msg-text', msgText);
    session.utils.put('status-msg-type', msgType);

For onFinalize event we can create a script that displays captured status bar messages in the status bar:

// onFinalize
// Get status message text and type form session store.
var msgText = session.utils.get('status-msg-text');
var msgType = session.utils.get('status-msg-type');
if (msgText) {
    // Clear session store.
    session.utils.put('status-msg-text', '')
    session.utils.put('status-msg-type', '')
    // Set status bar message.
    session.findById("wnd[0]/sbar").setMessage(msgText, msgType);    

Now let’s reenter the invalid data and see the result.


Figure 12: Merge error handled

Figure 12 shows that an appropriate warning message is displayed for the user.


The Profiler can be a very helpful tool when implementing tab merging changes. It helps flavor designers to better understand how the tab merging works under the hood as well as provides additional diagnostic information like status bar messages that would be lost otherwise. It also provides a list of user actions that could be performed manually on the original screen to repeat the merge error scenario. That can be helpful when analyzing the business logic of the underlying DYNPRO application as well as implementing an efficient merge error handling solution for the given transaction and requirements.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Damean-BF Chen
      Damean-BF Chen

      Thanks for the detail documentation ...The Profiler is sure a wonderful feature that we would probably used a lot in the future for troubleshooting.

      Question ... How do SAP envision using the "Profile" in the Production Environment or is it more for QA instances?

      One of constant issue we have is supporting remote users running the Slipstream flavor on a tablet\smartphone.  It will be great if there's somehow a mechanism\procedure via which user could trigger this Profiler tool themselves; then the only thing the support team have to do is just review the recordings.  This would cut down lots of wasted to & fro time; where IT support team need to remote in to user devices to see the error

      Peter Spielvogel

      Author's profile photo Krists Magons
      Krists Magons

      Good day!

      The primary purpose of the Slipstream Engine Profiler tool is to help flavor designers:

      • to write more efficient scripts by enabling them to evaluate performance impact of their coding
      • to deal with tab-merging problems
      • to debug scripting issues

      As of now, the profiler is not suitable to be used on mobile devices with relatively small screens, however, the flavor designers can still use it in desktop environments along with mobile emulators to develop and test mobile flavors

      Therefore, the Profiler is only enabled for the designers (having the standard /PERSONAS/EDITOR_ROLE role or P_RUNTIME 04 authorization object ) in desktop browsers, hence, development and test systems are the most typical environments for Profiler use-cases.

      Thank you!

      Best regards,
      Krists Magons
      SAP Screen Personas, Lead Architect