BPC Embedded: Common DAP Configurations
BPC embedded “lives on” BW and many BW concepts are present in BPC embedded.This is also the case with authorizations. The BW feature of Analysis Authorizations is extended in BPC embedded to accommodate additional line-of-business use-cases.
When it comes to authorizations, there might be a big difference if a user accesses data as a “BPC-user” or a “BW-user” (even though he/she might use the same query).
In a BPC context, the applicable authorizations for a query are calculated from BW’s Analysis Authorizations in conjunction with BPC’s the Data Access Profiles (DAPs).
We will take a look at the way this calculation is done and show how this can be used to implement different authorization concepts.
Effective Authorization from Analysis Authorization and DAP
If a query is run in the context of a BPC environment and model, the authorizations A are calculated in the following way:
- The BW Analysis Authorizations B (as maintained in /nRSECADMIN) are extended by the environment authorizations E of the current environment (maintained in /nRSECENVI).
- This extended set of authorizations is then restricted again by the DAP D of the BPC-model in question.
In short, this can be summarized as
A = (B∪E) ∩ D
When we look at BW Analysis Authorizations B as a baseline, the general rule is
- Environment Authorizations extend access
- DAPs restrict access
Implications and Applications
From formula (1), we we can immediately see a common pitfall when setting up authorizations in BPC:
No DAP, No Access
When setting up BPC models containing authorization-relevant dimensions, a DAP has to be maintained. Otherwise, no access will be granted at all.
The reason is simply that if no DAP is maintained, this is interpreted as D being empty. Hence formula (1) shows that the effective authorizations A are empty. So access is denied.
Enforcing BPC Usage
A query might be run in a BPC context (with environment/model) or without this context as a plain BW query. When run as plain BW query, the DAP configuration is not considered, of course. Neither are the restrictions imposed by the BPC Workstatus feature.
So it might be desirable to enforce the usage of a BPC context for all users.
This can be done by putting all analysis authorizations into the environment authorization E. So in formula (1), we would set B to be empty and E to be the maximal authorization for the environment.
If a user now tries to run a query without BPC context, the effective authorization will be B only, which is empty. So no access will be granted.
This configuration ensures that the only way a user might access data is by using a BPC environment/model context.
The extension of BW Analysis Authorizations by B by environment authorizations E means that a query run in a BPC context potentially grants access to more data than the same query when run without the BPC context.
Using Same Authorizations in BW and BPC
The opposite scenario is where the behaviour in a BPC context should not differ from the behaviour in “plain BW mode”.
This can be achieved by simply setting E to be empty and D to be the all-authorization (* for all dimensions in the DAP). From formula (1) we see that the resulting authorizations A are then equal to the BW Analysis Authorizations B.
Note that it is still necessary to maintain DAPs even though the impression might be that BPC authorizations are not used at all (cf. above).
Building Matrix-Authorizations in DAPs
Technically speaking, the authorizations B, E, and D in formula (1) are sets of authorization objects. These objects are multi-dimensional and when implementing complex matrix-security concepts, it might be required to have an authorization like this:
In this example, we have two dimensions: region and product. We want to define a set of authorizations such that the user is authorized to see data for product “PC” in region “Asia” and for product “Phone” in region “Europe”.
To achieve this, we create two DAPs for the given model.
- Region = Asia
- Product = PC
So for this model the set of DAPs D in formula (1) now has two entries giving the desired authorization.
While the example is given in terms of DAPs, the same holds for ordinary BW authorizations B and environment authorizations E. Matrix-style security can be implmented in any of the places of formula (1).
thanks a lot for this clarification and confirmation! It took hours to understand the logic via debugging the code. Finally i found RSEC_READ_BPC_AUTHS function module which is doing the "job".