Skip to Content

The marketing tagline for Personas is “personalisation without programming”. I understand where that comes from, and if you can legitimately call Personas scripting (at least at a basic level) “not programming” then you can get quite a lot done that way. However I find that some useful techniques require a genuine programming mindset. Even if you stay within the bounds of standard Personas scripting then things can get quite involved. Take, for instance, the scripting necessary for my Transaction-free lookup with Personas techniques, especially when combined with Creating bullet-proof Personas scripts. You can then stray beyond standard Personas scripting by Calling RFCs from a Personas script, which obviously requires ABAP skills. I have found several reasons to do this, some of which work around limitations of current Personas scripting, but all of which have made my final product much better. Here’s another example of where ABAP skills can make a big difference.

 

In the second part of the “transaction free lookup” blog referenced above I show how to use a list display transaction to create something like a search help, in that example for functional locations. It allows you to search for functional locations knowing just part of the description, like this:

 

My users also wanted to be able to search for purchase orders in a similar way. However, when they search for purchase orders they always start with the vendor. They know who they bought from and want a list of all relevant purchase orders to choose from. Of course, when they say they know the vendor, they don’t know the vendor number, just the name. And not necessarily the name known to SAP but the name they always use informally amongst themselves. So my search here needed to be for all purchase orders raised on vendors with names like “X”. There is no standard purchase order list display that does that.

 

It isn’t hard to write one, though, for a decent ABAPer. And that means I can build Personas functionality that works like this:

 

Here I know the vendor has “institute” in the name but I can’t remember the exact name. Hitting find shows me all the POs raised against any vendor than matches. There’s a date range to restrict the search. I’m typing in an old range as this is our development system – if left blank the “find” button would default something more recent. Note that the generated PO list contains not just the vendor, PO number and date, but also the description from the first line of the PO. For our users that last detail was important for finding the right PO. As I said, writing the ABAP report to produce this list wasn’t hard, but the combination of it with some UI enhancements via Personas gives our users a very powerful search mechanism.

 

The Personas technique for building this lookup is exactly the same as the one described above for functional locations. The new thing here is writing a custom list display transaction just for this search.

 

When you are thinking about what you can do with Personas, remember that it isn’t just for manipulating existing standard ABAP dynpro transactions, but it can also be used with any new ones you write, and that there’s nothing wrong with writing new stuff specifically to use with Personas. Whatever provides the best end result for your users…

To report this post you need to login first.

5 Comments

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

  1. Simon Kemp

    Hi Steve,

    You make a very valid point. While “no programming required” and “if you can build a power point slide you can build a screen persona” may be a useful marketing taglines – they are really just that. I remember when Visual Composer came out with similar marketing slogans… the reality there too was that to really build a decent visual composer application you needed to know more than your average bear.

    Thanks for continuing to share your experience with Screen Personas.

    Simon

    (0) 
    1. Steve Rumsby Post author

      Thanks Simon. I really do think that the focus on “without programming” is making Personas seem like a much smaller product than it really is.

      Steve.

      (0) 
      1. Abhijit Moholkar

        Hi Steve,

        Fantastic article. This has opened a all new ways to utilize persona using ABAP. Like making it a purely presentation layer and business logic outsourced to ABAP. It also creates scope and need for ABAP consultants and someone with ABAP skill can be a key resource in Personas projects.

        Waiting for more from you.

        Regards

        Abhi.

        (0) 
        1. Steve Rumsby Post author

          Yes, you can consider Personas as just a presentation layer for business functionality written in custom ABAP. However, just as using Personas with no programming misses some of its potential, so I think using it just as a presentation layer also misses some of its potential.

          One of the reasons I found Personas as a concept so attractive is that it allows you to build new user interfaces using existing ERP transactions as building blocks. During any implementation or upgrade you are going to test all of those transactions anyway, and so the testing load from even a sizeable Personas development is quite small. As, of course, is the initial development effort. Reskinning a standard SAP transaction, even with complex Personas scripting, is much easier than building the business logic from scratch in ABAP. This is such a great advantage of Personas that you really shouldn’t ignore it!

          As the title of this blog suggests, using standard SAP transactions where possible and adding just a little custom ABAP where absolutely necessary, is the ideal mix. Does that make sense?

          Steve.

          (0) 
          1. Abhijit Moholkar

            Hi Steve,

            I think that perfectly makes sense. Sorry, I did not respond immediately as I was thinking about what you replied and could not decide on how it should be or rather can be.

            But now it makes sense. Now I am almost certain that, we should use Personas to “re-skin” SAP, provide data to the user by automating multi-transactional access and reading screen values, without over-burdening the tool. This might mean, stricter and maximum possible selection criterias while executing reports, automating transactions where with moderate or intermediate leve of complexity.

            Again, these are still scattered thoughts, I am only 10 days old in Persona life 🙂 …..so lot to explore and lot to discuss….hope you won’t get fed up….

            Thanks for sharing your thoughts and works. They are a great help to us.

            Regards

            Abhi.

            (0) 

Leave a Reply