Skip to Content

Creating bullet-proof Personas scripts

Personas is great for creating a streamlined user experience, simplifying transactions and automating some or all of a process. When working with Personas scripting, though, you need to remember that ultimately you are driving a standard SAPgui transaction with the script and you need to be prepared to deal with things going wrong. For example, in my blog Transaction-free lookup with Personas I describe a technique for looking up a functional location description given just the location code, but doing that directly from the SAP start screen without having to directly run the transaction IL03. The script in that blog, though, does no error checking. If you try and look up a functional location that doesn’t exist, the script will fail and leave the user looking at an unfamiliar screen and an error message. That’s not in-keeping with the aim of improving the user experience!


Here is the same concept implemented for cost centres. The first lookup in this video succeeds and displays the description as expected. The second tries to lookup a non-existent cost centre. Here, KS03 will issue an error message and remain on the selection screen. The script detects this and displays an error message back on the start screen rather than failing in an unexpected (to the user) place.



How you go about this in a Personas script depends very much on the nature of the underlying transaction. For this cost centre example I use a trick described by Vandana Deep in this discussion: How do you deal with variable screen flow in a Personas script?, namely checking for the existence of labels to determine which screen you are looking at. Here’s the script





So far, so straightforward. The first two steps clear some fields on the start screen – the description and the error fields. Clearing the description field will be important later. Then run transaction KS03, paste in the cost centre copied from the start screen and press <ENTER>. Then the usual “Refresh Screen” action you need before examining the new screen contents.


Next we check for the existence of a label that will only exist if we’re displaying an actual cost centre. If found, copy the values we want and go back and paste them on the start screen. If not, issue an error message.





There are a couple of problems here. though. First, while you can use “IF is not empty” on a label to see if the expected screen is being displayed, you don’t seem to be able to use “IF is empty” to see if it is not. At least, that doesn’t work for me. Instead, here I check the description field. Remember that we cleared it right at the start? If it is still empty now then we must have not found a valid cost centre and that’s my trigger to issue the error message.


The other problem I have more generally with trying to build error-proof scripts is that Personas scripting does not (yet?) support nested IFs. One thing I generally do with all scripts like this is simply not do anything at all if the cost centre field, in this instance, is empty. There’s no point in looking up nothing. But if I do that, I currently can’t have any other error checking. This is another case where calling WebRFCs is useful – you can build much more robust ABAP functions than you can Personas scripts. You can find details of how to do that here: Calling RFCs from a Personas script.


Described above, then, are some techniques you can use to make your Personas scripts more error-proof and so improve the user experience not just when things are going right, but when they go wrong also.

You must be Logged on to comment or reply to a post.
  • Silly question probably but how do you get the statements after the IF indented?  I have created the IF statement at the top of my script after the original script was put in place but I can't see how to indent the subsequent statements

    • In the script editor select each statement you want in the "body" of the if and move it up with the arrow button just above step 1. Not obvious, I know. I had to ask... 🙂


        • Yeah, that doesn't have such an easy answer. That basically means your script is trying to manipulate a screen object that doesn't exist, which probably means you're not looking at the screen you think you are. Personas script debugging isn't easy sometimes!

          Peter mentioned the idea of building up the script in stages on separate buttons. I use that technique often. When a script is only a handful of steps long it is painless to delete and start again, which is often the easiest way to deal with this sort of thing! Also, if you have a script that is trying to navigate to a transaction and do stuff when it gets there, build the navigation part first and put it on the source screen. Build the rest on a new button on the target screen and when it is working, then export and append to the first button. Or simply have the first script do the navigation and then press the second button when it gets there. Again, developing in small pieces is easier to manage.

          I feel a script debugging blog coming on...

    • I have played with them a little to see how they work and what they're capable of, but I haven't found a use for them yet in the scenario I'm currently developing.

      Did you have a question about them?