Skip to Content
Former Member
Former Member
May 14, 2012 15 minute read

POWL —> My Learning

Follow RSS feed
0 Likes 1,238 View 1 Comment

POWL different Topics with my learning will be updated……………..

Personal Worklist As a End User

POWL is an SAP innovation that provides users with a general overview of their work environment and all the related business objects that they would be interested to work on. It enables them to manage their work by bringing together object assignments from different systems, which themselves are not a part of the workflow (including alerts, knowledge management (KM) notifications, and collaboration tasks). It’s used as the central access point to object-related tasks

Characteristics of a POWL

To describe a POWL more process and business wise it is worth to list up its characteristics. Hence, the following features shall help to get an understanding. A POWL …

  • is embedded in a web-based environment
  • can run in SAP Portal or in SAP NetWeaver Business Client (or even stand-alone, called via a URL)
  • is mostly grouped along other POWL´s forming a “Business Role” such as the “Buyer” or the “Internal Sales Representative”
  • – if embedded in a role – it is hence personalized to a specific target group
  • lists specific business objects (sales orders, purchase requisitions, etc.)
  • provides a homogenous user-interface and finally
  • simplifies business processes.

POWL and Universal Worklist (UWL)

In SAP a lot abbreviations are used and sometimes it’s quite confusing. Hence also the abbreviation “UWL” shall be explained in this context.

The term “Universal Work list (UWL)” also occurs in the context of POWL´s or portal roles in general. However, the distinction between both can be seen in the intention of the lists. A UWL is a generic work list tool and here the user “… is shown those objects he is obliged to process or to notice …” – so UWL´s display are used to display workflow items and alerts.

Both – UWL´s as well as POWL´s – can (and should) be used to tailor the system in a way that all relevant sub-processes of a specific role is comprised in one common framework.

Definition

Worklist that is created automatically for a user.

The user gets a list of tasks for a specific work area; this task list forms the worklist. 

●      Each list contains specific business objects from your department. For Sales and Distribution, for example, there are worklists for sales orders. The  content of the worklists is specifically defined according to each work area. For example, you can get a list with incomplete sales orders or one with  sales orders that are blocked for delivery.

●      The worklist also contains the specific functions with which the user can process the business objects.

The personal worklist is also referred to as follows in the Implementation Guide (IMG) and other documents:

POWL (Personal Object Worklist)

POWER List (Personal Object Work Entity Repository List)

Use

Process Business Objects

Each worklist of business objects provides special functions you can use to process the selected business objects and integrate them into subsequent business processes. For example, you can change incomplete sales documents to add missing pricing data.

Structure

The worklist is structured like a table:

●      The rows contain the individual business objects that you select for further processing (such as orders)

●      The columns contain the business data on a business object (such as sales document, sold-to party, net price)

You can adjust the data scope to suit your current task.

Integration

Query

The content of a worklist is defined by a query. Its definition is based on a worklist type that is set up in Customizing.

The worklist type refers to a specific business object and defines the business data that you can use as search criteria.

●      To use selected business data as search criteria, you personalize the query.

●      Additional settings for the view and layout of the worklists and reports support your personal method of working.

You can use the following specifications to tailor the business data selection to fit your current task.

Data

Use

View with Settings

You can change the view by editing the settings.
If you want to use your selected data more than once, save the changed view under a suitable name.

Filter

The filter settings restrict the worklist data to certain areas such as a period. Therefore, you can activate the filter separately and display the filter settings in the first row, or delete all filter settings.

Different transactions for POWL

You must execute the following activities for a standard POWL:

1.      Process personalization application ID ———— Tx —-> fpb_maintain_hier

You define the business context in which you want to use the personal worklist, for example, to process sales documents or for inventory management.  The application ID is used in several subsequent substeps to process data for the personal worklists.

2.      Create / Edit / Delete POWL Type  ————Tx ——> POWL_TYPE

          You can register your new POWL feeder classes (Implementation of Interface for POWL Feeder). The system determines the content and processing functions for a worklist on the basis of the feeder class.

For each POWL type, you can later define several queries that differ in how their selection criteria are valuated.

3.      Register POWL Type (Role-Based / User-Based)  ——–> POWL_TYPER and POWL_TYPEU

The Registration Type function (Register POWL Type) starts a processing step in which you can define an application ID to identify the POWL type and enter a language-dependent description. You can identify your personal worklist using the application ID.

Registration takes place on a user basis or role basis.

○       Assign the POWL type either a role (View: Type – Role Assignment) or an individual user (View: Type – User Assignment).

○       If you want to assign an iView to a POWL type, register the type in the processing step (View: Type – Role Assignment) and do not make an entry in the Role field. The system determines the POWL type for an iView based on the application ID.

4.      Register POWL Query (Role-Based / User-Based) POWL_QUERY, POWL_QUERYU, POWL_QUERYR, POWL_CAT

The Registration Query function (Register Query) starts a processing step in which you register a query for a role, user, or entire application, thus making the personal worklist visible in the portal.

Depending on your system settings, several substeps are required before you can register a query:

○       You use the Maintain Query function to define a query by specifying the POWL type that determines the content, for example.

○       You use the Registration Category function to register categories so that your sales representatives can group multiple queries for clearer display in the portal. These categories are part of the personalization settings and can be used by sales representatives to sort queries as required. The name of the category isused as the header for a group of queries.

Registration takes place on a user basis or role basis.

○       Assign the query either a role (View: Query – Role Assignment) or an individual user (View: Query – User Assignment).

○       If you use multiple queries for an application, you should define a category sequence for better transparency.

Using POWL in your WD component and using its Plug Parameters

  1. Create a WD ABAP component
  2. Double click on the name of your created component -> Choose tab ‘Used Components’.
  3. Enter a name for the component usage (column ‘Component Use’) and ‘POWL_UI_COMP’ for the component (column ‘Component’).
  4. Create an outbound plug (must contain the parameters which are provided by ‘POWL_MASTER’ window)
  5. Embed view ‘POWL_MASTER’ in your window and connect the default inbound plug provided by this view with your created outbound plug.
  6. Fire the outbound plug in the desired method.



Reports for Personal Worklists

POWL developers and administrators can execute various reports for personal worklists (Personal Object Worklist, POWL). These reports help in updating the cache data, query information etc.

The details of reports are given below

Report Use
POWL_D01
Delete Queries from Database

Purpose

This report deletes derived/ user defined POWL Queries from the cache based on Application Id and/ or User. It performs the following operations:

  • Display user defined queries based on Application Id and/ or User.
  • Delete the user defined queries or derived admin queries
  • Delete relevant query personalization This report is intended mainly for POWL developers and system administrators to delete any existing query cache.

    Selection

    You can specify a selection for Application Id and/ or User.  The report runs a check matching this selection and display the corresponding list of queries.
    Additionally, you can also decide if you want to display the results of your selection or you want to directly delete them without displaying it. The checkbox “Display Only”  is used for this purpose,

    Output

    The output of this report gives the following options:

  • Display list of queries with query id, POWL Type, GUID etc.
  • Deletion of one or more queries based on selection.
POWL_D02
Show POWL Design Information

Purpose

This report shows the structure of POWL applications – the assigned POWL types, admin queries and feeder classes. It can be useful in following cases:

  • Checking if the structure was defined properly, i.e. if the correct POWL types or admin queries were assigned * Search for the feeder classes related to a particular POWL Thus the report is intended mainly for POWL developers and administrators.

    Selection

    You can select the desired POWL applications two ways:

  • via roles: you specify a role selection and the program shows all POWL applications assigned to the PFCG-roles that fit to the role selection * via application ID: you specify a selection of application IDs and the program shows all POWL applications that match this selection, assumed the application IDs have been registered in the personalization framework (transaction FPB_MAINTAIN_HIER) You can also decide if you want to see the descriptions of the displayed objects (roles, POWL applications, types, queries) or not.

    Output

    You can see blocks per POWL application ID. If selection based on roles was made, you can also see the role names and the names of the role entries referring to the POWLs.
    Each application ID is followed by POWL types assigned to that application ID with the corresponding feeder class. Below each POWL type all admin queries of that type are listed.
    Furthermore you can see admin queries that are assigned to the current application ID but the type of which is not assigned to that application ID. Below each query the type of the query and the corresponding feeder class are mentioned.
    The report provides also some additional information:

  • the application ID is registered in the personalization framework (transaction FPB_MAINTAIN_HIER) * a referenced POWL type or query doesn’t exist in the check table * both the query and the type are assigned to the application ID * a query is activated * a query is visible If you switch on the descriptions then you can see the descriptions in the logon language (if existing) directly below the corresponding key.
POWL_D03
Check Consistency of POWL Table Entries

Purpose

This report checks the mapping consistency and existence of POWL table entries – Application IDs, POWL Types and Queries. It performs the following checks:

  • Application ID is registered to the personalization framework * Query assigned to an Application ID really exists * Type assigned to a query that is assigned to an Application ID really exists * Type assigned to Query is assigned to the same Application ID as the query * Category assigned to a query really exists * Default Layout assigned to a query really exists * Query is last refreshed after a particular (user-selected) date and time * Query is assigned to an Application ID * Type is assigned to some query * Type is assigned to an Application ID Additionally, this report compares check results generated at different instances, displaying the differences in POWL table entries between them.
    Furthermore, the report could be scheduled as a regularly running job in background mode.
    Thus the report is intended mainly for POWL developers and administrators.

    Selection

    Selection Options
    You can specify a selection for Application ID, POWL type and Query and the report runs a check matching this selection.
    If you want the (query related) check to be performed only for those queries that were refreshed after a particular period, you can specify a selection for date and time with the checkbox ‘Chk If Query Refreshed After’ checked.
    Additionally, you can also decide if you want the check results of your selection saved to have it available for future reference. Any of these saved results could be deleted using report POWL_D05.
    Display Options
    In addition to display of check results for current selection options, you can decide to:

  • Display your last saved results * Display any previously saved results (of any user) * Compare the results of current selection with any previously saved results and you can decide if you want to display all the results or only the differences * Compare any two previously saved results and you can decide if you want to display all the results or only the difference

    Output

    You can see four blocks in total; the first block showing the selection options entered and rest three blocks of check results.
    In the first block of results – Check Application IDs, you can see the check results related to Application IDs in the following format.
    <Application ID> | <Q/T> | <Query/Type> | <Check Results>
    In the column Q/T, Q stands for ‘Query’ check, T stands for ‘POWL Type’ check and if empty, it applies to the check for the Application ID.
    In the column for ‘Check Results’, you can see one or more of the following messages.

  • OK * Not registered in personalization framework (this check result is applicable only to an application ID) * Query doesn’t exist * Type doesn’t exist * Type not assigned to that Application ID * Category doesn’t exist * Default View doesn’t exist * Outdated Query (this check result is applicable only if the option to check queries refreshed after a particular period was activated) It may happen that more than one error message can occur per one line and in this case, you will find the error messages displayed one below the other.
    In the second block of results – Queries not assigned to an Application ID, you can see the list of all queries (as per the selection entered for ‘Query ID’) not assigned to an application ID in the following format.
    <Query ID> | <Check Results>
    In the column for ‘Check Results’, you can see one or none of the following messages.
  • Default View doesn’t exist * Outdated Query In the third block of results – Types not assigned to a Query or Application ID, you can see the list of all types (as per the selection entered for ‘POWL Type’) not assigned to either an application ID or a query or both in the following format.
    <Type ID> | <Check Results>
    In the column for ‘Check Results’, you can see one of the following messages.
  • Not assigned to an APPLID * Not assigned to a query * Not assigned to a Query/ APPLID Furthermore, if your display option was to compare two results, the output would still have four blocks in total as above, but in two column-sets; the first column-set showing the results for the first selection and the second/ last column-set showing results of the second selection with any difference in check result between the two results for a key row highlighted in red.
    If a key entry is available in one of the two result sets and not available in the other, comparison is not possible and this row is highlighted in yellow with a message ‘Corresponding entry not available to compare’ in place of the unavailable entry.
POWL_D04
Delete Cached Selection Criteria for Admin Queries

Purpose

This report deletes the selection criteria cache of admin queries based on the provided admin Query Id and/ or POWL Type. The output of this report is a transportable workbench request.
Thus the report is intended for the administrators to delete any selection cache of admin queries before updating the query with new selections.
For example, consider a query ‘Flight Details’ was delivered with the .following selection (set using transaction POWL_QUERY).
Carrier = ‘AA’.
After the query is delivered, if the administrators or developers would like to add a selection to the query ‘Flight Details, for example, like the following
Carrier = ‘AA’ and Connection Number = ‘0017’.
To have this new change visible to business users during their query execution, the current cache has to be first deleted by running this report and then the selections have to be set again in transaction POWL_QUERY.

Selection

You can specify a selection for Admin Query Id and/ or POWL Type, the report runs a check matching this selections and deletes the cached selection criteria.

Output

The output of this report gives the following options:

  • Deletion of selection criteria from the cache that is transportable
POWL_D05
Delete POWL Check Results		 This report deletes POWL check results that were generated  or saved previously using report POWL_D03.
POWL_D06
Activate Derived Queries

Purpose

Report POWL_D06 is used for activating the derived queries.
This should be used when the admin queries (created using transaction POWL_QUERY and mapped to an application using transaction POWL_QUERYR) are initially inactive (Active flag in transaction POWL_QUERY is unchecked) and are activated at a later point in time. In such a case the derived queries for the initially inactive query will not be visible on POWL as the changes made to the admin query are not transferred to derived queries. After executing this report the derived queries would get activated.

Selection

You can specify a selection for Application Id, POWL Type and Master Query Id. In case derived queries of another user need to be activated, the user name field needs to be updated.
POWL_D07
Delete Shadowing Entries

Purpose

This report deletes derived/ user defined POWL Queries created in shadowing mode from the cache based on Application Id and/ or User. It performs the following operations:

  • Display user defined queries based on Application Id and/ or User
  • Delete the user defined queries or derived admin queries
  • Delete relevant query personalization This report is intended mainly for POWL developers and system administrators to delete any existing query cache. This report is a replica of POWL_D01. Nevertheless, POWL_D01 is intended for normal POWL execution and POWL_D07 is intended for POWL execution in shadowing mode.
    Quick hint on what is shadowing mode: POWL queries are personalized queries that are locked for a user in a particular session. Meaning, when the same user opens the same query in the second session, the query is displayed in a disabled mode from the second session onwards. This is the normal behavior of POWL.
    Nevertheless, in cases where same ‘User Ids’ will be shared across business users, it is critical to have the same query opened in N number of sessions in an enabled state to allow the users to perform their business operation. This behavior can be switched on explicitly from the configuration and is referred to as ‘Shadowing Mode’ execution of POWL.

    Selection

    You can specify a selection for Application Id and/ or User.  The report runs a check matching this selection and display the corresponding list of queries.
    Additionally, you can also decide if you want to display the results of your selection or you want to directly delete them without displaying it. The checkbox “Display Only”  is used for this purpose,

    Output

    The output of this report will show following:

  • Display list of queries with query id, POWL Type, GUID etc.
  • Deletion of one or more queries based on selection.
POWL_D08
Delete Admin Layouts

Purpose

You can use this report to delete layouts delivered by SAP/ created by an administrator (from the POWL_QUERY transaction). The output of this report is a transportable workbench request. This report mandatorily needs to be executed in the development client only.
Ideally, admin layouts (also called as variants) are created on a per query basis and delivered. If at a later point, the administrators would like to make a particular layout unavailable for users, it requires a deletion of the layouts which can be achieved using this report.

Selection

You can specify a selection for the application ID and the report retrieves all the queries mapped to this application ID for which layout variants were created by the administrator.

Output

The output of this report gives the following options:

  • Display list of queries with query id, POWL Type, GUID, Layout variant description etc.
  • Deletion of one or more layout variants that is transportable
POWL_D09
Delete Default Layout Mapping

Purpose

You can use this report to delete mapping of default layouts to queries created by an administrator (from the POWL_QUERY transaction). The output of this report is a transportable customizing request. This report mandatorily needs to be executed in the customizing client only.
Ideally, ‘N’ admin layouts (also called as variants) could be created for a single query and one of these layouts is set as the default variant for the query. If at a later point, the administrators would like to reset/ remove this mapping or would like to validate if their layouts really exist in the system, this report could be executed to achieve the same.

Selection

You can specify a selection for the application ID and the report retrieves all the queries mapped to this application ID for which layout variants were created by the administrator.

Output

The output of this report gives the following options:

  • Display list of queries with query id, POWL Type, GUID, Default Layout variant description, Validity of the default layout, etc.
  • Deletion of one or more default layout variant mapping that is transportable
POWL_WLOAD Refresh Active POWL Queries You can use this report to update queries.  If you schedule the report as a background job, for example, you can update the queries overnight. Users then have access to the updated data when they start work, without having to refresh the data themselves. This is a way of controlling the server load.

Therefore you have to use the report POWL_WLOAD. You can restrict the asynchronous refresh to a chosen Logon/server group. If you check ‘Discard old cached results’ the cached results and the field catalog will be deleted. The selection parameters stay constant (will not be deleted because otherwise it would mean that the queries will be deleted).

With Note 1456947.

POWL_WLoad report selects all the queries in system based on selection criteria provided by the user and updates the cache for all the queries.
Some of the queries may be more frequently accessed than the rest. The user may wish to update the most frequently used queries so that the execution time of the report is less.
Explanation of functionality:
To selectively refresh the most frequently used queries, an option “Query last accessed in (days)” is provided.This is an optional parameter. This optional parameter is in inclusive of the other selection options already provided by the report.

Note: POWL_WLOAD is a performance intensive report. It is not recommended that this report be used for frequent refresh.

Assigned tags

Related Blog Posts

    Related Questions

      1 Comment
      You must be Logged on to comment or reply to a post.