BW & BPC 10.1 Authorization relevant flag for InfoObjects/Dimensions

[kennedydb]

Hi Colleagues,

We are using BPC 10.1 NetWeaver version, and we have several dimensions market as Secure in the BPC models, this activates the Authorization Relevant option for those infoObjects in BW.

We have created the necessary profiles/roles in BW, in order to control the access to BPC data from BEX reports, and it was working fine.

Something done in BPC (as we never change the BPC IO from rsa1 in BW), changed the IO authorization relevant flag, and now the profiles/roles in BEX are not working.

Does anyone know what in BPC could have deactivated this option in BW? The relevant dimensions are still marked as secure in BPC models.

Is it possible to change this option in IO directly from BW, without affecting BPC?

I'll appreciate any feedback.

Regards,

David

[daniel_aporta]

Hi David,

we are facing the same problem. It occurs in BPC 10.0 and in BPC 10.1. In one case we've set the authorization relevant option directly in BW with non consequential errors.

However, it happens from time to time again and we want to know why. Do you have any solution in the meanwhile?

Best regards

Daniel

[Former Member]

Hi David,

I'd assume you use Standard model.

"Something done in BPC (as we never change the BPC IO from rsa1 in BW), changed the IOauthorization relevant flag, and now the profiles/roles in BEX are not working." Did you upgrade or applied a SP? After what this issue started happening? What does it mean that profiles/roles are not working - do you get an authorization error or wrong results?

On what objects are your BEx Queries built: Real Time cube, Virtual Provider or MultiProvider?

Regards,

Gersh

[kennedydb]

Hi Gersh,

We didn't apply any SP. and as this is a PRD system, users are only working in BPC, running the Consolidation process with their BPF. Maybe some changes in the work status.

What's wrong with the authorizations, is that the Dimensions are marked as secure in BPC, and the corresponding InfoObjects in BW are not market as Authorization relevant, so all the BEX reports are now giving an authorization error, as if the user had no authorization.

We have a copy of the environment, we use for some testing, and in this environment the IO are marked as Authorization relevant, the same as in the DEV system.

So my concern is, is there anything a BPC user can do, without changing dimensions or model structures, that could change this in the IOs in BW?

Thanks in advance for your reply.

David

[Former Member]

Hi David,

Where those InfoObjects Auth relevant in Prod or only in Dev? Did you start this project on 10.0 or on an earlier release? There was a transition earlier from IOs not marked as Auth Relevant to marked. That setting had to be done in each box, since it wasn't transportable. If you restore Env IOs were marked as Auth Relevant.

What kind of authorizations did you create fro those IOs?

Please explain on what cube your Queries are running becuse depending of cube type they are checked differently.

Regards,

Gersh

[kennedydb]

Hi Gersh,

The Infoobjects were created using BPC 10.1 in a DEV system, and transported to PRD, and all the dimensions market as secure in the BPC models had the IO marked as authorization relevant in BW. We didn't set that option manually in BW.

To control the access for the BEX reports, we created authorization variables and we created the necessary authorization objects and roles, and assigned them to the users. This has been working fine for months, until the IO were unmarked as authorization relevant in BW, without changing the secure dimensions in BPC. So now there is an inconsistency between BPC and BW, because the dimensions are still set as secure but they are not marked as authorization relevant in BW.

In regards to how we access the BPC cubes from BEX, we set the BPC cubes as data sources, and we added the cubes to a Reporting Multicube in BW, and the BEX reports are running against this multicube. We are not using the remote cube or the multicube generated automatically by BPC. We are also using the parameter in BPC to fix the technical names.

To fix the authorization problem in BW, I could change the authorization relevant option in BW directly, but I’m not sure if this could “break” something for BPC.

Thanks again for your feedback.

Regards,

David

[Former Member]

Hi David,

When you set BPC Model as "data sources" VirtualProvider was generated with same tech name as the Model, but with _B at the end. If you report on that cube then BPC authorization will be taken into account for BEx Queries and you don't need to configure any additional authorizations in BW.

From your explantion it looks like you used that _B cube in a custom MultiCube on which you run your BEx Queries. Is that correct?

Usually everything has it's cause (at least in technology:), so it's hard to imagine that Auth Relevant check mark just disappeared overnight without anything being changed in the system.

Regards,

Gersh

[kennedydb]

Hi Gersh,

Thank you for your response.

For some models, like consolidation and data collection, we are using the xxxx_B cubes, but for the planning model we are using the BPC cube in the BW multicube, as we have some IP/BEX input forms and IP planning functions in place.

I know that the Auth.Rel. flag can’t just disappear, I'm trying to find an explanation for this, as we haven’t changed the model structures in BPC. The only changes we have done, are on the BPFs, some minor changes on Data Access profiles and work status, and I believe this should not have an effect on the auth definition in the IOs.

A few days before this happened, we had copied the environment, for testing purposes, and the copied environment still has the Auth.Rel. flag set to true. I have check the Admin activity report in BPC, since the date the environment was copied, and there is no other change done in the original environment (other than the ones mentioned above).

My real concern now is how to fix this. Not sure if I can change the flag directly in BW, or if there is a transaction code to do this, or if there is a way to fix this from BPC.

I have tried to replicate the problem in DEV, to then see how to fix it before doing it in PRD, but even changing a dimension to not secure in BPC, the corresponding IO in BW does not changed to not auth relevant.

I’ll appreciate any suggestion.

Regards,

David

[Former Member]

Hi David,

I don't think it's a good idea having BPC Standard writing data in a cube and IP Planning Functions writing into same cube. They have completely different locking strategy; this is a disaster waiting to happen.

There was an OSS Note that explained why generated BPC InfoObjects has to be marked as Auth Relevant, but I can't find it right now. I think it was BW Note, not BPC. It also suggested, if I remember it correctly, turning those object in QA and Prod manually because transport is not going to recognize that Dimension has changed. For newly created Dimensions it will work fine.

If you want analyzing what caused that change you can try go to "Save/Activate" logs in InfoObject definition.

You can't reproduce the issue with UJBR because it regenerates the InfoObject. You can only reproduce it with transports.

Regards,

Gersh