Skip to Content

It feels a little early to be talking about Personas idioms, but in my experimentation so far and in talks with users it seems there are some things we will end up doing a lot. I suspect others will find the same so it seemed worthwhile to create a document describing these things. I’m allowing anyone to edit this document so please feel free to add any idioms you discover so that we can all learn from each other.

Home screen techniques

Rather than simplifying individual transactions, the Personas work I’ve seen so far, and certainly what I’ve been doing, starts one step back by modifying the initial SAP home screen. Typically you remove most of the standard SAP stuff and turn that screen into a “cockpit” giving easy access to useful transactions, information and other things, to save users having to remember transaction codes or menu paths. Listed here are some useful things that can be done directly from this home screen. Here’s an example of our first (incomplete) prototype, mostly using the two techniques described below to give users quick access to the information they need.


Transaction-free lookup

I’ve come across a number of situations where a user has a transaction number (e.g. a PO number or service order number) or some master data (e.g. a cost centre or a userid) and they want to simply check that it is what they think it is. They want to lookup the description or the user’s full name. You can obviously run the corresponding display transaction for that, but if all you want is to check one field there is an easier way. Put a text field on the logon screen, a corresponding “Lookup” button and second text field for the result. The lookup button has a script that runs the transaction, grabs the necessary data and displays it back on the logon screen. The “Purchase Order” section above works like this:

For some added finesse, you can link the input text field and the lookup button, so that typing in a username and pressing enter also pushed the button. Then the lookup button doesn’t even need to be on the screen, so you can hide it as I have above.

Skipping selection screens

Following on from the above, if you need to display more information than you can reasonably pull back onto the logon screen then you are going to have to run the display transaction after all. But if the identifier (username, transaction number, etc.) for the object you are wanting to display is already in a text field on the screen you can grab it, skip the display transaction’s usual selection screen, and go straight to displaying the relevant information.

If you do this, don’t forget that the back button will now not go back to where you came from but back to the selection screen. You might want to replace it with a script button that goes back twice, so the user doesn’t see the skipped selection screen.

Scripting Techniques

Below are some general purpose tips and tricks applicable in many contexts.

Dealing with variable screen flow

Sometimes a transaction varies its screenflow depending on entered data, or other things. ME2J, for example, uses a separate pop-up window to ask for a “database profile” the first time you run it but then remembers the answer for subsequent invocations until you logout. Dealing with this in a script requires that the script can tell if the pop-up window is present or not. One way to do this is to use an IF to check if the label for the field in question is not empty, like this:


Thanks to Vandana Deep and Tobias Queck for this one!

Nested If

You may have noticed that the script editor does not allow you to have nested IF statements in a script. You might need to do this if, for example, you have a script that has to deal with variable screen flow, as above, but you also only want the script to run if a screen field is not empty. As far as I know there’s no way to do this in a single script, currently. You can achieve it through the use of multiple buttons. Build button one holding the main script – everything but the outer IF looking for an empty field. Then add a second button with a script like this:


Finally, hide button one since you don’t want users pushing it!

Thanks to Tobias Queck for this trick.

Keep it simple.

It can be extremely difficult to do things in a single script. Break your scripts in smaller chunks and proceed. Break IF condition is chunks. First handle the negative condition and then proceed with others, each on a separate PUSH. Here is a small example.


Avoid bulk data processing

If you are processing bulk data, then keep a stricter SELECTION criteria. I noticed that while using ME2L, with a larger date range the browser (IE 8.0) took forever to load, especially customized flavor. The lesson for me was to provide more and more criterias to restrict the final number of rows.

Don’t forget Refresh Screen

The magic command in Personas Scripting. It can really save you some work, especially if you are confused and trying to understand why your COPY command did not work or IF statement did not work. Use it religiously

Handling Checkboxes

Although this problem is version specific, I still thought to provide it. It might come handy and if there is a better way, hopefully someone will correct me and share a better option.


Handling Messages

Several times, we come across situation where the actual task becomes complex due to several messages either pop-up or displayed on the status bar. Worst, in Personas we can not determine message type, so in most cases, we have to read status bar and convert the message into a more straight one and present it to user or just proceed further. Here is a small scenario for handling the status bar message.


To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Will Conlon

    Thanks Steve. I’ve been toying with very similar techniques. I am eager to tackle the business issues. After doing some timings for our SAPGUI users I think the results will be outstanding. Appreciate your sanity checks! 😉


Leave a Reply