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…