SAP ERP 6.0 EhP3 and EhP4
MarchAugust 2000August 2000 2010
EnglishEnglish
APOHow to Develop POWER Lists
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf
Germany / How-to Guide:
Enablement Kit for SAP NetWeaver Business Client – V1.30

SAP Best PracticesHow to Develop POWER Lists

Copyright

© 2010 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook,and PowerPointare registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWinare trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP France in the United States and in other countries.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Icons

Icon / Meaning
/ Caution
/ Example
/ Note or Tip
/ Recommendation
/ Syntax

Typographic Conventions

Type Style / Description
Example text / Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths and options.
Cross-references to other documentation.
Example text / Emphasized words or phrases in body text, titles of graphics and tables.
EXAMPLE TEXT / Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example, SELECT and INCLUDE.
Example text / Screen output. This includes file and directory names and their paths, messages, source code, names of variables and parameters as well as names of installation, upgrade and database tools.
EXAMPLE TEXT / Keys on the keyboard, for example, function keys (such as F2) or the ENTER key.
Example text / Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.
<Example text> / Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.

Contents

1Purpose

2Prerequisites

3Development of own POWER Lists

3.1Basic Concept of POWER Lists

3.2POWER List Design

3.3POWER List Implementation

3.3.1Creating a new POWER List

3.3.2Maintenance of the Feeder Class methods

3.3.3Register a POWER List and make it visible

3.3.4Create a Query for a POWER List

3.3.5Connecting a POWER List to a Role

3.3.6Adding Transactions to Role and Defining OBN for POWLs

3.3.7POWER List Cache and User defined queries

3.3.8Pre-defined POWER Lists

3.4Advanced techniques for POWER List improvement

4Description of the Feeder Interface

4.1Description of the Feeder Interface IF_POWL_FEEDER

4.1.1Method GET_ACTIONS

4.1.2Method GET_ACTION_CONF

4.1.3Method GET_SEL_CRITERIA

4.1.4Method GET_FIELD_CATALOG

4.1.5Method GET_OBJECT_DEFINITION

4.1.6Method GET_OBJECTS

4.1.7Method GET_DETAIL_COMP

4.1.8Method HANDLE_ACTION

How to Develop POWER Lists

1Purpose

This guide describes the technical background as well as the concept of POWER Lists. In the main part, the development of own POWER List is explained.

2Prerequisites

Required Authorizations for development, role management and maintenance of cross client views.

3Development of own POWER Lists

3.1Basic Concept of POWER Lists

The POWER List is basically a framework that can list business objects and allows specific activities (actions) based on these business objects.

The central idea is that all properties of a POWER List (the whole scope described in HOW_TO_USE) can be specified viaone central, standardized class (the so called feeder class).This way an easy to handlethough powerful tool is provided to modify pre-defined POWER Lists respectively develop own ones.

The Feeder Class

The feeder class communicates with the database selecting specific data, forwards the data to a POWER List’s internal cache and refreshes the POWER List on the user’s client on demand. Moreover the feeder class includes the handling of actions initiated by the user while pressing a button.

Embedded into a well defined framework the feeder class is the central and most important place while developing or modifying POWER Lists. Therefore developing an own POWER List in principle means developing an own feeder.

Before we can go into details on the feeder class and its specific methods, another aspect of POWER Lists must be mentioned: the role dependency.

Role Dependency

As the connection between the user and the POWER Lists is done via the roles, it is possible to arrange several different POWER Lists from SAP and/or Partners into one or several roles. The roles are the access point to all the POWER Lists in the system. While exceptions may apply, in most cases, POWER Lists are launched as “homepages” within the canvas area of the SAP NetWeaver Business Client while having the navigation panel on the left side.

From a technical point of view a so called APPLID (application identifier) determines, which POWER List (POWL Application) will be called. Therefore the assignment of APPLIDs to a particular role determines which POWER List will be available for the role.

Beneath development of an own feeder the creation of a new POWER List requires the definition and assignment of an APPLID and assignment to appropriate roles as well.

3.2POWER List Design

Before starting developing a feeder (and a new POWER Lists),please also notethe following aspect of the whole concept.

Developing a POWER Lists doesnot mean to develop some feeder coding, only. Developing the coding is one task of a sequence you need to do.

The most important step to highlight is the design phase. Be aware that a good design upfront can not only speed up the process of developing the coding but also to increase the efficiency of the final POWER List and the way the user can work with it.

For a good design you should at least have a draft available for:

  • The data you want to select. Most common questions: Where can I find the data? What are the data types? Which function modules can be used? Do I need to develop own function modules?
  • The selection criteria you want to offer. Most common questions: Which selection makes sense for the user? Are there performance impacts to be considered?
  • The buttons you want to include. Most common questions: What are the actions? Button names? Can I use function modules? Will the buttons launch transactions?
  • Detailed component. Most common questions: Do I need the detailed component? Which data do I need to show up in the detailed view?

After developing the coding, you also need to test your POWER List. Make sure, especially for the pre-defined setting you might add to your feeder, that you are testing in a real environment, not only with real data, but also with a user which doesn’t hold SAP_ALL or similar authorization.

3.3POWER List Implementation

SAP ships pre-defined POWER Lists with the new Enhancement Packages for SAP ERP. These lists can be used as templates to define other POWER Lists, or to slightly modify them. A customer could also use them directly without modification. However, this needs to be checked in every case, as the business objects in the system for sure depend on the customizing settings of the customer. In some cases, a pre-defined POWER List cannot be used as it is, because of these customer specific settings and needs to be adjusted.

In all cases, SAP recommends to copy the pre-defined POWER Lists into customer namespace (Z* or Y*) to avoid conflicts in later system upgrades.

For sure, also SAP Partners can pre-define POWER Lists for their customers. They can leverage from the SAP Power Lists or they can develop completely new POWER Lists from scratch.

3.3.1Creating a new POWER List

Use

We will create a new feeder via the Class Builder. However instead of developing a new class from the scratch we will use the pre-defined interface IF_POWL_FEEDER and modify the contained methods afterwards.

Procedure

  1. Access the transaction choosing one of the following navigation options:

SAP ERP menu / ToolsABAP WorkbenchDevelopmentClass Builder
Transaction code / SE24
  1. On the Class Builder: Initial Screen, make the following entries:

Field name / User action and values
Object Type / Specify the name of your new feeder using the prefix “Z” or “Y” to ensure your feeder is developed in the customer namespace
  1. ChooseCreate.
  2. In the dialog boxObject Type leave the fields Name and the default option Class as they are and chooseEnter.
  3. On the Create Class screen provide an appropriate description for your POWER List.

Field name / User action and values
Description / Appropriate Description for the new POWER List

Leave all other fields as they are and chooseSave.

  1. On the Create Object Directory Entrysubscreen choose a package for the new development.

Field name / User action and values
Package / Specify the package name or choose via input help.

ChooseEnter in order to acknowledge the package or Local Object in case of a local development.

  1. Move to tab Interfaces on the Class Builder: Change Class screen

Field name / User action and values / Comment
Interface / Insert IF_POWL_FEEDER / This is the interface provided by SAP that contains all methods for the feeder

ChooseEnter.

  1. ChooseSave.

Result

All available methods and attributes of the feeder class are uploaded into the class builder and can now be modified according to your requirements (please see Maintenance of the Feeder Class methods for a description of all feeder class methods).

It might be useful to copy an existing feeder class and modify the copied version according to your needs. As basis you should choose a POWER List that matches your requirements the closest.Via transactions POWL_TYPER and FPB_MAINTAIN_HIER the APPLID as well as the Name of the corresponding feeder can be found out. Just specify that feeder name in the initial screen of the class builder (SE24); instead of create,chooseCopy from the menu.

Example

This example shows how to copy the existing feeder class for Vendors:

  1. Access the transaction choosing one of the following navigation options:

SAP ERP menu / Tools ABAP WorkbenchDevelopmentClass Builder
Transaction code / SE24
  1. On the Class Builder: Initial Screen, make the following entries:

Field name / User action and values
Object Type / /KYK/CL_MM_POWL_VENDOR_LIST
  1. Choose Copy Class/Interface (CTRL+F5).
  2. In the dialog box Copy provide an appropriate name for the target feeder class.

Field name / User action and values
Copy to / e.g. Z_MM_POWL_VENDOR_LIST
  1. ChooseContinue (Enter).

At this point you have created a 1:1-copy of the feeder class for Vendors. You could activate the copied class by choosing Activate (Ctrl+F3) and proceed with Register a POWER List and make it visible.

3.3.2Maintenance of the Feeder Class methods

After creation of a new feeder class (described in Creating a new POWER List) all necessarymethods of the class are available and can be implemented. If you have just created a new class and are still on the screen Class Builder: Change Class you can proceed with specifying the code for the methods required (4). Otherwise use transaction SE24 to modify the newly created feeder.

  1. Access the transaction by choosing one of the following navigation options:

SAP ERP menu / Tools ABAP WorkbenchDevelopmentClass Builder
Transaction code / SE24
  1. On the Class Builder: Initial Screen, make the following entries:

Field name / User action and values
Object Type / Specify the name of the feeder you want to modify.
  1. ChooseChange.
  2. On the screen Class Builder: Change Class choose tab Methods.If you enter a method via double-click, a new window will open up. In this window, the method specific coding takes place. Please see the SAP NetWeaver-Help on ABAP Workbench:Tools Class Builderfor a general description how to make developments with the class builder.
  3. Activate the feeder class resp. the changes. Use the Activate button or CTRL+F3 for this purpose.

Not all methods provided by the POWER List interface need to be used from the start; there are mandatory methods and optional ones. You can start developing a simple feeder, which only shows business objects. From there, you can then improve your feeder step by step.

The mandatory steps to take to develop a simple feeder are:

  • Define a data container (Method “GET_OBJECT_DEFINITION”)
    This method is used to define the container (e.g. specify field types) where the selected data gets stored. Caching and other mechanisms of the POWER Lists technology will be handled automatically in the background based on these settings. So there is no need to explicitly take care on things like caching data and so on. (see details and example for Method GET_OBJECT_DEFINITION )
  • Retrieve data from the backend system (Method “GET_OBJECTS”)
    Here you need to define the data retrieval itself. This can be either a very simple database select (e.g. select * from xyz) or a complex selection where you use existing SAP function modules or your own coding (see details and example forMethod GET_OBJECTS ).

With maintaining only these two methods with coding, a feeder with minimal functionality is available. Since there is no default query defined yet, the resulting POWER Listwill be more or less unusable. However, if you want to test the feeder at this stage, you can register the POWER List as described in Registering a POWER List and make it visible and enhance it step by step.

The following additional methods are part of the standard feeder interface:

  • Define selection criteria (Method “GET_SEL_CRITERIA”)
    With this method you can define, which selection criteria is visible and selectable by the user. Example: You have a POWER List showing billing documents. You could offer the selection criteria “billing date” so that the user can later retrieve the data directly the way he searches for it. (see details and example for Method GET_SEL_CRITERIA).
  • Define the field catalog (Method ‘GET_FIELD_CATALOG”)
    (see details and example for Method GET_FIELD_CATALOG)
  • Define buttons and their actions (Methods “GET_ACTIONS” & “HANDLE_ACTION”)
    By maintaining the two methods GET_ACTIONS and HANDLE_ACTION, you have a huge variety of options to improve the POWER Lists significantly. First you need to define the buttons with name, index and more (GET ACTIONS). Second you need to define the actions which should be initiated if the user presses such a button. The action can simply be launching a transaction and forwarding the business object parameters to it. Or it could be used to simplify a whole process by using the buttons to call several function modules in a sequence automating the process in the background based on the selected item(s) in the POWER List. (see details and example for Method GET_ACTIONS and HANDLE_ACTION)
  • Define a confirmation dialog box (Method “GET_ACTION_CONF”)
    Using this method allows you to throw a dialog box with some information like a confirmation. Think of a business object you can delete via a button in the POWER list. A confirmation dialog box could ask whether the user is sure to delete this object (see details and example for Method GET_ACTION_CONF).
  • Enable the detail component feature (Method “GET_DETAIL_COMP”)
    This method can be used in case you want to show a detailed view of a specific business object below the POWER List. This could be helpful if you have large data sets where a horizontal scrolling is too time consuming or not quite usable. In this case, the detailed component offers a good alternative as it provides a detailed view area below the list, where you can show all the different fields without the need of horizontal scrolling. (see details and example forMethod GET_DETAIL_COMP)

Not all of the methods described above need to be maintained to get a working POWER List. However, it is important to notice that none of the standard feeder methods must be deleted, even if they are empty. Moreover you have to ensure that all standard feeder methods are activated before the POWER List can be used. Otherwise a shortdump is likely to occur during execution.