Skip to Content

Simplifying a multi-screen transaction with Personas

Most of my previous Personas blogs have looked at techniques for building a launchpad for users, so that they can do everything they need from the main SAP start screen without ever running, or at least being aware of running, any SAP transactions. Once the launchpad is built, though, you do need to look at the transactions it, well, launches.


Many transactions will just need fields hiding or moving around into a more logical order. Some require more work. One of the most complex transactions used by our users and the one with the largest ratio of content displayed to content required is IW33. It is complex for several reasons. First there’s content spread across 10 tabs and some of those tabs contain more tabs, and despite all those tabs you still need to scroll the main “header” tab to see everything on it. Worse, there’s information that isn’t on any of those tabs and you have to delve into menus or even other transactions to see it. In particular, my users need to see the settlement receiver (from the Goto->Settlement rule menu) and the long text description of the fault from the corresponding notification (accessible via a button on the Header tab). So when a user looks at a notification, to get all of the information they need usage looks like this:



A little rearrangement of the transaction content, plus a simple (for a change!) script produces a Personas version that works like this:


Screen Shot 2013-12-09 at 10.34.40.png


Yes, that’s an image not a video. Everything our users need is on that one screen. Content from multiple tabs is merged into a single screen and a script fetches the settlement receiver and the notification long text and puts them in added custom fields. How much easier is that!


The script to fetch these values is pretty straightforward. Steps 1-5 go to the settlement rule via the menu, copy the settlement receiver and paste it back on the IW33 main screen. Step 6 selects the “Header” tab where the notification display button is. Steps 7-10 display the notification, grab the long text and come back again. Step 12 grabs the short text from the service order which is merged with the long text using a little Javascript in step 13 before pasting it on the main screen in step 14.

Screen Shot 2013-12-09 at 10.36.47.png

Screen Shot 2013-12-09 at 10.37.21.png

Screen Shot 2013-12-09 at 10.38.01.png

Screen Shot 2013-12-09 at 10.38.35.png

One interesting thing about how I use this script is how it is invoked. Of course it is attached to a script button, but asking the user to push a button to go and grab this extra data, while easier than doing it the standard way, isn’t very friendly. Instead the script button is attached to the screen so that whenever the screen is rendered the script is invoked afterwards. To do this, first select the script button and grab its ID from its properties. Then select the UserArea component and look at its properties. Down towards the bottom is a property called OnCreateHandler. Paste the script button ID there, like this:

Screen Shot 2013-12-09 at 10.39.18.png


Now, whenever the IW33 screen is rendered with this flavor, the script on the button will be invoked. Be careful what you do with such a script, though. If you aren’t careful you can produce a flavor you can’t edit, if it always fails while on a different screen from the script button! I suggest only adding the OnCreateHandler property right at the end, once you’re sure the script works correctly. During development, stick to manually pressing the button to test it.


Oh, and once everything is working correctly and the OnCreateHandler property is set, you can hide the script button. The user doesn’t need to see it.


You must be Logged on to comment or reply to a post.
  • Hi Steve,

    This is excellent, as it gives me the best indication of what it takes to enable complex scenarios with Personas (I personally have never touched it).  In particular, it demonstrates to me that the skillset required for these complex scenarios does require some technical competency, which is a little add odds to the marketing.  See link here

    … where on slide 9 it says …

    “Reduce the cost of personalisation by eliminating the need for ABAP programmers or scripting experts”

    And to me, the point is that it is the complex scenarios that you would want to most likely target, because that is where you would derive the most benefit.

    Separately, have you traced the network traffic between the client and the server for this type of use case?  I’m wondering how that compares to use of the traditional GUI screen.

    Thanks again for a great blog.



    • I’ve made no secret of the fact that I think Personas without programming is a waste of potential. Most of my blogs are about scripting techniques and I’ve also blogged about calling WebRFC functions from scripts, and even writing ABAP transactions specifically to be called from scripts.

      I think you’ll see the marketing message changing in the near future.

      That said, the scripting involved in this particular scenario really is pretty simple and I’m sure non-programmers would be able to manage it with no problems. It took me no more than 5 minutes to record, edit and test the script. The OnCreateHandler trick is just that – a trick. Once you know it, there’s nothing clever about it.

    • I haven’t done a network trace. Here’s what I would expect, though. The Personas client sends the equivalent of a BDC session to the ERP server – a batch of GUI interactions to be executed together. Those are played on the server with no traffic to the client until the script is complete. If you are going to grab data from the screens you visit in the script, as I do in the service order simplification above, you need to break the execution of the script into several pieces – that’s what the “RefreshScreen” action is. Still, with the script above there are much fewer interactions between client and server than in the manual example in the video. That should result in less network traffic overall. The traffic pattern will be different, though. Rendering that one Personas screen for IW33 will result in a more intensive burst of network traffic than the SAPgui equivalent screen.

      But that’s only half the story. For any given transaction I’d expect lower overall network traffic, but one of the points of all this is to make people more productive. Scripting interactions makes them happen more quickly, which means people can get more done. If the Personas screen above takes, say, 10 seconds to render compared to the 50 or to to navigate manually around the original IW33 transaction, in theory a user can do 5 times more. That doesn’t make a lot of sense for a display transaction, but if this was IW31 you’d expect such a simplification to mean a user could create more service orders in a given time. Each one might result in less network traffic, but overall you’d expect traffic to increase.

  • Steve,

    A question that occurs to me.  You have modelled a display scenario here.  What are your thoughts on the complexities of an update scenario, where you have potential for pop-up warnings or other things depending upon your data entered.  Do you see complexities for scripting those scenarios?  ie.  Do you need to fork the scripting for all the different branches that the (underlying) UI might take?



    • I haven’t done much yet with update transactions. My expectation is that such things will get quite complicated if you want to try and hide the usual unfriendly standard SAP error messages. Even in the display context, dealing with errors – asking to display a purchase order that doesn’t exist, for example – can sometimes stretch Personas scripting. Different transactions report errors in different ways – popup boxes, changes in screen flow, status bar messages. Some are easy to deal with, some less so.

      You can detect variable screen flow and act accordingly, but Personas scripting is not currently sophisticated enough to make this easy. A simple example – there is an “if” statement in Personas scripting but they can’t be nested. There are workarounds for that, but things gets tricky quite quickly.

      To relate this to your comment above, error detection and handling is, in my experience, the area where most “proper” programming effort is required when building Personas flavours. Basic automation is pretty straightforward. Bulletproofing it isn’t. There’s a discussion of such issues in this blog – Creating bullet-proof Personas scripts.

      • Hi Steve

        We have been building a flavor for MM02 – Change Material Master – and regarding your point about dealing with error messages – this has proven to be a sticky situation. Even with warning messages that you tend to just press enter for in the standard Basic View will cause the scripting to break – after all it’s a ‘BDC’, so it can’t cope with anything that you haven’t built into the script.  I am reliably informed that there will be a fix for this situation though, so will report back if/when this occurs.



        • There is usually a way to detect these pop-ups. The first this to try is an IS “is not empty” on the text of the message, or on a label somewhere in the pop-up. If true, take appropriate action. If the message is in the status bar, check that instead. I have found one pop-up I couldn’t figure out a way to detect, though. I had to use a different transaction to avoid it, in the end.

          My experience is that error detection is much more than half the work of building something like this in Personas. The initial automation script will typically take just minutes to build but making it robust enough can take days.

  • Hi Steve,

    fully agree to John’s statement that this example provides an excellent what can be done leveraging the full power of SAP Screen Personas. In my pov to get most of Personas you need to combine two skill sets:

    – a UX skill set to be able to understand the end-user needs and come up with a good and intuitive design of the new screen

    – a technical skill set to make full use of features like scripting – it’s also helpful to understand how Personas technically works and where the limitations are

    We recently see more case where customers seem to forget the UX aspect of a Personas implementaion…


    • Hi Jogu,

      The official configuration guides as well as documentation is available on SAP Service Marketplace for every customer that has access to SAP Screen Personas. Other then that, you can find How-tos and discussions on Personas here on SCN.


  • Hi Steve,

    I can see the video, but the static images seem to have lost their links, I can’t see them.

    Shame, because I really wanted to see what you managed 🙁

    As you know, I’m looking at PR05 and the main problem with that is that it’s an access point to a series of ‘transactions’ that have no distinct SAP Tcode of their own. What I’m finding is that I’m now getting a confusing number of flavours because “PR05” is the hook. I don’t see an easy way to bring all of that stuff under one or two flavours. There is no way to control flavour selection to suit a navigation between flavours.

    As a user I would (and do) find it as irritating as hell to a) see flavour titles that are out of context and b) have to switch myself into the right one that is in context.

    Apologies if this isn’t clear (luckily) you have no need to use PR05 and can’t visualise my problem.



    P.S. I may have figured out a way to overcome the number for flavours of PR05, if it works I’ll post the results up.

    • Yes, sorry about the images problem. My fault. I will fix this, but I’ve been a bit busy since I noticed it. Come back in the next few days and I’ll have it sorted…


      • HI Steve,

        Thanks for sharing.

        I have one question, Suppose i have 5 subscreen, Shall i use Copy and Paste technique to copy the data from other screen or shall i use cache technique for this,



        • You have to copy values from their existing places, and paste them in their new places. That’s just the way it works. Your question, then, is really whether you need to cache them also.

          I would say in most cases you don’t. Caching is a just performance optimisation. You would use it if the process of driving the SAP backend to get the data to copy is very expensive and you need to repeat it often. If you are just doing a one-off screen simplification, caching is unlikely to be necessary, and might possibly make things slower. It certainly makes things significantly more complicated. Avoid it unless you really need it.


  • Hello,

    I’m implementing SAP Screen Personas 2.0, personally i think it’s a good tool. I think that SAP have to add others components(like a grid) and more properties for actual components.

    Currently I have a bit problem , i need redirec back button(F3) or disable back button back(F3). this is possible?

    • You can hide the standard back button and replace it with script button that does what you need. I do this in most of my flavours. There’s no way to intercept the F3 keypress, though, I’m afraid.