PowerLists_HowToDevelop - Community Wiki
|SAP ERP 6.0 EhP3 and EhP4 | |
|MarchAugust 2000August 2000 2010 | |
|EnglishEnglish | |
| |APOHow to Develop POWER Lists |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| |How-to Guide: |
| |Enablement Kit for SAP NetWeaver Business Client – V1.30 |
| | |
| | |
| | |
| | |
| | |
|SAP AG | |
|Dietmar-Hopp-Allee 16 | |
|69190 Walldorf | |
|Germany | |
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 PowerPoint are 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 MultiWin are 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 |
|[pic] |Caution |
|[pic] |Example |
|[pic] |Note or Tip |
|[pic] |Recommendation |
|[pic] |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. |
| |Variable user entry. Pointed brackets indicate that you replace these words and characters |
| |with appropriate entries. |
Contents
1 Purpose 5
2 Prerequisites 5
3 Development of own POWER Lists 5
3.1 Basic Concept of POWER Lists 5
3.2 POWER List Design 6
3.3 POWER List Implementation 7
3.3.1 Creating a new POWER List 7
3.3.2 Maintenance of the Feeder Class methods 9
3.3.3 Register a POWER List and make it visible 11
3.3.4 Create a Query for a POWER List 13
3.3.5 Connecting a POWER List to a Role 16
3.3.6 Adding Transactions to Role and Defining OBN for POWLs 17
3.3.7 POWER List Cache and User defined queries 18
3.3.8 Pre-defined POWER Lists 19
3.4 Advanced techniques for POWER List improvement 19
4 Description of the Feeder Interface 20
4.1 Description of the Feeder Interface IF_POWL_FEEDER 20
4.1.1 Method GET_ACTIONS 20
4.1.2 Method GET_ACTION_CONF 23
4.1.3 Method GET_SEL_CRITERIA 24
4.1.4 Method GET_FIELD_CATALOG 28
4.1.5 Method GET_OBJECT_DEFINITION 34
4.1.6 Method GET_OBJECTS 35
4.1.7 Method GET_DETAIL_COMP 37
4.1.8 Method HANDLE_ACTION 39
How to Develop POWER Lists
Purpose
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.
Prerequisites
Required Authorizations for development, role management and maintenance of cross client views.
Development of own POWER Lists
1 Basic 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 via one central, standardized class (the so called feeder class). This way an easy to handle though 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.
[pic]
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.
[pic]
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.
2 POWER List Design
Before starting developing a feeder (and a new POWER Lists), please also note the following aspect of the whole concept.
Developing a POWER Lists does not 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 POWER 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.
1 Creating 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 |
2. 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 |
3. Choose Create.
4. In the dialog box Object Type leave the fields Name and the default option Class as they are and choose Enter.
5. 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 choose Save.
6. On the Create Object Directory Entry subscreen choose a package for the new development.
|Field name |User action and values |
|Package |Specify the package name or choose via input help. |
Choose Enter in order to acknowledge the package or Local Object in case of a local development.
7. 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 |
Choose Enter.
8. Choose Save.
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).
[pic]
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, choose Copy from the menu.
[pic] 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 |
2. On the Class Builder: Initial Screen, make the following entries:
|Field name |User action and values |
|Object Type |/KYK/CL_MM_POWL_VENDOR_LIST |
3. Choose Copy Class/Interface (CTRL+F5).
4. 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 |
5. Choose Continue (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.
2 Maintenance of the Feeder Class methods
After creation of a new feeder class (described in Creating a new POWER List) all necessary methods 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 |
2. 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. |
3. Choose Change.
4. 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 Builder for a general description how to make developments with the class builder.
5. 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 for Method 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 List will 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 for Method GET_DETAIL_COMP)
[pic] 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 short dump is likely to occur during execution.
3 Register a POWER List and make it visible
After a feeder is developed, it needs to be made visible to the roles. Basically, this means we need to register the feeder under a specific APPLID, define a POWER List type and introduce it to the roles.
Creating an APPLID for the POWER List
Use
First of all, you need to specify the so-called APPLID (Application ID). This ID will later be used in the role to specify the target (your feeder) which will then be shown as POWER List homepage in the SAP NetWeaver Business Client. The APPLID is more or less just a name to specify.
Procedure
1. Access the transaction choosing the following navigation option:
|Transaction code |FPB_MAINTAIN_HIER |
2. On the Display View “Personalization Hierarchy”: Overview screen, choose Display Change (Ctrl + F1).
3. In the dialog box Caution Table is cross client, choose OK.
4. From the menu bar choose New Entries.
5. In the grid Personalization Hierarchy, make the following entry:
|Field name |User action and values |
|Personalization |Specify an APPLID for the POWER Application |
|Application | |
|Text |Specify an appropriate description. |
6. Choose Save.
7. Specify a transport order in the upcoming dialog.
Specifying the POWER List Type
As next step, you need to specify the POWER List type. We have seen that a POWER List provides 1 to n types of object types a user can select from. At this point it becomes clear that the types are exactly the feeders we can develop. In other words, we need to define our feeder as possible POWER List type.
(Feeder Class must be activated)
Procedure
1. Access the transaction choosing the following navigation option:
|Transaction code |POWL_TYPE |
2. In the dialog box Caution Table is cross client, choose OK.
3. From the menu bar choose New Entries.
4. On the View: Type Definition screen, make the following entry:
|Field name |User action and values |
| Type |Specify an appropriate name as Feeder Type. (Use the input help, only if you want to use or change |
| |an existing assignment; otherwise insert a name of the type to be created.) |
|Description |Specify an appropriate description |
|Feeder Class |Choose the feeder class via input help. |
| |[pic] A new feeder won’t be available in the dialog box until it is activated. |
|Sync. Call |This checkbox can be set to enforce synchronous query refreshes. |
|No Msg. Wrapping |For POWER Lists a so-called Message Wrapping takes place by default. That is, in case of errors |
| |during POWER List execution, the UI does not show the system-generated messages. Instead, the error |
| |messages are 'wrapped up' into a generic one, which is more meaningful to the end-user. For |
| |debugging purposes, however, it might be useful to disable this message wrapping mechanism by using |
| |this flag. |
5. Choose Save.
6. Specify a transport order in the upcoming dialog.
Role assignment for the POWER List Type
Finally, we connect the APPLID with the type and make it visible to the role. In detail this means that I can now select my APPLID in a role item.
Procedure
1. Access the transaction choosing the following navigation option:
|Transaction code |POWL_TYPER |
2. From the menu bar choose New Entries.
3. On the New Entries: Details of Added Entries screen, make the following entry:
|Field name |User action and values |
| Application |Choose APPLID defined in FPB_MAINTAIN_HIER via input help |
|Role |Optional field; specify only if a role dependent mapping is required |
|Type |Choose the POWER List Type defined in POWL_TYPE via input help |
4. Choose Save.
5. Specify a transport order in the upcoming dialog.
[pic]
It might be useful to check the mappings that have been made so far. Test a POWER List via SAP Menu describes an easy way to test the newly created POWER List using the Favorites of SAP Menu. Basically the POWER List should work at this point; however, it will be empty, since there is no default query defined yet.
4 Create a Query for a POWER List
Define the Query
Use
Default queries are defined using the transaction “POWL_QUERY”. Here you can define a query (QUERYID) and connect it to a POWER Lists type. Finally, you can set up the query.
Procedure
1. Access the transaction choosing the following navigation option:
|Transaction code |POWL_QUERY |
2. From the menu bar choose New Entries.
3. On the Maintain Table Views: Initial screen, make the following entry:
|Field name |User action and values |
|Query ID |Provide an appropriate Identifier for the Query |
|Description |Specify a description for the Query |
|Type |Choose the POWER List Type via input help |
|Sync. Call |This checkbox can be set to enforce synchronous query refreshes. In case the flag is set, the option|
| |applies to all queries connected to the type and then overrides the setting for the query itself |
|Layout |Default ALV Layout view (optional) |
4. Choose Save.
5. Specify a transport order in the upcoming dialog boxes.
6. At this point, two additional buttons “Query Parameters” and “Query Settings” should be available in the menu bar (in case they are not – refresh the screen by using the Back button (F3) from the menu to leave the screen and re-enter it by double clicking on the newly created Query ID).
Now you can maintain the query parameters and the query settings
▪ Button “Query Parameters”
Here you can set the parameters the same way as you would do it as a user creating a new query. However, the difference here is that this setting is available system-wide and is therefore available to every user. Define your settings, press the Check button followed by the Accept button.
(GET_SELCRITERIA specifies the parameters available. If the method is empty, there will be no parameters for selection).
▪ Button Query Settings
In the upcoming window, you can specify several attributes mapped to each single selection criteria.
[pic] Please ensure that all standard feeder methods are activated before you use the buttons (esp. GET_SELCRITERIA). Even though the methods might remain empty, they must be implemented and activated. Otherwise a shortdump is likely to occur,
7. Choose Save and specify a transport order in the upcoming dialogs boxes.
Role assignment for the Query Type
As with the type, the query needs to be introduced to the roles. Therefore the APPLID and the QUERYID get mapped to each other.
Procedure
1. Access the transaction choosing the following navigation option:
|Transaction code |POWL_QUERYR |
2. From the menu bar choose New Entries.
3. On the New Entries: Details of Added Entries screen, make the following entry:
|Field name |User action and values |
|Application |Choose APPLID defined in FPB_MAINTAIN_HIER via input help |
|Role |Optional field; specify only if a role dependent mapping is required |
|Query ID |Choose the Query ID via input help |
|Category |Category (category assignment for link matrix mode); you can assign default categories to the POWLs.|
| |The categories are meant to structure several queries for a POWER List in a link matrix. This |
| |display mode can be chosen during personalization in the SAP NetWeaver Business Client (NWBC). The |
| |user can also create his own categories in NWBC. For more information see also the documentation How|
| |to … Use POWER Lists on this DVD. |
|Category sequence no |Sequence number for POWL query category. You define here the sequence of the categories in the link |
| |matrix mode. |
|Query sequence no |Sequence no for a query for link matrix mode. If several default queries have been designed you can |
| |define here the sequence of their appearance in NWBC. |
|Tab sequence no |Sequence number for a query for tab strip mode. Every query is displayed as separate tab page in the|
| |NWBC if the tab strip mode in the personalization has been chosen. You define here the sequence of |
| |their appearance. |
|Activate |Flag: query is activated; if unset, the user has to activate it in the NW Business Client during |
| |List definition |
4. Choose Save.
5. Specify a transport order in the upcoming dialog.
Your POWER List should now come up with a predefined query.
2 Test a POWER List via SAP Menu
[pic]
Before a newly created POWER List is connected to the roles and the UI of the NetWeaver Business Client, there is an easy way to test the POWER List via the Favorites folder of the SAP Menu of the back-end system.
Prerequisites
Ensure that the Web Dynpro service is activated. Normally the activation should have been done during system setup for using the NetWeaver Business Client.
Perform the following steps in case the service is inactive:
1. Access the transaction choosing the following navigation option:
|Transaction code |SICF |
2. On the Maintain Service screen leave the default values as they are and choose Execute (F8).
3. In the Virtual Hosts/ Services tree control locate the node sap/bc/webdynpro. Right click on the node and choose Activate Service from the context menu.
Procedure
1. Navigate to the initial screen of the SAP Easy Access Menu.
2. Choose Favorites -> Add other objects in the menu.
3. Choose Web Dynpro Application from the upcoming dialog box list.
4. On the Web Dynpro Application subscreen, make the following entries.
|Field name |User action and values |
| Web Dynpro Applicat. |POWL |
|Description |Specify a description for the Favorite |
|Protocol |Leave the checkbox HTTPS unchecked. In the SAP NetWeaver Business Client (NWBC) , you can define |
| |which protocol is used. In case you make any settings here, these will be overwritten by the |
| |settings in the NWBC. |
|Start Mode |Leave option Browser |
|Parameter |APPLID |
| |[pic] Be sure to select the parameter via input help. |
|Value |Specify the APPLID defined for the POWER List to test. |
5. Choose OK.
Result
By double-click on the created favorite, the specified POWER List will be displayed in a separate Browser window. This way the basic functionalities of a new development can be tested independently from the NetWeaver Business Client. Especially the correctness of type mapping and the standard query can be checked in an easy way.
[pic]
For a complete functionality test however it is recommended to make the POWER List available in the Business Client and test it with different users and roles. Using the SAP menu, OBN navigation cannot be tested anyway, since the target transactions must be specified for the specific roles.
5 Connecting a POWER List to a Role
Prerequisites
Ensure that the Web Dynpro service is activated. Normally the activation should have been done during system setup for using the NetWeaver Business Client. Please use transaction SICF in case the service is inactive (as described in Test a POWER List via SAP Menu).
Procedure
1. Access the transaction choosing one of the following navigation options:
|SAP ERP menu |Tools ( Administration ( User Maintenance ( Role Administration ( Roles |
|Transaction code |PFCG |
2. On the Role Maintenance screen make the following entry:
|Field name |User action and values |
| Role |Specify the role to be maintained |
3. Choose Change.
4. On the screen Change Role navigate to tab Menu.
5. Navigate to the specific folder within the role menu.
6. Choose Others.
7. Choose entry Web Dynpro Application on the upcoming subscreen Add additional objects.
8. On the Web Dynpro Application subscreen, make the following entries.
|Field name |User action and values |
| Web Dynpro Applicat. |Insert POWL |
|Description |Specify a description for the Favorite |
|Protocol |Leave checkbox HTTPS unchecked. In the SAP NetWeaver Business Client (NWBC) , you can define which |
| |protocol is used. In case you make any settings here, these will be overwritten by the settings in |
| |the NWBC. |
|Start Mode |Leave option Browser |
|Parameter |APPLID |
| |[pic] Be sure to select the parameter via input help. |
|Value |Specify the APPLID defined for the POWER List to be assigned |
9. Choose OK.
[pic]
If the entry "Additional Details" is not visible please check note 955258.
10. Choose Save.
[pic]
By default, a POWER List is not refreshed automatically within the SAP NetWeaver Business Client. If a result list contains a lot of entries, performance issues may occur. And if the content of the displayed sets doesn't change very often an automatic refresh is not necessary.
However, in case an automatic refresh is required, then it can be achieved by providing an additional parameter REFRESHQ for the respective POWL. Please proceed as described above (8) and add parameter REFRESHQ in the parameter section of the pop-up: the value should be set to „X“. (without the quotes).
Result
The POWER List is available as new node in the role menu and can be tested via Execute from the context menu (right click).
Please remember to maintain appropriate Authorizations for the new entry as it is described in the guide K53_How_to_Guide_EN_DE.doc.
[pic]
In case the POWER List feeder uses OBN-navigation (method HANDLE_ACTION) and is supposed to call a target transaction, it is necessary to add it on the Menu tab (button Transactions) of the Change Role screen. Here it it also possible to assign the Business Objects-method to the specific transaction and to map the Business Object-parameters.
6 Adding Transactions to Role and Defining OBN for POWLs
Procedure
1. Access the transaction choosing one of the following navigation options:
|SAP ERP menu |Tools ( Administration ( User Maintenance ( Role Administration ( Roles |
|Transaction code |PFCG |
2. On the Role Maintenance screen make the following entry:
|Field name |User action and values |
| Role |Specify the role to be maintained |
3. Choose Change.
4. On the screen Change Role navigate to tab Menu.
5. Navigate to the specific folder within the role menu.
6. Choose [pic].
7. In the upcoming dialog box Assign Transactions make the following entry:
|Field name |User action and values |
| Transaction |Target transaction to be called |
8. Choose Assign transactions.
9. Right click on the newly created entry and choose Details for NetWeaver Business Client (or Additional Details for SAP ERP EhP3) from the Context Menu.
10. In the upcoming dialog box Additional Details make the following entries:
|Field name |User action and values |
|Description |Appropriate description |
|Invisible |Check Invisible and leave all other checkboxes unchecked. |
11. Choose [pic] Insert Method in group Business Object.
12. In the upcoming dialog box Select Method make the following entries:
|Field name |User action and values |
|Obj. Type |Select the Object Type to be used for OBN-navigation. That is the object specified in method |
| |HANDLE_ACTION of the feeder class. |
|Method |Select the Business Object-method to be used for OBN-navigation. That is the method specified in |
| |method HANDLE_ACTION of the feeder class |
Please see Example for method HANDLE_ACTION for details.
13. Choose Enter.
14. In the upcoming dialog box Parameter Mapping make the following entries:
Choose [pic] Insert Parameter and specify the parameter mapping.
|Field name |User action and values |
|Transaction |Screen field of the transaction (can be found out e.g. via F1Help in the transaction screen). |
|Value |Choose the parameter to be mapped to screen field via input help. |
15. Repeat this action for each parameter to be mapped.
16. Confirm all open dialog boxes with Enter.
17. Choose Save.
7 POWER List Cache and User defined queries
As described in the document K51_How_to_Use_Guide_EN_DE.doc, the queries of a POWER List selection are stored temporarily in a special cache. During the development phase of new POWER List it might be useful to refresh the cache, especially when the POWER List logic or the underlying query has been changed. Sometimes it might be desired to delete all user defined queries.
For this purpose the following reports are provided, which can be executed via transaction SE38.
■ POWL_WLOAD: refresh POWL cache when changing POWERLIST logic during a session
■ POWL_D01: delete all queries per applid and user
■ POWL_WLOAD: define refresh interval for cached queries, set flag ‘Discard old cached results
8 Pre-defined POWER Lists
As described earlier in 3.3.1 (Creating a new POWER List), it might be helpful to use already existing POWER Lists as basis for creating new ones.
In order to get an overview of all POWER Lists available in the system, you can use the Data Browser (transaction SE16) and show all entries of table POWL_TYPE; set an appropriate value for Maximum No. of Hits (use Number of Entries beforehand).
The easiest way to get a simple list would be to extract the result list via Edit->Download into a required file format, e.g. an Excel Spreadsheet. Afterwards it might be reworked according to your needs.
4 Advanced techniques for POWER List improvement
While in the previous chapters the basic steps for development of POWER List have been described, there are additional techniques for enhancement resp. improvement.
▪ Dynamic Selection Criteria
For Date fields it is possible to set dynamic values for selection e.g. Today +/- Number of Days
Detailed information on this functionality is given in document HowToDevelopandUseDynamicVariables.pdf. also available in the enablement kit for NWBC – V1.30.
▪ Visible Columns available to application at runtime
This is a performance enhancement feature. The framework provides the latest list of visible columns to the applications at run time and the applications in turn could do a selective fetch based on this info. For detailed information on this functionality please refer to document HowToReadonlyvisiblefieldsinPOWL.pdf also available in the enablement kit for NWBC – V1.30.
▪ Remote API Enablement of POWL
POWL framework provides a set of API's that enables usage and consolidation of feeders in different remote systems. Detailed information on this functionality is given in document HowToDevelopRemotePOWL.pdf also available in the enablement kit for NWBC – V1.30.
Description of the Feeder Interface
1 Description of the Feeder Interface IF_POWL_FEEDER
1 Method GET_ACTIONS
Purpose
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.
Parameters
|Importing |
|I_USERNAME |the user ID the current portal user is mapped to |
|I_APPLID |Application ID identifying the current POWL Iview |
|I_TYPE |the POWL type ID as registered |
|I_SELCRIT_PARA |current selection criteria assignments |
|I_LANGU |Language Key |
|Exporting |
|E_ACTIONS_CHANGED |In case none of the action definitions supplied to the Feeder via C_ACTION_DEFS had to|
| |be changed, you can leave this flag unset. Otherwise, you have to set it to 'X' (set |
| |if uncertain) |
|Changing |
|C_ACTION_DEFS |Supplies the current explicit action definitions for the query to the Feeder. |
For each action to be defined a record has to be added to table C_ACTION_DEFS. The following table describes the structure and meaning of such a record.
|Field name |Description |
|ACTIONID |Appropriate identifier for the action which can be referenced to in Method |
| |HANDLE_ACTION |
|CARDINALITY |Action dependency from selection cardinality |
| |S – At least one object has to be selected; I – Ignore selection (i.e. action |
| |is always active) |
|PLACEMENT |Placement |
| |B – Toolbar ; (C – Context menu [not supported yet]) |
|ENABLED |Flag: action enabled/ disabled |
|PLACEMENTINDX |Index of placement |
|IMAGESOURCE |Path to an action icon |
|TEXT |Action description text (e.g. button text) |
|TOOLTIP |Action tooltip |
|ADD_SEPARATOR |Flag to add a seperator after the action item |
|ACT_CHOICES |Action Choice |
[pic]
For labels or help texts it is recommended to define text elements (language dependency) instead of using static literals.
[pic] Example
The following example shows the GET_ACTIONS method of standard feeder class /KYK/CL_POWL_VENDOR. Three action buttons are added to the toolbar.
METHOD IF_POWL_FEEDER~GET_ACTIONS.
DATA:
lstru_action_def TYPE powl_actdescr_sty,
ltab_action_def TYPE powl_actdescr_tty.
DATA:
lref_my_badi TYPE REF TO badi_feeder_vendor,
l_bwconnected TYPE xflag.
FIELD-SYMBOLS:
TYPE powl_actdescr_sty.
* if first call add action definitions
IF c_action_defs IS INITIAL.
* display partner functions
lstru_action_def-actionid = 'DISPLAY'.
lstru_action_def-cardinality = c_feeder_action_sel_req.
lstru_action_def-placement = c_feeder_action_toolbar.
lstru_action_def-enabled = c_true.
lstru_action_def-placementindx = 1.
lstru_action_def-text = text-001.
lstru_action_def-add_separator = 'X'.
INSERT lstru_action_def INTO TABLE ltab_action_def.
* related info records
lstru_action_def-actionid = 'INFOREC'.
lstru_action_def-cardinality = c_feeder_action_sel_req.
lstru_action_def-placement = c_feeder_action_toolbar.
lstru_action_def-enabled = c_true.
lstru_action_def-placementindx = 2.
lstru_action_def-text = text-002.
lstru_action_def-add_separator = ''.
INSERT lstru_action_def INTO TABLE ltab_action_def.
* related agreements
lstru_action_def-actionid = 'AGREEMENTS'.
lstru_action_def-cardinality = c_feeder_action_sel_req.
lstru_action_def-placement = c_feeder_action_toolbar.
lstru_action_def-enabled = c_true.
lstru_action_def-placementindx = 3.
lstru_action_def-text = text-009.
INSERT lstru_action_def INTO TABLE ltab_action_def.
e_actions_changed = c_true.
c_action_defs = ltab_action_def.
ENDIF.
ENDMETHOD.
The constants used are defined in the private section of the class:
private section.
data M_CURRENT_VIEWTYPE type XCHAR .
data M_NEW_VIEWTYPE type XCHAR .
data MT_FIELDINFOS type DDFIELDS .
data MT_FIELDCATALOG type POWL_FIELDCAT_TTY .
data MT_CURRENT_SELCRIT_VALUES type RSPARAMS_TT .
data M_AUTH_CHECKED type XCHAR .
data M_AUTH_GRANTED type XCHAR .
constants C_TRUE type XFLAG value 'X'. "#EC NOTEXT
constants C_FEEDER_VIEWTYPE_PURCH type XCHAR value '2'. "#EC NOTEXT
constants C_FEEDER_VIEWTYPE_FIN type XCHAR value '3'. "#EC NOTEXT
constants C_FEEDER_VIEWTYPE_BASIC type XCHAR value '1'. "#EC NOTEXT
constants C_FEEDER_VIEWTYPE_TOTAL type XCHAR value '0'. "#EC NOTEXT
constants C_FALSE type XFLAG value ''. "#EC NOTEXT
constants C_FEEDER_SELCRIT_SELECT type XCHAR value 'S'. "#EC NOTEXT
constants C_FEEDER_SELTYPE_ALL type XCHAR value 'A'. "#EC NOTEXT
constants C_FEEDER_SELTYPE_INTER type XCHAR value 'I'. "#EC NOTEXT
constants C_FEEDER_SELTYPE_MULT type XCHAR value 'M'. "#EC NOTEXT
constants C_FEEDER_SELCRIT_PARAM type XCHAR value 'P'. "#EC NOTEXT
constants C_FEEDER_PARTYPE_INPUT type XCHAR value 'I'. "#EC NOTEXT
constants C_FEEDER_PARTYPE_DROP type XCHAR value 'D'. "#EC NOTEXT
constants C_FEEDER_PARTYPE_CHECKBOX type XCHAR value 'C'. "#EC NOTEXT
constants C_FEEDER_ACTION_SEL_REQ type XCHAR value 'S'. "#EC NOTEXT
constants C_FEEDER_ACTION_TOOLBAR type XCHAR value 'B'. "#EC NOTEXT
constants C_YES type XCHAR value 'Y'. "#EC NOTEXT
constants C_OBN_SYS_ALIAS_COMMON type STRING value 'SAP_ERP_Common'. "#EC NOTEXT
constants C_OBN_VENDOR type STRING value 'supplier'. "#EC NOTEXT
constants C_OBN_OP_PARTNER type STRING value 'dsppartfct'. "#EC NOTEXT
constants C_OBN_OP_DSPSRCOFSPLY type STRING value 'dspsrcofsply'. "#EC NOTEXT
constants C_SOS_USE_VEN type XCHAR value 'V'. "#EC NOTEXT
constants C_SOS_USE_MAT type XCHAR value 'M'. "#EC NOTEXT
constants C_BW_INFOBJ_GRP_VENDOR type STRING value '0GN_VENDOR__0CI_GRP_PAR'. "#EC NOTEXT
constants C_BW_INFOBJ_GEN_VENDOR type STRING value '0GN_VENDOR'. "#EC NOTEXT
constants C_OBN_OP_LAUNCHBW type STRING value 'launchbw'. "#EC NOTEXT
2 Method GET_ACTION_CONF
Purpose
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. The confirmation choice will be available in method HANDLE_ACTION via import parameter I_ACTION_CONF.
Parameters
|Importing |
|I_USERNAME |the user ID the current portal user is mapped to |
|I_APPLID |Application ID identifying the current POWL Iview |
|I_TYPE |the POWL type ID as registered |
|I_ACTIONID |Action identifier (defined in method GET_ACTIONS) |
|I_RESULT_TAB |the current query results (adhering to GET_OBJECT_DEFINITION) |
|I_SELECTED |the table line indices of the query results currently selected (i.e. marked) by the |
| |user |
|I_CHANGED |only relevant for editable query results table-- change information on those query |
| |results changed by the user since most recent enabling of POWL "dirty" state (c.f. |
| |HANDLE_ACTION for details) |
|I_ACTION_INDEX |result table line index for cell-based actions |
|I_LANGU |Language Key |
|Exporting |
|E_CONF_MESSAGE |the confirmation message to be displayed before actual execution of the action |
| |identified by I_ACTIONID |
[pic] Example
The following example exemplarily shows a simple message to be shown before object deletion. The action must be defined in GET_ACTIONS.
method IF_POWL_FEEDER~GET_ACTION_CONF.
data: l_test LIKE LINE OF E_CONF_MESSAGE.
CASE i_actionid.
WHEN ‘DELETE’.
l_test = ‘Really delete selected lines?’.
Insert l_test into table e_conf_message.
WHEN OTHERS.
Return.
3 Method GET_SEL_CRITERIA
Purpose
With this method you can define which selection criteria are 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.
Parameters
|Importing |
|I_USERNAME |the user ID the current portal user is mapped to |
|I_APPLID |Application ID identifying the current POWL Iview |
|I_TYPE |the POWL type ID as registered |
|I_LANGU |Language Key |
|Exporting |
|E_SELCRIT_DEFS_CHANGED |If none of the selection criteria definitions supplied to the Feeder via |
| |C_SELCRIT_DEFS had to be changed, you can leave this flag unset. Otherwise, you have |
| |to set it to 'X'. (set if uncertain) |
|E_DEFAULT_VAL_CHANGED |If none of the selection criteria default values supplied to the Feeder via |
| |C_DEFAULT_VALUES had to be changed, you can leave this flag unset. Otherwise, you have|
| |to set it to 'X'. (set if uncertain) |
|Changing |
|C_SELCRIT_DEFS |Selection criteria meta description. Supplies the current selection criteria |
| |definitions to the Feeder. Note that selection criteria definitions are cached on |
| |database upon query refresh |
|C_DEFAULT_VALUES |Default values for selection criteria. Supplies the current selection criteria default|
| |values to the Feeder. Note that selection criteria default values are cached on |
| |database upon each query refresh. |
For each selection criterion a record has to be added to table C_SELCRIT_DEFS in order to specify the UI-properties of the respective field. The following table describes the structure and meaning of such a record.
|Field name |Description |
|SELNAME |ID of the selection criterion |
|KIND |Specifies, if the criterion allows single or multi value range. |
| |Allowed values are P and S. P stands for Parameter and defines a single value |
| |input, S stands for Select option and provides a multi value input resp. |
| |intervals. |
|PARAM_TYPE |Display type for simple parameters |
| |I – Input field, C – Checkbox, D – dropdown list, T - textline |
|SELOPT_TYPE |Criteria type for select options (in case KIND = S) |
| |A - Select-option with interval and multi-selection, I - Select-option without |
| |multiselect; M - Select-option without interval |
|ALLOW_ADMIN_CHANGE |This flag can be set to allow the change of properties MANDATORY, READ_ONLY and|
| |HIDDEN, manually (Transaction POWL_QUERY). Otherwise the settings specified in |
| |the coding cannot be overridden. |
|MANDATORY |Flag to set the field mandatory in the UI: X – flag is set, empty means unset. |
|READ_ONLY |Flag to set the field readonly in the UI: X – flag is set, empty means unset. |
|HIDDEN |Flag to set the field hidden in the UI: X – flag is set, empty means unset. |
|QUICKSEARCH_CRIT |This flag determines if the criterion will be available as Quick Search |
| |criterion: X – flag is set, empty means unset. |
|DATATYPE |Datatype Name |
|REF_TABLE |Name of the DDIC reference |
|REF_FIELD |Name of the specific field in the reference table. |
|OUTPUTLEN |Output length |
|CRITTEXT |Field label of the criterion |
|TOOLTIP |Tooltip for the criterion |
|HEADER |Additional headline for the criterion. If no header is specified the criterion |
| |will be grouped under the same header as the preceding criterion. |
|OVS_HANDLER_NAME |OVS handler class for own input help (must implement interface IF_POWL_OVS). |
| |Can be omitted if standard is used. |
|VALID_VALUES |By specifying this parameter a validation check for the input can be defined. |
| |The underlying type POWL_NAMEVALUE_TTY requires data in form of Key/Value – |
| |pairs. |
|DDIC_SHLP |Name of the DDIC search help. Can be omitted in case the default help is to be |
| |used. |
|DECIMALS |Decimals for selcrits |
The example below shows exemplarily how the table C_SELCRIT_DEFS is to be used in this method.
[pic]
For labels or help texts like CRITTEXT, TOOLTIP etc. it is recommended to define text elements (language dependency) instead of using static literals.
In this method it is also possible to define default values for the selection criteria (or for a subset of them). The default values have to be added to table C_DEFAULT_VALUES; a relation between the value and the corresponding criterion is established via field SELNAME.
|Field name |Description |
|SELNAME |ID of the selection criterion |
|KIND |Specifies, if the criterion allows single or multi value range. |
| |Allowd values are P and S. P stands for Parameter and defines a single value |
| |input, S stands for Select option and provides a multi value input resp. |
| |intervals |
|SIGN |Sign before a criterion |
| |I – include values, E – exclude values |
|OPTION |Selection option |
| |EQ – equal, GE – greater or equal, GT – greater , LE – less or equal, LT- less,|
| |NE – not equal |
|LOW |LOW value |
|HIGH |HIGH value |
[pic] Example
The following example shows the GET_SEL_CRITERIA method of standard feeder class /KYK/CL_MM_POWL_VENDOR_LIST. The two selection criteria ‘Vendor’ and ‘Purchasing Organization’ are defined as Input fields (param_type = I) without multiselect (selopt_type = I). Criterion S_LIFNR (Vendor) uses reference field LIFNR (Account Number) of table LFA1 (Vendor Master); criterion S_EKORG (Purchasing Organization) uses reference field EKORG (Purchasing Organization) of table T024E (Purchasing Organizations)
METHOD if_powl_feeder~get_sel_criteria.
* define selection criteria available for this feeder
* in this case corresponding to report ERPSLS_CUSTOMERS
* fill private object attribut MT_SELCRITERIA & MT_CRITERIA_DEFAULT
DATA: ls_selcrit TYPE powl_selcrit_sty,
ls_criteria_default TYPE rsparams.
IF mt_selcriteria IS INITIAL.
* LFA1-LIFNR
CLEAR ls_selcrit.
ls_selcrit-selname = 'S_LIFNR'.
ls_selcrit-kind = 'S'. " select option
ls_selcrit-param_type = 'I'. " input field
ls_selcrit-selopt_type = 'I'. "M & I " Select-option with interval and multi-selection
ls_selcrit-quicksearch_crit = 'X'.
ls_selcrit-datatype = 'LIFNR'.
ls_selcrit-ref_table = 'LFA1'.
ls_selcrit-ref_field = 'LIFNR'.
ls_selcrit-ddic_shlp = 'KRED_C'.
ls_selcrit-allow_admin_change = 'X'.
APPEND ls_selcrit TO mt_selcriteria.
* -----------------------------------
* RF02K-EKORG
* -----------------------------------
CLEAR ls_selcrit.
ls_selcrit-selname = 'S_EKORG'.
ls_selcrit-kind = 'S'. " select option
ls_selcrit-param_type = 'I'. " input field
ls_selcrit-selopt_type = 'I'. "A, M & I " Select-option with interval and multi-selection
ls_selcrit-quicksearch_crit = 'X'.
ls_selcrit-ref_table = 'T024E'.
ls_selcrit-ref_field = 'EKORG'.
ls_selcrit-ddic_shlp = 'H_T024E'.
ls_selcrit-allow_admin_change = 'X'.
APPEND ls_selcrit TO mt_selcriteria.
e_selcrit_defs_changed = 'X'.
e_default_val_changed = 'X'.
c_selcrit_defs = mt_selcriteria.
c_default_values = mt_criteria_default.
ELSE.
c_selcrit_defs = mt_selcriteria.
c_default_values = mt_criteria_default.
e_selcrit_defs_changed = 'X'.
ENDIF.
CLEAR c_default_values.
ENDMETHOD.
Parameters mt_selcriteria and mt_criteria_default are defined in the private section of the class:
private section.
types:
BEGIN OF ty_ls_vendor,
BUKRS TYPE BUKRS,
SPERR TYPE SPERB_B,
LOEVM TYPE LOEVM_B,
ZTERM TYPE DZTERM.
INCLUDE TYPE /kyk/v_lfa1m1.
TYPES END OF ty_ls_vendor .
types:
ty_lt_vendor TYPE STANDARD TABLE OF ty_ls_vendor .
types:
BEGIN OF ty_ls_seltab,
sign TYPE char1,
option TYPE char2,
low TYPE char40,
high TYPE char40,
END OF ty_ls_seltab .
types:
ty_lt_seltab TYPE STANDARD TABLE OF ty_ls_seltab .
constants GC_ACTION_DISPLAY type POWL_ACTIONID_TY value 'ANZ'. "#EC NOTEXT
constants GC_ACTION_EDIT type POWL_ACTIONID_TY value 'AEN'. "#EC NOTEXT
constants GC_ACTION_CREATE type POWL_ACTIONID_TY value 'ANL'. "#EC NOTEXT
constants GC_ACTION_CREATE_REF type POWL_ACTIONID_TY value 'REF'. "#EC NOTEXT
constants GC_ACTION_EXTEND type POWL_ACTIONID_TY value 'EXT'. "#EC NOTEXT
constants GC_ACTION_DELETE type POWL_ACTIONID_TY value 'DEL'. "#EC NOTEXT
data MT_ACTIONS type POWL_ACTDESCR_TTY .
data MT_SELCRITERIA type POWL_SELCRIT_TTY .
data MT_FIELDCAT type POWL_FIELDCAT_TTY .
data MT_CRITERIA_DEFAULT type RSPARAMS_TT .
data MT_RESULT type TY_LT_VENDOR .
4 Method GET_FIELD_CATALOG
Purpose
This method describes the field catalog to be used for query results table and the UI properties of the particular fields.
Parameters
|Importing |
|I_USERNAME |the user ID the current portal user is mapped to |
|I_APPLID |Application ID identifying the current POWL Iview |
|I_TYPE |the POWL type ID as registered |
|I_LANGU |Language Key |
|I_SELCRIT_VALUES |the selection criteria values of the current query |
|Exporting |
|E_FIELDCAT_CHANGED |Flag: catalog in C_FIELDCAT changed (set if uncertain) |
|E_VISIBLE_COLS_COUNT |number of concurrently visible table columns |
|E_VISIBLE_ROWS_COUNT |number of concurrently visible table rows |
|Changing |
|C_FIELDCAT |supplies the current field catalog to the Feeder. |
Each entry in the field catalog is a reference to one column of the actual (internal) query results table as delivered by GET_OBJECTS and defines the rendering of this column. The set of available columns is defined by GET_OBJECT_DEFINITION. Note that each internal results column not referenced by a field catalog entry will be rendered as text view per default.
There are passive cell renderers (as text views, input fields or checkboxes) and active ones (button and link to action). If the user clicks on a table cell with active cell renderer, this will trigger a call of HANDLE_ACTION, supplying the column ID as action ID. Such actions are defined as "implicit actions". (Therefore, the column IDs in the field catalog and the action IDs receivable by HANDLE_ACTION have the same domain).
Note that the field catalog is cached on database upon each queryrefresh. exporting E_FIELDCAT_CHANGED: if none of the field catalog entries supplied to the Feeder via C_FIELDCAT had to be changed, you can leave this flag unset. Otherwise, you have to set it to 'X'.
Parameter C_FIELDCAT determines the cell renderer for each outtab column. The following table describes the properties that can be set via C_FIELDCAT. For several of the properties shown below, there are two different ways to specify their behavior: either a static value is provided, which applies for the whole column, or a reference to a different column (normally a technical column) is specified; in the latter case the behavior of the specific cell is determined by the cell-value of the corresponding reference column (e.g. TEXT as static text and TEXT_REF as reference to different column).
|Field name |Description |
|COLID |Unique reference to the column (defined in method GET_OBJECT_DEFINITION) |
|COLPOS |Position of the column within the output grid |
|WIDTH |Output length of the field |
|HEADER |Column header text |
|HEADER_BY_DDIC |Use header text from DDIC |
|DISPLAY_TYPE |Display style for the column |
| |TV – textview; IM – image; CK – checkbox; DK - dropdown by key; IN - input |
| |field; LU - link to url; LA - link to action; BT – button; PI - progress |
| |indicator |
|H_ALIGN |Output justification |
| |L- Left; C – Center; R – Right |
|FIXED |The fixed columns will always be displayed in the ALV (even if you reduce the |
| |number of displayed columns in the layout settings; this restricts only the |
| |unfixed columns). The ALV builds a block with the fixed and one with the |
| |unfixed columns (the fixed columns will always be shown as first in the table).|
|TEXT |Static Text |
|TEXT_REF |Outtab column reference determining text |
|EDITABLE |Flag to set the column editable |
|EDITABLE_REF |Outtab column reference determining cell editability |
|WRAPPING |Text wrapping is enabled |
|WRAPPING_REF |outtab column reference determining textual wrapping |
|ICON_SRC |Source for icon display |
|ICON_SRC_REF |outtab column reference determining icon source |
|ICON_FIRST |Icon positioning |
|ICON_FIRST_REF |outtab column reference for icon positioning |
|CBOX_CHECK |Checkbox state |
|CBOX_CHECK_REF |outtab column reference determining checkbox state |
|COL_VISIBLE |Outtab column is visible |
|TECHNICAL_COL |Flag to specify the column as a technical column. The column is invisible but |
| |in contrast to a ‘hidden’ column it is not available via user settings. |
|ENABLED |Flag to enable the column |
|ENABLED_REF |outtab column reference determining enabled status |
|TOOLTIP |Tooltip Text |
|TOOLTIP_REF |outtab column reference determining tooltip |
|ALLOW_FILTER |Outtab column can be used as filter |
|ALLOW_SORT |Sort is allowed for the outtab column |
|CQ |Type of CQ_REF field |
| |C – currency, Q – Quantity |
|CQ_REF |outtab column reference for currency/quantity |
|SORT_REF |Outtab column reference determining sort order index |
|FILTER_REF |outtab column reference containing filter value |
|OVS_HANDLER_NAME |OVS handler class for own input help (must implement interface IF_POWL_OVS). |
| |Can be omitted if standard is used. |
|VALID_VALUES |By specifying this parameter a validation check for the input can be defined. |
| |The underlying type POWL_NAMEVALUE_TTY requires data in form of Key/Value – |
| |pairs |
|DDIC_SHLP |Name of the DDIC search help. Can be omitted in case the default help is to be |
| |used |
|PROGR_PERCENT |Percentage of progress indicator |
|PROGR_PERCENT_REF |outtab column reference determining progress percentage |
|COLOR |Semantic column color 0 to 19 |
|COLOR_REF |outtab column reference for cell color |
|SET_NULL |Flag to set cell value to null |
|SET_NULL_REF |outtab column reference for setting cell value to null |
[pic] Example
The following example shows the GET_FIELD_CATALOG method of standard feeder class /KYK/CL_MM_POWL_VENDOR_LIST. Column MANDT (Client) is defined as a hidden column (col_visible = ‘ ’); during runtime it will be available in the Setting-dialog of the POWER List within the UI.
METHOD if_powl_feeder~get_field_catalog.
* define field catalog corresponding to MT_RESULT !!
* COLID = corresponding field in MT_RESULT structure type definition !
* ( see method 'get_object_definition')
* 'REF'-attributes the same .....
DATA: ls_fieldcat TYPE powl_fieldcat_sty,
ls_dfies TYPE dfies,
ls_fcat TYPE lvc_s_fcat,
l_seqnr TYPE int4.
DEFINE add_colpos.
add 1 to l_seqnr.
ls_fieldcat-colpos = l_seqnr.
END-OF-DEFINITION.
CASE i_type .
WHEN 'KYK_FI_VENDOR_LIST_AP'.
WHEN 'KYK_FI_VENDOR_LIST_MM'.
WHEN OTHERS.
ENDCASE.
IF mt_fieldcat IS INITIAL.
* 1. MANDT
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'MANDT'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = 'X'.
ls_fieldcat-h_align = 'L'.
* ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = ' '.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 5.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
* 1. LIFNR
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'LIFNR'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = 'X'.
ls_fieldcat-h_align = 'L'.
* ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 5.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
* 2. EKORG
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'EKORG'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = 'X'.
ls_fieldcat-h_align = 'L'.
* ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 5.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
* 3. NAME1
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'NAME1'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = 'X'.
ls_fieldcat-h_align = 'L'.
ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 10.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
* 4. LAND1
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'LAND1'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = 'X'.
ls_fieldcat-h_align = 'L'.
ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 10.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
* 5. ORT01
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'ORT01'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = 'X'.
ls_fieldcat-h_align = 'L'.
ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 5.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
* 8. TELF1
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'TELF1'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = 'X'.
ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 5.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
* 5. MCOD1
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'MCOD1'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = 'X'.
ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 30.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
* 6. INCO1
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'INCO1'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = ' '.
ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 30.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
*
* 7. VERKF
CLEAR ls_fieldcat.
ls_fieldcat-colid = 'VERKF'.
add_colpos.
ls_fieldcat-header_by_ddic = 'X'.
ls_fieldcat-fixed = ' '.
ls_fieldcat-allow_sort = 'X'.
ls_fieldcat-col_visible = 'X'.
ls_fieldcat-editable = ' '.
ls_fieldcat-width = 5.
INSERT ls_fieldcat INTO TABLE mt_fieldcat.
e_visible_cols_count = 11.
e_fieldcat_changed = 'X'.
c_fieldcat = mt_fieldcat.
ELSE.
c_fieldcat = mt_fieldcat.
ENDIF.
*
*
ENDMETHOD.
Parameter mt_fieldcat is defined in the private section of the class:
private section.
types:
BEGIN OF ty_ls_vendor,
BUKRS TYPE BUKRS,
SPERR TYPE SPERB_B,
LOEVM TYPE LOEVM_B,
ZTERM TYPE DZTERM.
INCLUDE TYPE /kyk/v_lfa1m1.
TYPES END OF ty_ls_vendor .
types:
ty_lt_vendor TYPE STANDARD TABLE OF ty_ls_vendor .
types:
BEGIN OF ty_ls_seltab,
sign TYPE char1,
option TYPE char2,
low TYPE char40,
high TYPE char40,
END OF ty_ls_seltab .
types:
ty_lt_seltab TYPE STANDARD TABLE OF ty_ls_seltab .
constants GC_ACTION_DISPLAY type POWL_ACTIONID_TY value 'ANZ'. "#EC NOTEXT
constants GC_ACTION_EDIT type POWL_ACTIONID_TY value 'AEN'. "#EC NOTEXT
constants GC_ACTION_CREATE type POWL_ACTIONID_TY value 'ANL'. "#EC NOTEXT
constants GC_ACTION_CREATE_REF type POWL_ACTIONID_TY value 'REF'. "#EC NOTEXT
constants GC_ACTION_EXTEND type POWL_ACTIONID_TY value 'EXT'. "#EC NOTEXT
constants GC_ACTION_DELETE type POWL_ACTIONID_TY value 'DEL'. "#EC NOTEXT
data MT_ACTIONS type POWL_ACTDESCR_TTY .
data MT_SELCRITERIA type POWL_SELCRIT_TTY .
data MT_FIELDCAT type POWL_FIELDCAT_TTY .
data MT_CRITERIA_DEFAULT type RSPARAMS_TT .
data MT_RESULT type TY_LT_VENDOR .
5 Method GET_OBJECT_DEFINITION
Purpose
Define 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.
(defines the datatype of the actual (internal) query results table as to be delivered by GET_OBJECTS)
Parameters
|Importing |
|I_TYPE |the POWL type ID as registered |
|I_LANGU |Language Key |
|Exporting |
|E_OBJECT_DEF |The table type definition of the actual (internal) query results table as instance|
| |of CL_ABAP_TABLEDESCR. |
[pic] Example
The following example shows the GET_OBJECT_DEFINITION method of standard feeder class /KYK/CL_MM_POWL_VENDOR_LIST. Method descibe_by_data of class cl_abap_tabledesc is an easy way to assign the type definition to export parameter E_OBJECT_DEF.
METHOD if_powl_feeder~get_object_definition.
* return the table type description for the private object attribute MT_RESULT
e_object_def ?= cl_abap_tabledescr=>describe_by_data( mt_result ).
ENDMETHOD.
Parameter mt_result is defined in the private section of the class:
private section.
types:
BEGIN OF ty_ls_vendor,
BUKRS TYPE BUKRS,
SPERR TYPE SPERB_B,
LOEVM TYPE LOEVM_B,
ZTERM TYPE DZTERM.
INCLUDE TYPE /kyk/v_lfa1m1.
TYPES END OF ty_ls_vendor .
types:
ty_lt_vendor TYPE STANDARD TABLE OF ty_ls_vendor .
types:
BEGIN OF ty_ls_seltab,
sign TYPE char1,
option TYPE char2,
low TYPE char40,
high TYPE char40,
END OF ty_ls_seltab .
types:
ty_lt_seltab TYPE STANDARD TABLE OF ty_ls_seltab .
constants GC_ACTION_DISPLAY type POWL_ACTIONID_TY value 'ANZ'. "#EC NOTEXT
constants GC_ACTION_EDIT type POWL_ACTIONID_TY value 'AEN'. "#EC NOTEXT
constants GC_ACTION_CREATE type POWL_ACTIONID_TY value 'ANL'. "#EC NOTEXT
constants GC_ACTION_CREATE_REF type POWL_ACTIONID_TY value 'REF'. "#EC NOTEXT
constants GC_ACTION_EXTEND type POWL_ACTIONID_TY value 'EXT'. "#EC NOTEXT
constants GC_ACTION_DELETE type POWL_ACTIONID_TY value 'DEL'. "#EC NOTEXT
data MT_ACTIONS type POWL_ACTDESCR_TTY .
data MT_SELCRITERIA type POWL_SELCRIT_TTY .
data MT_FIELDCAT type POWL_FIELDCAT_TTY .
data MT_CRITERIA_DEFAULT type RSPARAMS_TT .
data MT_RESULT type TY_LT_VENDOR .
6 Method GET_OBJECTS
Purpose
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.
(This method is responsible for the actual query execution and delivery of the query results table which must adhere to the type definition given by GET_OBJECT_DEFINITION)
Parameters
|Importing |
|I_USERNAME |the user ID the current portal user is mapped to |
|I_APPLID |Application ID identifying the current POWL Iview |
|I_TYPE |the POWL type ID as registered |
|I_LANGU |Language Key |
|I_SELCRIT_VALUES |the selection criteria values of the current query |
|Exporting |
|E_RESULTS |the actual query results for the criteria values supplied to the Feeder via |
| |I_SELCRIT_VALUES [selection result table (c.f GET_OBJECT_DEFINITION)] |
|E_MESSAGES |messages that occured during query execution/results determination and are to be |
| |displayed to the user |
[pic] Example
The following example shows the GET_OBJECTS method of standard feeder class /KYK/CL_MM_POWL_VENDOR_LIST. The data retrieval is performed via a SELECT-statement on tables /KYK/V_LFA1M1 (Vendor List for Purchasing Organisation) and /KYK/V_LFA1B1 (Vendor List for Comapany). Please note how the import parameter i_selcrit_values is used to build lt_seltab_lifnr and lt_seltab_ekorg for the WHERE-clause of the selection.
METHOD IF_POWL_FEEDER~GET_OBJECTS.
* select objects with criteria from i_selcrit_values
* selname was defined in method get_sel_criteria
DATA: lt_selcrit TYPE rsparams_tt,
ls_selcrit TYPE rsparams.
DATA: ls_seltab_lifnr TYPE ty_ls_seltab,
lt_seltab_lifnr TYPE ty_lt_seltab,
ls_seltab_bukrs TYPE ty_ls_seltab,
lt_seltab_bukrs TYPE ty_lt_seltab,
ls_seltab_ekorg TYPE ty_ls_seltab,
lt_seltab_ekorg TYPE ty_lt_seltab.
DATA: lt_lfa1m1 TYPE ty_lt_vendor,
lt_result TYPE ty_lt_vendor,
ls_result TYPE ty_ls_vendor.
FIELD-SYMBOLS: TYPE ty_ls_vendor.
LOOP AT i_selcrit_values INTO ls_selcrit.
CASE ls_selcrit-selname.
WHEN 'S_LIFNR'.
ls_seltab_lifnr-sign = ls_selcrit-sign. "'I'.
ls_seltab_lifnr-option = ls_selcrit-option. "'BT'.
ls_seltab_lifnr-low = ls_selcrit-low.
ls_seltab_lifnr-high = ls_selcrit-high.
APPEND ls_seltab_lifnr TO lt_seltab_lifnr.
WHEN 'S_EKORG'.
ls_seltab_ekorg-sign = ls_selcrit-sign. "'I'.
ls_seltab_ekorg-option = ls_selcrit-option. "'BT'.
ls_seltab_ekorg-low = ls_selcrit-low.
ls_seltab_ekorg-high = ls_selcrit-high.
APPEND ls_seltab_ekorg TO lt_seltab_ekorg.
ENDCASE.
ENDLOOP.
SELECT * FROM /kyk/v_lfa1m1 AS m1 INNER JOIN /kyk/v_lfa1b1 AS b1 ON
m1~mandt = b1~mandt
AND m1~lifnr = b1~lifnr
INTO CORRESPONDING FIELDS OF TABLE lt_lfa1m1 WHERE m1~lifnr IN lt_seltab_lifnr
AND m1~ekorg IN lt_seltab_ekorg.
LOOP AT lt_lfa1m1 ASSIGNING .
MOVE-CORRESPONDING TO ls_result.
INSERT ls_result INTO TABLE me->mt_result.
ENDLOOP.
e_results = me->mt_result.
ENDMETHOD.
Following type definitions are assumed in the attributes section of the class:
private section.
types:
BEGIN OF ty_ls_vendor,
BUKRS TYPE BUKRS,
SPERR TYPE SPERB_B,
LOEVM TYPE LOEVM_B,
ZTERM TYPE DZTERM.
INCLUDE TYPE /kyk/v_lfa1m1.
TYPES END OF ty_ls_vendor .
types:
ty_lt_vendor TYPE STANDARD TABLE OF ty_ls_vendor .
types:
BEGIN OF ty_ls_seltab,
sign TYPE char1,
option TYPE char2,
low TYPE char40,
high TYPE char40,
END OF ty_ls_seltab .
types:
ty_lt_seltab TYPE STANDARD TABLE OF ty_ls_seltab .
constants GC_ACTION_DISPLAY type POWL_ACTIONID_TY value 'ANZ'. "#EC NOTEXT
constants GC_ACTION_EDIT type POWL_ACTIONID_TY value 'AEN'. "#EC NOTEXT
constants GC_ACTION_CREATE type POWL_ACTIONID_TY value 'ANL'. "#EC NOTEXT
constants GC_ACTION_CREATE_REF type POWL_ACTIONID_TY value 'REF'. "#EC NOTEXT
constants GC_ACTION_EXTEND type POWL_ACTIONID_TY value 'EXT'. "#EC NOTEXT
constants GC_ACTION_DELETE type POWL_ACTIONID_TY value 'DEL'. "#EC NOTEXT
data MT_ACTIONS type POWL_ACTDESCR_TTY .
data MT_SELCRITERIA type POWL_SELCRIT_TTY .
data MT_FIELDCAT type POWL_FIELDCAT_TTY .
data MT_CRITERIA_DEFAULT type RSPARAMS_TT .
data MT_RESULT type TY_LT_VENDOR .
7 Method GET_DETAIL_COMP
Purpose
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.
(Optionally, custom details can be displayed for one query result at a time. If this is desired, this method has to deliver the necessary meta information to the POWL.)
Parameters
|Importing |
|I_USERNAME |the user ID the current portal user is mapped to |
|I_APPLID |Application ID identifying the current POWL Iview |
|I_TYPE |the POWL type ID as registered |
|I_LANGU |Language Key |
|Exporting |
|E_DETAIL_COMP |the name of a Web Dynpro Component which implements the component interface |
| |IWCI_POWL_DETAIL_COMP_IF. This component will be instantiated at runtime and has |
| |to manage the actual details display; the respective "master result" data |
| |(adhering to GET_OBJECT_DEFINITION) will be supplied by the POWL to the detail |
| |component via method UPDATE_DETAIL_DATA as defined in IWCI_POWL_DETAIL_COMP_IF. |
|E_DETAIL_TYPE |Detail type ID (to be supplied if POWL_TABLE_COMP is used) |
If you don't want to display result details, just leave this parameter blank.
Use
The following steps have to be performed to create a POWER List detail Component
Procedure
1. Create a WebDynpro ABAP component
2. Implement the WebDynpro ABAP component Interface 'POWL_DETAIL_COMP_IF'
3. This Interface contains the following methods and events:
Methods:
'UPDATE_DETAIL_DATA' implement this method in order to receive the DATA reference of the POWL lead selection Parameter - 'I_POWL_LINE_DATA' type ref to DATA
Events:
'DO_REFRESH' fire this event from your detail component when you need the POWL query refreshed
'POWL_FOLLOW_UP' use this event to pass 'something' to the 'POWL_UI_COMP' event 'POWL_FOLLOW_UP'. This makes only sense when the POWL is embedded into another WD ABAP component. Parameters: 'ADD_EVENT_DATA' type ref to DATA 'EVENT_PARAMETERS' type POWL_NAMEVALUE_TTY
4. create your 'custom' detail Views (WD ABAP)
5. insert your views into the interface window 'POWL_DETAIL'
6. pass the name of the above created WD component through your feeder class method 'GET_DETAIL_COMP' using the parameter 'E_DETAIL_COMP'
Hint: as the POWL query data is cached it makes sense to have the detailed data also cached (synchronous) e.g. nested table structure in your POWL line data
8 Method HANDLE_ACTION
Purpose
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.
Parameters
|Importing |
|I_USERNAME |the user ID the current portal user is mapped to |
|I_APPLID |Application ID identifying the current POWL Iview |
|I_TYPE |the POWL type ID as registered |
|I_LANGU |Language Key |
|I_ACTIONID |Action identifier; the ID of the action triggered by the user (i.e. either the ID |
| |of one of the explicit actions as defined by GET_ACTIONS or the results table |
| |column ID of an implicit action as defined by the field catalog by an active cell |
| |renderer). |
|I_CHANGED |--only relevant for editable query results table-- change information on those |
| |query results changed by the user since most recent enabling of POWL "dirty" |
| |state.; outtab change infos (changes by the user) for Feeder |
|I_ACTION_INDEX |in case an implicit action, this parameter will supply the results table line |
| |index where the action was triggered to the Feeder.; result table line index for |
| |cell-based actions |
|I_ACTION_CONF |in case there was an action confirmation message defined by GET_ACTION_CONF, this |
| |parameter supplies the confirmation result (i.e. Y for Yes or N for No) to the |
| |Feeder. The default value (which is also supplied in case there was no |
| |confirmation message) is Yes.; action confirmation result (c.f. |
| |GET_ACTION_CONFIRMATION) |
| | |
| |Y - Yes (Execute action (default)) |
| |N - No (Don't execute action) |
|Exporting |
|E_MESSAGES |messages to be displayed to the user |
|E_DO_REFRESH |if this flag is set, a refresh of the query will be enforced upon the |
| |HANDLE_ACTION call.; trigger a complete query refresh |
|E_RESULT_LINES_CHANGED |if none of the results supplied to the Feeder via C_RESULTS had to be changed, you|
| |can leave this flag unset. Otherwise, you have to set it to 'X'.; result table |
| |C_RESULTS changed (set if uncertain) |
|E_CHANGES_PROCESSED |--only relevant for editable query results table-- if all results changes done by |
| |the user have been processed by the Feeder, you can set this flag to 'X' in order |
| |to tell the POWL to suppress data loss confirmation messages (like "Unsaved data |
| |will be lost. Continue?"), i.e. to reset the POWL "dirty state". A typical action |
| |which would set this flag is something like "Save data".; user changes processed |
| |by Feeder (reset POWL "dirty" state) |
|E_SELECTED_CHANGED |if none of the selected result line indices supplied to the Feeder via C_SELECTED |
| |had to be changed, you can leave this flag unset. Otherwise, you have to set it to|
| |'X'.; selected results in C_SELECTED changed by Feeder |
|E_ACTIONS_CHANGED |if none of the action definitions supplied to the Feeder via C_ACTION_DEFS had to |
| |be changed, you can leave this flag unset. Otherwise, you have to set it to 'X'.; |
| |flag: actions in C_ACTION_DEFS changed (set if uncertain) |
|E_PORTAL_ACTIONS |Supplies a portal action to be performed upon the HANDLE_ACTION call. Currently, |
| |the following portal actions are supported: |
| |Absolute navigation: just set the component PORTAL_PATH to the respective |
| |navigation target. Note that all parameters supplied in component PARAMETERS will |
| |be transported as URL-encoded value string of URL parameter 'DynamicParameter'. |
| |Object based navigation: all components with prefix BO_ are to be filled according|
| |to the business object operation to be triggered. If you want to fire the default |
| |operation of the resp. business object, you may omit the component BO_OP_NAME. |
| |Portal client-side event: all components with prefix CS_ have to be filled |
| |accordingly. |
|Changing |
|C_SELECTED |supplies the indices of all results table lines selected/marked by the user to the|
| |Feeder. The first entry of this table corresponds to the lead selection index.; |
| |result table indices of selected results. |
|C_RESULT_TAB |supplies the current query results table (including all changes done by the user |
| |if the results table is editable) to the Feeder.; current result table (adhering |
| |to GET_OBJECT_DEFINITION) |
|C_ACTION_DEFS |supplies the current explicit action definitions for the query to the Feeder.; |
| |POWL action definitions |
|C_FIRST_VISIBLE_ROW |supplies the index of the first visible results table row to the Feeder (i.e. the |
| |current scroll position of the results table). Normally, you will only have to |
| |adapt this index if result table lines were added and/or deleted.; index of first |
| |visible results table row |
|C_FIRST_VISIBLE_SCROLL_COL |Name of first scrollable column |
For each action defined in method GET_ACTIONS a record has to be added to table E_PORTAL_ACTION. The following table describes the structure and meaning of such a record. Please note that the respective ACTIONID to be handled is passed via parameter I_ACTIONID.
|Field name |Description |
|PORTAL_PATH |Path for absolute portal navigation to fix target (not to be used in A1N) |
|PORTAL_NAV_MODE |Navigation mode |
| |valid values: IF_WD_PORTAL_INTEGRATION=>CO_SHOW_ |
| |(not to be used in A1N) |
|BO_SYSTEM |System alias for Object Base Navigation (OBN) |
|BO_NAME |Name of OBN business object |
|BO_OP_NAME |Name of an operation of the specified business object |
|BO_RESOLVE_MODE |Scope of role resolution: USER_SET_OF_ROLES, SOURCE_ROLE |
|CS_EVENT_NAMESPACE |Client side event name space |
|CS_EVENT |Name of a client side event |
|PARAMETERS |Name/Value set |
|FIRE_WDEVENT |For wrapped POWL feeder classes to fire the event outwards. |
|ADD_WDEVENT_DATA |Additional data for the event |
[pic] Example
The following example shows the HANDLE_ACTION method of standard feeder class /KYK/CL_SLS_LIST_CUSTOMERS_FI. Here it should become clear, how Business Objects are used for OBN navigation. Via ls_portal_actions-bo_name the specific Business Object is specified, via ls_portal_actions-bo_op_name the Business Object-method.The (ls_namevalue-key , ls_namevalue-value)pairs provide the particular Business Object –parameters with values, respectively.
[pic] It is important to note that the OBN navigation requires an appropriate ‘Transaction assignment’ for the specific role (via transaction PFCG). That way the connection between the Business Object-method and the transaction to be executed is established - furthermore the mapping between the Business Object-parameters and the screen fields.
For example the handling of action ‘CHAN’ returns Business Object 'KYK_CUSTOMER_BLOCK' and its method 'Change' via parameter E_PORTAL_ACTION.
Now, let’s have a look at the menu entry Customers of role SAP_AIO_SALESPERSON-S, where a POWER List based on the relevant feeder is assigned.
[pic]
Due to our considerations regarding OBN-navigation there must be a transaction within the menu folder, which is executed whenever method HANDLE_ACTION returns ‘KYK_CUSTOMER_BLOCK.Change’ via E_PORTAL_ACTION-bo_name and E_PORTAL_ACTION-bo_op_name.
Entry XD02 fulfills this requirement; via Additional Details from the Context Menu it can be verified that method ‘KYK_CUSTOMER_BLOCK.Change’ is specified. Furthermore we can see, how the parameters are mapped to the particular screen fields of transaction screen XD02:
RF02D-KUNNR={Customer}&RF02D-BUKRS={Company_Code}&RF02D-VTWEG={Distribution_Channel}&RF02D-SPART={Division}&RF02D-VKORG={Sales_Organization}
method if_powl_feeder~handle_action .
data:
ls_portal_actions type powl_follow_up_sty,
ls_namevalue type powl_namevalue_sty,
lv_lines type i.
field-symbols:
like line of me->mt_result,
type rstabix.
clear:
e_portal_actions,
e_messages,
e_do_refresh,
e_result_lines_changed,
e_changes_processed,
e_selected_changed,
e_actions_changed.
* handle actions defined in method 'get_actions'
ls_portal_actions-bo_system = space.
ls_portal_actions-bo_name = 'KYK_CUSTOMER_BLOCK'.
describe table c_selected lines lv_lines.
check lv_lines = 1. ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
read table c_selected assigning index 1.
read table c_result_tab assigning index -tabix.
case i_actionid.
when 'DISP' or 'CHAN' or 'AACC'.
* fill e_portal_actions to navigate
ls_namevalue-key = 'Customer'. "#EC NOTEXT
ls_namevalue-value = -kunnr.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'Sales_Organization'. "#EC NOTEXT
ls_namevalue-value = -vkorg.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'Distribution_Channel'. "#EC NOTEXT
ls_namevalue-value = -vtweg.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'Division'. "#EC NOTEXT
ls_namevalue-value = -spart.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'Company_Code'. "#EC NOTEXT
ls_namevalue-value = -bukrs.
insert ls_namevalue into table ls_portal_actions-parameters.
when 'CLIT'.
ls_namevalue-key = 'AGKON'. "#EC NOTEXT
ls_namevalue-value = -kunnr.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'BUKRS'. "#EC NOTEXT
ls_namevalue-value = -bukrs.
insert ls_namevalue into table ls_portal_actions-parameters.
endcase.
case i_actionid.
when 'DISP'.
ls_portal_actions-bo_op_name = 'Display'. "#EC NOTEXT
* filled by default?
*** ls_namevalue-key = 'CHANGE'.
*** ls_namevalue-value = space.
*** insert ls_namevalue into table ls_portal_actions-parameters.
e_portal_actions = ls_portal_actions.
when 'CHAN'.
ls_portal_actions-bo_op_name = 'Change'. "#EC NOTEXT
* space cannot be filled by default
ls_namevalue-key = 'CHANGE'. "#EC NOTEXT
ls_namevalue-value = space.
insert ls_namevalue into table ls_portal_actions-parameters.
e_portal_actions = ls_portal_actions.
when 'COPY'.
* copy customer
ls_portal_actions-bo_op_name = 'Copy'. "#EC NOTEXT
ls_namevalue-key = 'Reference_Customer'. "#EC NOTEXT
ls_namevalue-value = -kunnr.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'Reference_Company'. "#EC NOTEXT
ls_namevalue-value = -bukrs.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'Reference_Sales_Org'. "#EC NOTEXT
ls_namevalue-value = -vkorg.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'Reference_Distr_Chan'. "#EC NOTEXT
ls_namevalue-value = -vtweg.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'Reference_Division'. "#EC NOTEXT
ls_namevalue-value = -spart.
insert ls_namevalue into table ls_portal_actions-parameters.
e_portal_actions = ls_portal_actions.
when 'EXT'.
* extend customer
ls_portal_actions-bo_op_name = 'Extend'. "#EC NOTEXT
ls_namevalue-key = 'Customer'. "#EC NOTEXT
ls_namevalue-value = -kunnr.
insert ls_namevalue into table ls_portal_actions-parameters.
e_portal_actions = ls_portal_actions.
when 'AACC'.
* analyze account
ls_portal_actions-bo_op_name = 'Analyze_Account'. "#EC NOTEXT
* 'Customer' and 'Company_Code' already provided, 'Fiscal_year' to be entered manually
e_portal_actions = ls_portal_actions.
when 'CLIT'.
ls_portal_actions-bo_op_name = 'Clear_Items'. "#EC NOTEXT
e_portal_actions = ls_portal_actions.
endcase.
* this came from general list
case i_actionid.
when 'BLOC' or
'DELE' or
'EDCL'.
clear ls_portal_actions.
ls_portal_actions-bo_name = 'KYK_CUSTOMER_BLOCK'. "#EC NOTEXT
case i_actionid.
when 'BLOC'.
* block/unblock
ls_portal_actions-bo_op_name = 'Block'. "#EC NOTEXT
when 'DELE'.
* deletion flag
ls_portal_actions-bo_op_name = 'Delete'. "#EC NOTEXT
when 'EDCL'.
* edit credit limit
ls_portal_actions-bo_op_name = 'CRC_Edit'. "#EC NOTEXT
ls_namevalue-key = 'KKBER'. "#EC NOTEXT
ls_namevalue-value = -kkber.
insert ls_namevalue into table ls_portal_actions-parameters.
ls_namevalue-key = 'NAME1'. "#EC NOTEXT
ls_namevalue-value = -name.
insert ls_namevalue into table ls_portal_actions-parameters.
endcase.
ls_namevalue-key = 'KUNNR'. "#EC NOTEXT
ls_namevalue-value = -kunnr.
insert ls_namevalue into table ls_portal_actions-parameters.
e_portal_actions = ls_portal_actions.
endcase.
endmethod.
■
The Business Object Builder can be used to inspect the methods of a Business Objects resp. to create own ones.
|SAP ERP menu |Tools → Business Workflow → Development → Definition tools → Application |
| |Integration → Business Object Builder |
|Transaction code |SWO1 |
See the Application Help for general information about scope and usage of the Business Object Builder.
-----------------------
POWER List Cache
Backend
Database
Feeder Class
POWER List Framework
POWER List Cache
Backend
Database
Feeder Class
POWER List Framework
APPLID
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- program logic formulation is the study of the
- ifcap technical manual veterans affairs
- boolean logic in computing electrical engineering
- logical architecture diagramming guidelines
- turn over package guide colarelli construction
- powerlists howtodevelop community wiki
- experiment 6 flip flops and feedback devices