How the SAP R3 Query Tools Work


How the SAP R/3 Query Tools Work

Query tools are based on the foundation of the SAP R/3 database. Historically, the primary method of creating reports in SAP was by using the ABAP Workbench and writing code in the language of ABAP. Specially trained programmers could write a long series of lines of code in an ABAP editor to retrieve information from the database, compute relationships, configure security, design selection screens, and present data in a particular arrangement. The skill set for ABAP programming is challenging to learn and usually requires experience in each application area of SAP for which programming will occur. For example, an ABAP programmer with experience in the Financials module would require special training to change functions and create reports in the Sales and Distribution area. Because these programming skills are substantial, SAP created the Query family of tools so that end users could pick and choose the fields they want to include in their reports and, behind the scenes, SAP would handle all the technical details. Figure 1.1 is a diagram that shows the foundation of the SAP Query tools.

Figure 1.1. An overview of the technical aspects of the SAP R/3 Query tools.


As described in the following sections, the SAP R/3 Query toolsSAP Query, InfoSet (Ad Hoc) Query, and QuickViewerare built on the foundation of four main components:

  • Query areas

  • Query groups

  • InfoSets

  • Administrative decisions (which are company-specific)

Query Areas

Query areas (known as application areas in versions of SAP earlier than 4.6) contain SAP Query elements, queries, InfoSets, and query groups. SAP has two distinct query areas:

  • Standard Standard query areas are client-specific. That is, by default, they are available only within the client in which they were created. For example, if they were created in the live production client, they would exist only in the production client. Transport of query objects created in the standard area can be accomplished between multiple clients on the same application server.

  • Global Queries designed in the global query area are used throughout the entire system and are client-independent. In version 4.6, SAP delivers many of its standard reports in the SAP Query global query area. These queries are also intended for transport into other systems and are connected to the ABAP Workbench.

Query Groups

Query groups were known as user groups in versions of SAP prior to version 4.6. A query group is a collection of SAP users who are grouped. A user's assignment to a query group determines which queries he or she is allowed to execute or maintain. In addition, it designates which InfoSets (that is, data sources) the user has access to work with. Basically, query groups give a user access to create, modify, and execute reports in a certain area within R/3. For example, you could create a query group for the Finance department that would house your financial users, or you could create a query group for the Human Resources department that only members of the Human Resources department would belong to. Using query groups is an easy way to group and segregate reports and users.

Query groups, which are often maintained by a system administrator, are created on the User Groups: Initial screen, which you can find by using the transaction code /nSQ03.

Users can belong to multiple query groups and might, under certain circumstances, copy and execute queries from other query groups (if the permissions are the same). Any user within a query group has authority to execute queries that are assigned to it, but only users with the appropriate authorization can modify queries or define new ones. Users are not permitted to modify queries from other query groups.

InfoSets

InfoSets, known as functional areas in earlier versions of SAP, are areas that provide special views of logical databases and determine which fields of a logical database or data source can be evaluated in queries. That is, an InfoSet is basically the data source, from which you get data to use in reports.

InfoSets can be built on a variety of different sources, but the most common is the use of an SAP logical database. Remember that writing reports without Query tools requires a programmer to write code that goes into the main R/3 database and retrieves the records it needs, and that is no easy skill. SAP delivers logical databases, which are rational prearranged groupings of data from multiple related indexed tables. SAP places all the fields you want to report from in a nice container from which you simply select the fields you want to include in your report.

Administrative Decisions for Query Tool Use

Using any new tool in an SAP R/3 system requires that you plan ahead and make sure you have all your administrative bases covered before you dive in and start creating reports. Because the SAP tools are so easy to configure and use, you might be tempted to skip ahead in this book and begin creating reports. Although that is possible, it is a best practice to first review and make some administrative decisions before proceeding, as described in this section.

From the get-go, deciding which departments will have ownership of and responsibility for the different areas of the Query tools is imperative. Again, because the tools are so easy to configure and use, it is possible to configure the tools and begin creating reports without ensuring that you are following the desired strategic direction of the organization. Making sure you review the different options and recommended best practices in this section is crucial to your successful deployment of query-based reporting at your organization. The following sections use the most popular and most robust query solution, the SAP query, instead of continually referring to each of the query tools individually.

Administrative Decisions for Query Areas

In Chapter 2, "One-Time Configuration for Query Tool Use," you will learn how to do the behind-the-scenes configuration for the SAP R/3 Query tools. This configuration is very easy to perform, and it is important that you first decide ownership and rules for the different query items.

One important administrative decision is how to use query areas. In version 4.6, SAP began to distribute its standard R/3 canned reports in the global query area. Those reports are now automatically available to every client on the application server because they exist in the global query area. A common best practice is to allow SAP to continue to deliver reports via the global area and for end users to use the standard query area to create all query-related reports. Reports created in this standard area are client-specific and by default exist only within the client in which they are created. However, they can be transported to other clients via the transport truck on the InfoSets screen (SQ02), bypassing the ABAP Workbench Organizer. The recommended best business practice is for SAP customers to use the standard query area to create their reports.

Administrative Decisions for Query Groups

Another important administrative decision is where to keep and maintain the query groups and InfoSets. For example, will you keep them in your development environment or in your production environment? With custom-coded ABAP reports written by programmers, the traditional methodology for report creation was as follows: A programmer accessed a development environment, where the first draft of the custom report was coded and tested. Next, the report was transported to a testing or quality assurance client, where it was more thoroughly tested. If it passed the testing, it was then moved on to the production environment for use.

The Query tools were added to SAP to give end users with no technical skills the ability to create reports in real time. With this in mind, your organization has to make a decision regarding a transport strategy. Query objects can be created in any client. However, there are some best practices. For starters, end users who will be using the Query tools often only have user IDs in the live Production environment. Because of this, and because the Query tools are designed for real-time live access to information, the best practice is to maintain query groups live in the production client.

Helpful Hint

If your organization uses some version of a standard new SAP user request form, it would be ideal to add a section to that form where you specify which query groups the new user will belong to and assign the task of placing users in the appropriate query groups as part of the SAP ID creation process.


Administrative Decisions for InfoSets

Although InfoSets can be created in any client, best practice dictates that they be treated in line with normal programming methodology: InfoSets should be created in a development environment owned by a technical professional and transported to a testing quality assurance client, where they are tested and then moved on to production for use. InfoSets are treated differently from the other fundamental objects of the query tools, such as query areas, because a trained user can add special coding or programs to InfoSets that may have an impact on system resources or functioning, and testing them is required in those cases. So the best business practice is to create InfoSets in your development environment.

Administrative Decisions for Queries

Finally, you need to make some administrative decisions regarding the reports (queries) themselves. Unlike custom-coded ABAP reports, query reports are designed to be made in real time in an ad hoc fashion, so the best practice is to create queries live in your production environment. Although the Query tools no longer have the resource hog reputation that existed in the early days, a user still needs to be trained before using queries in production.

As with all SAP-delivered canned reports and all of your organization's custom ABAP reports that are available to end users in your production client, if a user does not input the appropriate information on the report's selection screen, he or she runs the risk of pulling an incorrect amount of data from the database. This is also true of queries. The same training that new users of SAP receive to learn how to run standard reports must be extended to the Query tools as well. The best business practice is to allow trained end users to create queries live in your production environment.




SAP Query Reporting
SAP Query Reporting
ISBN: 0672329026
EAN: 2147483647
Year: 2006
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net