SAP Cheat Sheet for Performance Testers

Performance testers must switch between different technology platforms almost every time they join a new project. Here are a few things you should know so you don’t look like a complete n00b on your first SAP project.

Transactions and Sessions

Unless a restriction has been put in place, users may create multiple sessions from a single workstation. Using the menu, this can be done through System > Create Session or by left-clicking on the top right of the SAP client window and selecting the Create Session option.

This menu is also the only place a transaction may be stopped if a dialog step is taking a long time to complete. Ending a transaction that has stopped responding by using Windows Task Manager to kill your SAP client is a bad solution, and I have seen it leave zombie processes running in the system.

Most of your navigation probably won’t be done using the menu tree, but by entering a transaction code in the command field.

In the above screenshot I am jumping directly to the Data Browser, which has a transaction code of SE16. There are several other things we can do in the command field:

• /x is a shortcut for exiting the system
• A new session can be opened with /o[Transaction Code]. E.g. “/oSE16” would open another session and start the Data Browser
• If you are already in a transaction and want to jump to another, you would use /n[TransactionCode]

Be aware of where you invoke a transaction in your LoadRunner script. If you are restarting a transaction every time you iterate through the Action section of your script, you may be creating an unrealistic usage pattern (unless your users really will restart the transaction every time they use it).

Extracting Data

If you need to automate anything within SAP, like small-scale data loads or data extractions through the GUI, it is easier to use QuickTest Pro (if you are licensed) rather than CATT/eCATT scripts, which are a big pain in the butt.

Regular cut and paste does not work for all of the SAPGUI widgets. Where this is the case, you will have to use Ctl-y to select text before you can copy the text to the clipboard.

If a data grid does not have an export button to allow you to export data to a local file in Excel format, you have another option. Choose System > List > Save > Local File, and choose your preferred file format.

If you have access to the Data Browser (SE16), you can extract data from the database tables directly. Because SAP want their software to be independent of the underlying database, they discourage the use of SQL, so you must query the table using their forms.

Extracting data from tables rapidly becomes painful if your data spans multiple tables, because you can’t do a join. The (hacky) solution to this is to either extract both tables to Excel and join there (small data sets only), or right click in the field in the second table that is the key and choose multiple selection from the context menu. This will allow you to run a query on the table to match all the records that have your key value.

Finding the correct database table can be tricky as most tables and fields have cryptic names (very short German abbreviations). The field and table behind an edit field in your application can be found by placing the cursor in the edit field and pressing F1 (help).

Click on the icon with Technical Information icon (with the hammer and spanner), and the technical details behind the field will be displayed.

If you are lucky, you will be given a table and field name, otherwise you will be given a Struct. This is a data structure in the ABAP code that may have pulled data from multiple tables (or wherever). You will also be able to see the field in the struct and the underlying field (data element) in the database. Double click on the data element and you will be taken to a data dictionary view. Press the Where-Used List button to see a list of all the tables that have this field. Double click on the field name under the correct table and you will be taken to the data dictionary view of the table. Confirm you have the correct table and then jump back to SE16 to construct your query.

End-user Performance

I’ve talked about this before, but I think that the transaction timer in the SAP client is quite a neat feature.

It measures how long each dialog step takes, so if you press a button and you have wait for a response from the server, the timer will run until the response is received. Note that if multiple dialog steps are executed when you press the button, the timer will measure each individually (causing the timer value to update with a new value for each dialog step), and you will finish with only the last value.

Note from the screenshot, you can also see the transaction code for the current transaction in this menu.

LoadRunner Scripting

SAPGUI is one of the easiest vuser types you will ever use. Read all the LoadRunner documentation and you shouldn’t have many problems. Be aware that you can only run a limited number of virtual users on each generator due to GDI resource limitations. The work-around for this is to open up multiple Terminal Services sessions, each of which has its own allocation of GDI objects. You may need to run fewer virtual users in each TSC session if your application is graphically rich.

Further Reading

• Make sure to read enough that you will understand the SAP architecture for your project, also any tuning guides are useful
• Read the relevant sections in the LoadRunner manual
• Search the Mercury Support Knowledge Base for SAP-related tips and tricks. Read Problem ID: 11907 – How-to and troubleshooting guide for SAP Vuser
• Read the slides from my Mercury World Australia presentation on Mercury Diagnostics for SAP
• Finally, I plan to make a list of SAP transaction codes that are useful to performance testers, so check back soon