With “SAP Query” you can read out and analyze tables, i.e. bundle and present data in such a way that it can become the basis for decision-making.
The most important transactions around SAP Query are:
|SQ03||create user groups (to control access to queries)|
The first two transactions are also available to end users, SQ02 and SQ03 should be reserved for admins/authorized users.
How are queries created?
Queries can be useful tools for any question and in any operational environment. Important for this: The correct composition of the data that is evaluated in the query. The data comes from tables. The infoset (transaction SQ02) defines which tables and which fields from these tables flow into the respective query. Good to know: You can also use SAP logical databases as data sources. These already provide the correct table structure and important links and are used primarily in the SAP HCM area.
Important: As already mentioned, queries access tables. Users who are to execute or create queries therefore need authorization to view tables. This can be done via two different authorization objects: S_TABU_DIS or S_TABU_NAM.
S_TABU_DIS and S_TABU_NAM are identical in result: they allow (or not) access to database tables. However, important differences lie in the details. S_TABU_DIS always checks the combination of access activity (does the user want to view, change, create, etc.?) and table authorization group. The problem with this is that not every table is automatically assigned to a table authorization group. In addition, the names of the authorization groups are only 4 characters long, which can make a differentiated distinction difficult. Furthermore, a table authorization group always contains a large number of tables. This means that one authorizes possibly too much (and not only the access to the one desired table). Therefore, S_TABU_NAM no longer checks for the table permission group, but directly for the table name in connection with the access activity. Good to know: Within the authorization check, the check for S_TABU_DIS is always performed first. Only if this is negative, the authorization on S_TABU_NAM is checked.
How are SAP queries authorized?
Ultimately, it is a question of the authorization concept how strongly you differentiate the query authorizations. Basically, you can authorize the execution, creation and editing of queries in three ways:
- via the authorization object S_QUERY
- via user groups
- via an individual transaction that you define for a specific query
Authorize queries via S_Query
With the characteristic of the authorization field ACTVT (activity), you can specify in the object S_QUERY, for example, whether someone may create, edit or only execute queries. The problem with this is that if a user is allowed to both change (ACTVT: 02) and maintain (ACTVT: 23) queries via this object, they will have access to all queries of all user groups.
Authorize queries via user groups
To restrict this global access, you can authorize the queries via user groups (transaction SQ03). Here you can compile users, Infosets and queries in such a way that only certain users can access and change the corresponding data and evaluations. If you create a new user group or add a user to a user group, you can revoke the change authorization that the user may have via S_Query (in one of his roles) in the corresponding screen. He can then only access the queries and infosets that are assigned to him via the user group.
Create individual transaction for query
Good to know: You can create individual transactions for queries. These can be displayed in the Authorized User menu. In the respective role, access to the query is then authorized via the transaction (in the object S_TCODE) and not via the object S_QUERY. This also helps to keep authorizations as tight as possible.