Виртуальный куб на основе ФМ

murmur

Есть виртуальный куб и ФМ, реализующий его логику. В параметрах ФМ-у передаются 2 таблицы: одна с глобальными параметрами (фильтр запроса) и локальные ограничения на показателях

*" REFERENCE(I_T_RANGE) TYPE RSDRI_T_RANGE OPTIONAL
*" REFERENCE(I_TX_RANGETAB) TYPE RSDRI_TX_RANGETAB OPTIONAL

Мне надо всю логику ФМ-а, которая была ранее, подменить вызовом данных из нового мультипровайдера. Для этого пытаюсь использовать ФМ RSDRI_INFOPROV_READ, но в нем нет эквивалентного параметра I_TX_RANGETAB. Как можно выкрутиться из данной ситуации (I_TX_RANGETAB должна обязательно присутствовать в параметрах - это важно)? Может есть какие-то альтернативные модули чтения мультипровайдера, где все параметры соответствуют?

Rozoviy.Slon

Можно попробовать воспользоваться методом READ класса CL_RSDRI_INFOPROV, если не пугает страшная надпись рядом с этим параметром (I_TX_RANGETAB TYPE RSDRI_TX_RANGETAB): "For internal use only: do not use!".

refeline

стандартный код примерно такой (пишу по памяти, надо проверять):

Code:

DATA:
  l_t_range type rsdri_t_range.

  l_t_range[] = i_t_range[].

  loop at i_tx_rangetab assigning <l_s_rangetab>.
     append <l_s_rangetab>-t_range to l_t_range.
  endloop.

i_t_range - глобальные фильтры
i_tx_rangetab - фильтры для элементов структур

murmur

Таким кодом вы логическое выражение V1*(V2+V3+V4) раскрываете как V1*V2*V3*V4, что неправильно. Так что "зелененькая штучка" остается за Розовым слоном

где
V1 - i_t_range - глобальные фильтры
V2, V3, V4 - i_tx_rangetab - фильтры для элементов структур

refeline

На самом деле.
Ну тогда надо галочку поставить "Использовать только глобальные условия выбора" у кубика и вообще не использовать I_TX_RANGETAB.

А что, от зеленых штучек есть какой-то профит?

murmur

Не использование I_TX_RANGETAB приведет к тому, что данных будет больше извлекаться, и разбиваться запрос на несколько подзапросов (по крайней мере в моем случае) не сможет.

refeline

Если уж виртуальник для отчетности, то зачем он вообще такой нужен с большими объемами данных...

murmur

Ну это уже просто философия пошла...

refeline

Софистика...
Ну, как я это вижу... Если источник данных будет DSO, то навряд ли будет профит от нескольких запросов к нему. Если это кубы, то можно подумать еще о целесообразности анализа критериев для FEMS... кэш для подзапросов и все такое.
Интересно, что будет в случае, если есть показатель без фильтров и другой с фильтрами - получается, что все равно нужны все записи... как-нибудь надо посмотреть что передается в I_TX_RANGETAB.

Если найдете красивое решение, отпишитесь, будет интересно посмотреть.

Виртуальный куб на основе ФМ

Кто сейчас на конференции