Skip to Content
0

Composite Provider cannot be used as the base of an aggregation level

Dec 06, 2017 at 09:53 PM

337

avatar image
Former Member

I am trying to create an aggregation level on top of a very simple composite provider:

I have an aDSO with a couple of attributes in the union node that is write enabled. I have a join to a calculation view to get customer information and that is it.

I read that you cannot use Composite Providers for input enabled queries on a join that links to what you're trying to update, but that shouldn't be the case here as I have the union on the write enabled DSO.

Does anyone have any insight into why I'm unable to create this aggregation level?

UPDATE: I was reading this blog and thus the reason for thinking my solution below would work. I know one note mentions not being able to use a join for an input ready provider in a Composite Provider, but by attaching the input DSO by union, should this not work?

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Selva AM Dec 06, 2017 at 10:16 PM
0

Hi Ashley,

Can you post the screen shot of the error.

-- Selva.

Show 2 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Here is the error message I get when hitting Create

0
Former Member

And the long text

0
Gregor Dieckmann
Dec 07, 2017 at 03:01 PM
0

Hi,

it seems that you get message RSPLS142 (read the long text). The question is whether your HCPR (CompositeProvider) is consists of providers P (planning), R (reporting) with HCPR = P JOIN R or whether you have something like HCPR = P UNION (R1 JOIN R2) with R1,R2 reporting providers? The first is not possible as a basis of an aggregation level.

Regards,

Gregor

Show 2 Share
10 |10000 characters needed characters left characters exceeded
Former Member

This is what my Composite Provider looks like whereas as the DSO would be used for planning Join to CustomerSoldTo based on customer number for additional customer information. You're saying this is not allowed for planning purposes? What would be another approach to achieving this to where I can limit the data in the DSO and only use the calculation views for additional information?

0

Hi,

your use case seems to be equivalent to 'navigation attributes', so you may add CustomerSoldTo as an attribute in CustomerNumber master data table or you use a HANA view as a basis for CustomerNumber and map/use CustomerSoldTo as a navigation attribute. Then you need only the aDSO and no JOIN in the CompositeProvider.

Planning does not support joins in CompositeProviders with planning base providers since - in the general case - it is not clear how to 'split' the records to the planning enabled base provider.

Regards,

Gregor

0