Question Re: BW Info Objects assigned under wrong BW dimensions after transport in Financial Management Q&A

BW Info Objects assigned under wrong BW dimensions after transport

Former Member — Mon, 19 Sep 2016 14:41:43 GMT

Hi guys,

there's a weird issue we are currently facing:

After transporting a BPC environment from development to quality, the BPC model specifc /CPMB/ - info objects appear under different BW dimensions than in the development system.

(We are using less than 13 BPC dimensions by the way).

Has anyone come across this or a similar issue?

Thanks for your thoughts...

Cheers

Claus

--------------------------------------------------------------------------

SAP_BW: 740, SP-Level 0011 (SAPKW74011)

CPMBPC: 801, SP-Level 0012 (SAPK-80112INCPMBPC)

Re: BW Info Objects assigned under wrong BW dimensions after transport

Former Member — Mon, 19 Sep 2016 17:40:56 GMT

HI Claus,

Why is this an issue? BW Dimensions don't play any role in BPC Model.

Do you have any errors because of this?

Regards,

Gersh

Re: BW Info Objects assigned under wrong BW dimensions after transport

Former Member — Tue, 20 Sep 2016 07:47:07 GMT

Hi Gersh,

thanks for your answer. It's not an issue as such. However, it's weird and I'd like to understand why that is. In particular since neither we haven't been facing this in the past nor have we applied any technical activities, such as full optimization. What's weird though is that exactly the same 'mixed up' assignment applies to the environment in our productive system as well.

So development shows the original state whereas quality and production show the dimension - info object mix up.

Cheers

Claus

Re: BW Info Objects assigned under wrong BW dimensions after transport

Former Member — Tue, 20 Sep 2016 08:15:21 GMT

BTW...

just need to add: We're running Exadata as our underlying database...

Maybe that's causing the issue.

Re: BW Info Objects assigned under wrong BW dimensions after transport

Former Member — Tue, 20 Sep 2016 13:39:41 GMT

Hi Claus,

If I remember it correctly InfoObjects are assigned to BW Dimensions in order of creation. So, if you changed the Model after initial creation or changed Dimension definitions that order could be changed. When Model is transported InfoObjects are assigned in alphabetical order.

Hence it can be different from original order.

Regards,

Gersh

Re: BW Info Objects assigned under wrong BW dimensions after transport

Former Member — Wed, 21 Sep 2016 11:12:18 GMT

Ok, thanks for these thoughts, Gersh.

However, we should be facing the same order between both systems, Development and Quality since if a model gets changed, then only in development.

I launched a call with SAP regarding this topic since my gut feeling tells me that it got something to do with the in-memory database (Exadata) that we are running underneath. Dimension table don't play a role in the creation of the underlying flat tables and hence it could be that this topic is somehow related to this.

And I agree, in BPC, we should not be facing issues, especially not when staying < 13 dimensions. However, in BW info objects get assigned to dimensions by purpose and under performance considerations. And if that intended design changes in the target system of a transport, then I would consider this a an 'undocumented feature', or - in short terms - a bug.

I'll keep you posted

Cheers

Claus

Re: BW Info Objects assigned under wrong BW dimensions after transport

Former Member — Wed, 21 Sep 2016 20:37:42 GMT

Hi Claus,

Why do you think that BW Dimension assignment should be same be same in both systems?

If you have less that 13 BPC Dimensions it doesn't matter what InfoObject assigned to what BW Dimension - performance will be same. If you have more than 13 Dimensions then distribution between systems can be quite different - it depends how much transaction data you have for each Dimension member and that can be different between Dev and QA.

I won't expect your DB plaing any role in this, but you never know:).

Bug is when something runs wrong - don't see anything wrong here.

Regards,

Gersh