Agregation level exit variable problem

[Former Member]

Hi Dear All,

I'm trying to use cmod variable for agreggation level in input-ready query . I have one real time cube and two different agregation levels.

Exit checks comp_code value (which is processed by authorization, single value) and get  infoprovider variable value (single value), and it works but query is locked for input.When I use constant value of agregation level in query, it is unlocked.  I made tests in rsrt and values for comp_code and agregation level are filled correct way. We have BW 7.01.

query locked for input even if I hardcode value of infoprovider  in exit, I checked it on  I_STEP = 1 and I_STEP = 2.

        l_s_range-low   = 'ZPF_LEVEL'.
        l_s_range-sign  = 'I'.
        l_s_range-opt   = 'EQ'.
        APPEND L_S_RANGE TO E_T_RANGE.
      ENDLOOP.

Can anybody explain me why input is locked?

[Former Member · Accepted solution]

Ive got some time to close topics.

At the end we found the way to make query unlocked.

There was two aggregation levels for one multiprovider and one query. One level contained cost_center and another did not, because some comp_codes had cost_centers and some did not.
The idea was to  fill  aggregation level value by user-exit, depending on comp_code value.
The decision is to use # for cost_center variable if we choose comp_code without cost_center.
So there was no reason to use two different agg.levels.

Thank you all.

[gregor_dieckmann]

Hi,

I think you use a multiprovider; is the aggregation level on top of the multiprovider or are the aggregation level contained in the multiprovider?

Since you want to use a variable for 0INFOPROV that sets the aggregation level based on comp_code I assume the latter.

When you define a query on an InfoProvider the system determines the characteristics to be included in the query (rows, columns, free and restricted key figures) needed to cover the aggregation level used. Since the aggregation level determines the granularity (delta-) records will be inserted in the InfoCube the query has to contain all these characteristics.

Having a variable for 0INFOPROV in the query the system at query generation time does not know the InfoProvider used, so more characteristics will be required to make cells input-ready, mabe all characteristics used in the multiprovider. The needed characteristics will be added as free characteristics. You can check this in RSRT, press the 'Generate' button and check the messages.

As a result, using the variable the query is not input-ready since additional free characteristics are not restricted to a single value (and are not drille-down).

Regards,

Gregor

[Former Member]

Moreover I tried to use input-ready variable for infoprovider, and same...data input is locked.

[Anand71]

Hallo,

I thibk code is ok.

Try to use infoprovider variable at key figuer Level and also at same time in global filter on query.

Regards,

Anand Kumar

[Former Member]

Anand, I tried to add variable to global filter and key figure filter (in key figure restriction in query, as I undestood) same time, but it doesent help.

Code is  correct, because rsrt test is ok, and both variables are filled.

Cornelia, your idea works, but we can't use it because it wouldn't be possible to add new rows by user (in WAD) to cube, we need this option.

Regards,

Nadya

[cornelia_lezoch]

Hi Nadya,

can´t you put the char into columns, set it in advanced settings to "show according master data"?

regards

Cornelia

[cornelia_lezoch]

Hi Nadezhda,

I am not a programmer, so I am not sure about the code.

I compared with code my ABAP-guis were defining and there is an additional

CLEAR l_s_range-high.

before the append.

otherwise try what I suggested in the first reply - put the characteristic (infoprovider and if comp-code is strangely selected also this one) into the drill down.

regards

Cornelia