QuickViewer Security Considerations


QuickViewer Security Considerations

An important security distinction that applies to the QuickViewer does not apply to the InfoSet (Ad Hoc) Query tool or the SAP Query tool: the dynamic declaration of the data source.

If you think about the recommended strategies for deploying and configuring the data source with the SAP Query tool and the InfoSet (Ad Hoc) Query tool, you will recall that the configuration of the data source happens only in the development environment. A technical professional trained in your development environment must configure the InfoSet (data source) for reporting with the InfoSet (Ad Hoc) Query tool and the SAP Query tool. Furthermore, when creating InfoSets (data sources) with those tools, you should use logical databases to provide security. When a logical database is used within a data source and a user writes a query-based report by using that data source, the SAP solution is smart enough to determine who the user is and what the user has access to; it then restricts the user's reporting results accordingly.

A QuickView's data source is declared when the QuickView is built. So, for example, you can say you want to create a QuickView that uses a table. Doing so ensures that every field and every record in the table is available to you. This raises a security concern, however. With the ability to directly read tables, you can bypass traditional security concepts and have access to all data.

Let's look at a real-world example from the Human Capital Management (HCM) module. In the HCM module, users commonly have access to different things. One level of access can be based on location. For example, some users would have access to all associates in New York, and others would have access to associates in California. When any SAP Query report is created that uses a logical database within its data source, the security settings specify which users can see which locations. For example, if Jim had access only to New York, his executed report would contain only New York associates, and if Dan had access only to California associates, upon execution of the same report, Dan would see only the California associates.

If a user created a QuickView by using the QuickViewer tool and specified the employee table directly (rather than the logical database that includes it), the user would see all associates (from New York, California, North Carolina, and so on) in his or her report output, bypassing security.

It is a best practice to choose one reporting solution and use it exclusively. Considering the security limitations of the QuickViewer, best practice dictates that it should not be the tool of choice.



Things to Remember

  • Creating QuickViews is quick and easy.

  • You must declare a data source when creating a QuickView.

  • You can convert QuickViews to SAP queries.

  • QuickViews are available only in SAP 4.6C and later.

  • There are security implications for allowing end users to use the QuickViewer reporting tool.



Chapter 21. SAP Reporting with Microsoft Excel

In this chapter

Using SAP Reporting with Microsoft Office 256

Maximizing SAP Reports by Using Microsoft Excel 256

The Fictional SAP Report for a Basic Microsoft Excel Columnar Chart 257

The Fictional SAP Report for a Basic Microsoft Excel Pie Chart 263

Making Microsoft Excel Pivot Tables Using SAP Report Data 265

This chapter describes how to maximize the use of the Microsoft Excel application in query reporting. This chapter is designed for those who are currently using some form of reporting that they wish to transmit and share with Microsoft Excel for further charting or pivot table analysis. You can use this chapter even if you do not create any SAP reports but can execute reports in SAP and have access to Microsoft Excel.