POWL: User creates a new query - Does it always save the last entered values? And is this standard functionality?

[former_member195355]

Hiya,

From your experience how would you say user defined queries work?

Okay let's say we have a POWL and the user decides to create their own query via the 'Define New Query' button.

They create a new POWL query, with specific selection criteria, and it works great.

Uh-oh, one day they accidentally run the new query with some bogus selection criteria that the user doesn't want.

The new POWL query seems to remember the last entered selection criteria and always shows that to the user.

And there seems to be no way of going back to the orginal selection criteria of the user's POWL query?

Is this standard POWL functionality for user defined queries?

i.e. That whatever the user last enters into the selection criteria, is also what will appear hence forth, and not the criteria that was entered when the user created their query?

Thanks in advance for any help!

[ionbarbu · Accepted solution]

Hi Robert,

What you are describing is standard behavior of the POWL queries. In a way, it can be an advantage for the user of the POWL to have the data previously entered upon future uses of the application. Think of this as transaction history in SAPGUI.

The way you have described the problem it sounds like perhaps the users should not be creating new queries, but rather to use either existing selection criteria, or filters.

Selection Criteria.

When the customizing is done centrally for a POWL application, the fields relevant for selection can be defined. Normally, whatever fields the users require for the business process should be made available in this way. When end users then launch the POWL app, they can vary their selections according to their needs.

Filters

Another option for end users is to activate the filtering logic. If for some reason the users do not want to adapt / modify the selection criteria, and only want to work with the data in the report, then filters could be useful. Upon clicking the filter button, each column can be filtered individually. Operators can be used during filtering, have a look here for some examples.

If you go for the filter option, then each time the POWL is loaded, the filtered criteria will be reset.

For a more detailed explanation of how POWL_D01 report, please search this forum, or provide us the system details (EHP level etc) of your implementation.

Regards,

Ion Barbu

[former_member195355 · Accepted solution]

Hi Ion,

Thanks for the really great explanation!

I'm on EHP 6 Netweaver 7.31 if that helps.

That's one thing I struggle with, finding detailed documentation for POWLs (or anything else really).

POWLs seem so useful but finding good information seems to be tricky. The POWL wiki seems to be good but if you have any other tips then that would be great!

Thanks again!

[ionbarbu · Accepted solution]

Hi Robert,

Glad to hear the info was useful. As far as finding additional info, my recommendation is to spend some time hands on with the application to better understand the functionality. Given your EHP level, POWL_D01 should work as already explained above by Damean-BF Chen. In earlier versions, there was a bug which affected admin queries / views but this has been resolved.

One other suggestion is to think about the end users of the POWL in question. It is not clear from your comment if there will be a lot of users in this group or not, but end users usually need support. If they are all allowed to create their own queries, then it can become difficult to troubleshoot individual issues. Some instances to consider could be:

• As they have query level access, end users could delete admin (master) queries for their user
• Performance is dependent to the number of records requested
• Changes in the field catalogue (back end) could be out of sync with queries created by end users (ex: User xyz creates a query with column 123. In the back end, you decide column 123 is no longer relevant and you remove it from the catalogue. Now user xyz loads the POWL and gets a short dump)

If the end user community is a large one, I would recommend to:

• deploy the application with an admin query
• ensure the relevant selection criteria is available
• do not allow query creation / change access for end users

Regards,

Ion Barbu

[Damean]

Robert

   When you say "Create Query", does it mean doing that from the Query Cockpit (POWL_COCKPIT); or just creating a new Query Tab via the POWL application?

  If it's the later (new Query Tab via POWL app)  ... My 2 cents; sometimes user are confused between Personalization, Customization vs Configuration; hence creating versions that they're not even aware of.  To resolve, run program POWL_D01; find the duplicates and delete it.

  HTH

[former_member195355]

Hi Damean,

Many thanks for the reply and sorry, I think I didn't explain myself clearly.

Our users 'Create Queries' from the POWL - which we developed. There are three options on the left of the POWL:

'Change Query'

'Define New Query'

'Personalise'

(Or something like that, I'm not connected to a system so I can't check)

And it's this 'Define New Query' that I'd just like clarification on.

You see, users are creating their own queries and saving them using 'Define New Query'.

They have noticed that when they adjust the search criteria on their 'new' query, the next time they go into it, the system remembers the ‘latest’ change rather than the state of the query that was saved when they initially created it, via 'Define New Query'.

It might be a standard behaviour, I don’t know.

Would you know?

I tried using POWL_D01 but this seemed to delete the new query, and so the user had to create it from scratch.

Is that how you'd expect POWL_D01 to work?

Thanks again for any help you can offer.

[Damean]

Robert

  IC ... You're correct, the POWL_D01 report does do the deleting; but you would notice that it's set to Display Only By Default. The objective is basically trying to see how many copies of the same query have the user created; and then only delete those those you suspect not being used (regrettably reports has no "last used" date).  User may not realize it, but duplicates could be accidentally created due to diff logon language; or because of the Shadowing setup.

  Also, another report that I may run is POWL_D04l this delete the cached selection criteria created for the Admin queries.

HTH

Regards

Damean