cancel
Showing results for 
Search instead for 
Did you mean: 

What not to add to the InfoProvider

Former Member
0 Kudos
32

Would it be efficient to add the 0DOC_NUMBER to the InfoProvider. We have this InfoObject defined in the DSOs, but the users would prefer to report from the InfoProvider.

I am aware that the InfoProvider should not have the detail data defined but rather on summary data.

The reason for the requirement because there are some attributes related such as order reason and purchase order type.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

You could also include order reason and purchase order type in the Cube, and leave the 0DOC_NUMBER in the DSO.

Former Member
0 Kudos

I would have to enhance the datasource.

Former Member
0 Kudos

Hi Edna,

As per you question the Reporting Requirement is to show some Attributes of DOC_NUMBER and you have DOC_NUMBER at DSO level.

You can just add those Attributes directly in your Cube and Populate them via Update Rules from your DSO to Infocube.

I am suggesting this because adding DOC_NUMBER which is always a unique/new number will create a much larger dataset/Dimension in your Infocube, although you can always mark it as Line Item Dimension to improve performance. while Order Type will have only few 100 different values and will be repititive (denormalized).

Please let us know for furthere information/issues.

Thanks,

CK

Message was edited by:

Chitrarth Kastwar

former_member187400
Active Contributor
0 Kudos

Dear Edna,

Better if the operational data, the user(s) are asked to get it(the reports) in the source directly (R/3 for example). Ussually, BW is used for analyzing.

But if it must go through BW, I suggest you to use DSO/ODS to have detail report (operational data), using cube if only the data is for summary.

You can use index in ODS to make it faster.

Hopefully it helps.

Best regards,

Niel.

(Many thanks for any points you choose to assign).

Answers (3)

Answers (3)

Former Member
0 Kudos

There are several approaches to this.

1. I could enhance the standard datasource to include the purchase order type because this is the only one that is not there, and this will solve everything. But not sure about the delta extract for this field once enhanced.

2. I could put 0DOC_NUMBER in the InfoProvider and make it line item dimension. The order reason and purchase order type are attributes to 0DOC_NUMBER. This requires no user exit coding and datasource enhancement. No make suring if the delta will work for the field purchase order type.

3. I could do a multiprovider for the DSO and InfoPovider but I don't think you can mix the two because multiprovider is for InfoProviders only.

It seems that the way to go is item 1.

What are other approaches to this scenario?

Former Member
0 Kudos

Hi Edna,

The 1st Step is the most cumersome one.

By the way you can create a Multiprovider and DSO is available in That with other Infoproviders.

Why dont u try to add Attributes directly to your Infocube and Populate them via update Rules.

Please let us know your views.

Thanks

CK

Former Member
0 Kudos

Though it is practice not to store details in the cube, if the requirement is so, then you may.

Reporting from DSO will not be very encouraging.

Ravi Thothadri

Former Member
0 Kudos

hi,

Option1: you can provide the user a report on the DSO itself.This way u dnt have to add the field in the cube and the objective can be achieved.

Option2: If you have to build the report out of the cube you can add the 0DOC_NUMBER and make it a line item dimension.This will help in the performance of the queries too.

hope it helps,

regards,

Parth.