This is an extension of the permission check article.
In terms of data, we need to take data from different systems and show them to users.
The authority is involved here. Depending on the authority, the data that can be seen is different.
Unlike ERP, the ERP side is about what operations you can perform, but the BW side is about what data you can see and what operations you can perform .
We only know the fur of BW, we can only summarize and summarize BW.
Article Directory
Permission object
What is a permission object?
Just like a block of access control tokens, you have different tokens, pass through different entrances, and they will be given to you after being checked by others. If you check that there is no token, I'm sorry, don't enter.
What you can do after entering will also be stated, this is called the permission field. Each permission field on the permission object will tell you what you can do and where on the object.
We can see all standard permission objects in SU21 . The standard tells you what you can do . Such as modeling, monitoring, counting, loading and so on.
Analyze authorization
In addition, there is analysis authorization . Create and maintain analysis authorization code: RSECADMIN .
What is the analysis authorization? It tells you what data you can see . How is this achieved?
This is achieved through permission-related objects.
Such as company code, factory, cost center, profit center. By setting these permissions-related objects to establish data permissions for different companies, different factories, different cost centers, and different profit centers.
Analysis authorization does not operate on the authorization object. But you can analyze the authorization in the authorization object. It is actually based on a set of permissions-related features or navigation properties. In the analysis authorization, the value of the relevant characteristics of the authorization is limited to provide the authorization of the corresponding data. Of course, it is not necessarily a specific value, you can also use an export variable to limit it. If you feel dizzy, continue to look down.
These permission-related variables are used in the query, and the user's permission is checked when the user accesses the query. Under normal circumstances, the query will always run a data set that meets the conditions from the database. If there are permission-related objects in this data set, then you have to ensure that the user who runs the report has the permission of the corresponding permission-related objects, and then he can run out of his own data. Otherwise, there will be an unauthorized error. Generally, in order to prevent the query performance from being affected, it is best not to exceed 10 permission objects in a query. If the permission object value is limited to *, then there is no effect, which is equivalent to no restriction.
It should be noted that analysis authorization is not a concept of filters.
To sum up, the analysis authorization is based on a set of permission-related characteristics or navigation attributes, and then the value of the restriction characteristic is restricted.
The limit value can be single value, interval or level authorization.
Then to assign this authorization to the user.
So how to allocate it?
Create role and profile
By establishing role and profile. PFCG to build role:
change permission data.
We can refer to the existing template:
From the following we can see that the permission data is based on the SU21 permission object and the permission fields under the object.
According to what we said before, the permission object is equivalent to a token, and the permission field tells you what you can do. The figure below is an analysis of the authorization field filling value. You may be dizzy here. Didn't it mean that analysis authorization has nothing to do with permission objects? Why give the value under the authority object?
Because the authority object opened a hole for it, including the object of analysis authorization. It's just that the value is an analysis authorization.
Let's look at a standard authorization: the
standard authorization object is which token you gave, the authorization field under the token, and what you can allow them to do. For example, the activity field above allows people with this role to add, delete, modify, and check. These operations are all possible. There is no limit to the operable range below.
For report users, you must add permission objects:
S_RS_COMP
S_RS_COMP1 is
used to restrict the accessible reports. Qualify the report name in Name of a reporting Component. Or start with Q*.
S_RFC is associated with the permission of the background from Bex, otherwise the background data cannot be accessed.
So far, without discussing and analyzing the specific operations of authorization. We can directly activate and transfer the role. The profile will be generated before. A role corresponds to a profile. In the specific permissions file, you can see that the profile is the number after the permission object, with the last two digits removed.
Regarding the transfer role, please see this article: Role transfer
Finally, we just assign this role to the user.
The above is to integrate the analysis authorization into the profile of the role by creating a role. You know that analysis authorization can be established directly from RSECADMIN, so if you want to directly assign analysis authorization to users, it is also possible: or RSU01,
but analysis authorization seems to be generally based on roles. This is why we first created the role, and then assigned the analysis authorization under the standard object. If you directly build an analysis authorization and assign it directly to the user, it is under Manual or Generated.
Analyze the realization of authorization
Well, come back here to fill the hole.
The role that the user currently has is just created with reference to the role provided by SAP. In the analysis of authorization, what we see is this:
0BI_ALL. This is for all permissions. If you give this authorization and then create your own authorization, please remember that this all will cover all other authorizations.
If you check under rsecadmin, you will find that this 0BI_ALL includes all the permission-related objects in the system, and then gives all the object values: *
Then what should we do?
We can copy this analysis and authorize it, and then modify it based on it:
You can limit the hierarchy to dynamically obtain values from the customer export variables.
This is why the analysis authorization can not be simply regarded as a filter, the function of exporting from the customer is actually equivalent to an interface. (Writing later, if available)
can also be limited to a fixed value or interval.
Then fill in this new analysis authorization under the authorization field, replacing 0BI_ALL to complete our authorization limit.
If you want to create a completely new one yourself, it's just that there will be three default objects:
0TCAACTVT-is the authorized behavior, you can modify or view.
0TCAVALID-authorized time interval.
0TCAIPROV-Authorized information provider.
At this point, the next step is to create a query with the authorization object defined in the analysis authorization, and then let the user execute the query to verify whether our analysis authorization is reasonable.
You can test for him by yourself: RSUDO
or under RSECAMDIN:
to execute query.
