Всем доброго утра! Или дня\вечера\ночи.
Вот такой вот вопрос, некие показатели должны посчитаться итерационно. Например мы имеем клиентов и сумму их покупок. А нам надо вывести что-то типа:
Кол-во всего клиентов, Ср. сумма, Кол-во клиентов больше

Ср. сумма определяется как сумма на всего клиентов, а кол-во больше - количество клиентов, сумма покупок которых больше, чем средняя. И в строках, например, пошла какая-то классификация клиентов, неважно. Но вот что важно, так это то, что клиентов легко может быть больше 68000 (т.е. вариант выкинуть отчет с агрегацией на уровне "клиент" и потом посчитать макросом отпадает) и то, что отчет такой делается за период времени, причем - произвольный (т.е. в этом случае не получится посчитать заранее). Таким образом получается, что в этом случае придется использовать virtual cube with services, правильно? В принципе, хаутушку нашел, буду изучать, но сильно нетерпеливо гложет такой вопрос, если у меня виртуальный куб определен на ФМ, то будут ли в момент запуска в этот ФМ передаваться параметры запросов, которые определены на этом кубе?

Ну и вообще - для этого ли придуманы такие виртуальные кубы и какие есть еще варианты (может более корректные) для реализации подобной задачи?

Что-то я не понял выделенный момент, какой в итоге вид должен иметь отчёт?

Да, это возможно, если позволят возможности сервера приложений, нагрузку такой куб может создать большую, особенно на память. Кроме того, откуда необходимо брать данные из ODS или куба?

Да, будут передаваться списки необходимых признаков и показателей, ограничения на признаки и ключевая дата.

Думаю, что для этого их и придумали, а кроме макросов вариантов не вижу.

Ну например:



Ну макросы не подойдут, поскольку клиентов-то может быть больше, чем вмещается строк в екселе. Или Вы имели в виду как раз виртуальный куб на базе ФМ?

Да, по поводу ODS или куб - я пока об этом не думал, а это важно? В том смысле, что из куба будет в ФМ сложнее выбирать данные? Или в принципе может отличаться реализация?

Такой отчёт должен пойти без проблем.
Я имел ввиду, кроме виртуальных кубов и макросов, а раз макросы отпали, то только ФМ писать, может кто другой проще подход предложит.
Про ODS и куб, на простых запросах можно для ODS в рукопашную select написать, для куба это сомнительно. А для сложных запросов надо использовать, например RSDRI_INFOPROV_READ_RFC с DESTINATION 'NONE', правда разбирать его вывод весьма нудно.

Вызов выглядит примерно так:

CALL FUNCTION 'RSDRI_INFOPROV_READ_RFC' DESTINATION 'NONE'
EXPORTING
i_infoprov = Z_INFOPROV
i_reference_date = z_keydate
i_save_in_table = z_false
i_save_in_file = z_false
i_authority_check = z_authchk
i_rollup_only = z_space
importing
e_end_of_data = e_end_of_data
TABLES
i_t_sfc = g_t_sfc
i_t_sfk = g_t_sfk
i_t_range = l_t_range
e_t_rfcdata = g_t_rfcdata
e_t_field = g_t_field
EXCEPTIONS
illegal_input = 1
illegal_input_sfc = 2
illegal_input_sfk = 3
illegal_input_range = 4
illegal_input_tablesel = 5
no_authorization = 6
ncum_not_supported = 7
generation_error = 8
illegal_download = 9
illegal_tablename = 10
data_overflow = 12
others = 13.

IF sy-subrc <> 0.
raise read_access_error.
ENDIF.

CALL FUNCTION 'RSDRI_DATA_UNWRAP'
EXPORTING
i_t_rfcdata = g_t_rfcdata
CHANGING
c_t_data = g_t_data.

И еще вот это может будет полезно:

https://www.sdn.sap.com/irj/servlet/prt ... fba451d6ac

Спасибо большое за подсказку! Нудно-то нудно, главное - что возможно и пользователя удовлетворить.

может для этого отчета лучше будет виртуальный показатель посчитать ?

надо попробовать решить задачу на BEx.

Самое интересное здесь разобрать что-ж в этом самом g_t_data два дня помню голову ломал.


Во, точно, ещё один вариант это BADI, но абапить надо не меньше, чем при сервисном кубе.

Сервисный куб, будет работать через BEx, как и обычный.

[quote="EvgenySA"]
Самое интересное здесь разобрать что-ж в этом самом g_t_data два дня помню голову ломал.



Есть примерчик, помогает.

Report RSDRI_INFOPROV_READ_DEMO

Может быть, хотя сложно представить принцип - не придется ли для этого, "просматривать" все данные для каждой строки отчета? Но я обдумаю этот вариант, спасибо.

RSA1
Очень полезная информация - спасибо за советы.

Видел я его, он помог слабо (я особо восхитился представлением навигационных атрибутов), больше помог отладчик и просмотр кода, который работает внутри RSDRI_INFOPROV_READ_RFC.

Так а может Вы тогда поделитесь своими результатами? Впрочем - если это Ваше "ноу-хау", то вполне обоснованно.

Ничего особо секретного там нет В include LRSDRIF05 FORM generate_read_write_report можно найти как определить тип строки возвращаемой таблицы g_t_data (CALL FUNCTION 'RSD_TNAMES_GET_FOR_CUBE' и далее). А в include LRSDRC_SELDRF10 FORM set_chaalias, который превращает имя навигационного атрибута '0MATERIAL__0MATL_GROUP' в 'S003_0MATERIAL', есть ещё FORM set_kyfalias для показателей.