Background
When we had BW 3.x we could do a role upload into the Portal and everything gets created. After some customizing on the uploaded role, the end-user would get their reports. A few customers back than even developed their own application in BSP or WAD to display a Report Menu.
After BI 7.0 the whole picture changed and we no longer do role uploads for reports. Mainly because the security model changed from role based to data based. So customer had to define the data visibility of a report rather than the report itself. Since there is no role upload any longer customers need to maintain a neat Portal PCD filled with all sorts of BI content. After that, ask for a Portal Content Admin to create the navigation structure and so on.
Recently I came across a customer wishing to lower the Portal Content administration for BI Reports. What they wanted was to maintain the report entries on BI and those entries would automatically go into a user’s role. Meaning: once a new report comes up, they would just create an entry in the system and the report would magically appear to end-users.
The solution
The first alternative I came up with was to create an ABAP application (BSP, Webdynpro) to read a table where they would define such report entries. But I know there should be a more standard way of doing this. And in fact, there is. This customer had implemented Business Package for Plant Maintenance and it featured exactly what they requested. There was a transaction where they defined the report entries and each one made their ways into a Portal page.
The transaction in question is LPD_CUST which stands for Launchpad Customizing. Lucky me, this is a standard feature of most modern ABAP systems. A Launchpad is basically a Webdynpro Application that reads a definition from what’s customized via LPD_CUST and displays them as hyperlinks, just like a Workset Map iView – icons, descriptions and links are also available and customizable.
I was enthusiastic about Launchpad: besides being a standard feature, it supports the transport mechanism. So the customer requested a prototype.
Implementation
Step 1: Create the Application Launcher
First step it to create the Launchpad configuration. We do it using LPD_CUST:
We create a new application:
Fill in the application parameters:
After selecting the application category the bottom most area of the screen will change.
So you need to scroll down to the very end and you will see more options.
One might wonder why I didn’t create an application for BSP category.
Firt of all, there is no such category (at least on customer’s system).
Second, I used the simplest application I could find. It was just an example of Launchpad’s power and flexibility.
Step 2: Create an iView for this Launchpad
In Portal, create a remote Webdynpro ABAP iView, pointing to application APB_LAUNCHPAD.
The only thing you need to care about is the application’s parameters:
Preview
Now we can preview the Launchpad we have just created:
The road ahead
This is just a very modest example of how we create a Launchpad. Imagine if you create several Launchpads (one for each reporting scenario you have in your company). Then the Portal Role would carry just a link to those Launchpads. For a better user-experience you could create a Workset Map iView and include the lanchpads into a Workset.
Look & Feel
The following is a workset map iview containing the links for the abap launchers. I don’t need to mention this is all done in the Portal:
Once we click on a particular launcher we see what is defined on LPD_CUST:
Next steps
Figure out how to integrate other types of iViews and Web Apps into the lanchpad.
Watch for the next blogs on this topic.
Comments