- SAP Managed Tags:
One common question people ask is, "How do I create a custom table in a Personas flavour?" The standard answer is that you can't - Personas does not have a table object you can add to a flavour and while there is a "CopyTable" action to copy content from a standard table, there's no "PasteTable" action to put it back. But maybe you can fake it using the objects and actions that do exist? I had a request for a Personas flavour that would have been best implemented as a custom table so I thought I'd give it a try!
The scenario I was given is PO Release. We have a good number of users that do very little but release purchase orders. Currently they do that via ME28 or ME29N, and need to know the intricacies of release codes and release groups. I wanted to try and build something that made this easier for them. The first step was to create a custom report that lists all the POs waiting for release with a release code they have access to, so they didn't have to think about codes and groups. This isn't a particularly complex report, but does require digging through a user's profiles and authorisations. There are BAPIs to help with this. I won't show the details of this report here, as that's not the point of the blog. The end result is a report that looks like this:
I could build the release functionality into this report, but one thing that our existing Personas users like is being able to carry out tasks directly on the home screen (see Putting everything together - the finished Personas project). That means creating custom objects and scripts to copy data from transactions back to the home screen and manipulate it. What I needed to do was reproduce this table on the home screen, but as I said earlier there's no Personas table object. What I ended up with was this:
How did I achieve this? Firstly all the fields are standalone fields. The "refresh" button calls the above report, uses "CopyTable" to extract the data, JavaScript to transfer the data to a lot of separate variables (ponum1, ponum2, ponum3, etc...), and then a lot of "PasteValue" options to put them in the custom text boxes. Making it scroll adds some complexity. Here's the same video with a couple of hidden fields visible to see how the scrolling works:
The field on the right controls how many rows of the table in the original transaction to skip before copying. As you scroll down, this goes up. The field on the right is simply the number of rows in the table, and is used to stop the "scroll down" button from scrolling past the end of the table. The scroll buttons check that scrolling is possible based on these two fields, and adjust the number to skip as appropriate. Most of the hard work is done in a hidden button - let's call it the "Fill" button. The script here is the most complex.
The first steps just initialise the "lines to skip" field and then run the report. Here I'm running it via SE38 - for productive use the report would have its own transaction code:
Next I copy the table and extract the data. It generates a separate variable for each value copied - ponum1, vendor1, date1, ponum2, vendor2, date2, etc. This is all done in two JavaScript steps, one to empty all these variables and the second to copy the values.
The second JavaScript is where we take into account which row to start the copy process - notice the use of the "first" variable
rows = args.po_list[0].length;
args.rows = rows;
first = parseInt(args.first);
if(rows-first > 1) {
args.ponum1 = args.po_list[0][first+1];
args.vendor1 = args.po_list[1][first+1];
args.date1 = args.po_list[3][first+1];
args.relcode1 = args.po_list[4][first+1];
}
if(rows-first > 2) {
args.ponum2 = args.po_list[0][first+2];
args.vendor2 = args.po_list[1][first+2];
args.date2 = args.po_list[3][first+2];
args.relcode2 = args.po_list[4][first+2];
}
if(rows-first > 3) {
args.ponum3 = args.po_list[0][first+3];
args.vendor3 = args.po_list[1][first+3];
args.date3 = args.po_list[3][first+3];
args.relcode3 = args.po_list[4][first+3];
}
if(rows-first > 4) {
args.ponum4 = args.po_list[0][first+4];
args.vendor4 = args.po_list[1][first+4];
args.date4 = args.po_list[3][first+4];
args.relcode4 = args.po_list[4][first+4];
}
if(rows-first > 5) {
args.ponum5 = args.po_list[0][first+5];
args.vendor5 = args.po_list[1][first+5];
args.date5 = args.po_list[3][first+5];
args.relcode5 = args.po_list[4][first+5];
}
That's the interesting part over. Now we just head back to the home screen and paste everything into all the custom fields. Long and tedious... :smile:
With all that done in the hidden "fill" button, the scripts on the visible buttons are easy. The refresh button simply initialises the hidden "first" field to 0 and then pushes the "Fill" button. The "Scroll up" button subtracts 1 from "first", unless it is 0 already, and pushes the "Fill" button. The "Scroll down" button adds 1, unless that would take us too far, and pushes "Fill". In both cases you need to use JavaScript to do the arithmetic, but otherwise the scripts are straightforward.
Overall I'm very pleased with the effect, although I'd like to try and optimise the scrolling a little. I'm not sure my users would like the slow response time. It is also going to put a lot more load on the backend system, because it calls the report afresh for each scroll step. You wouldn't want to do this unless the table was short and the report very quick. Consequently, I'm not sure I'd want to use this technique often - using a proper table on a proper SAPgui transaction would certainly be preferable. In the right context, though, and bearing all these things in mind, it might be useful occasionally. And it was fun building it!
Are there any situations where you've wanted a custom table in a Personas flavour, and this technique might work for you?
(I'll blog the rest of the PO Release app separately - this blog is already long enough...)
28 Comments
