Помогите пожалуйста решить проблему.
Проблема в следующем - при погрузке данных допустим из одного ODS в другой ODS (1 млн. записей) система SAP BW динамически разбивает данные на пакеты по каким-то своим соображениям и грузит каждый пакет отдельно. Как быть если необходимо загружать данные одним пакетом, например для расчета в правилах обновления средневзвешанных величин понадобиться сначала сложить все записи по нужным ключам, а потом найти средние величины и только потом загрузить. Все эти моменты решаются в правилах обновления на ABAP, но из-за того что система делит данные на пакеты при погрузке - беруться не все записи для расчета средневзвешанных, а часть данных одного пакета.
Кто сталкивался с этим и знает как заставить данные грузиться одним пакетом в ODS ? Либо как объединить эти пакеты в один в подпрограмме запуска или еще где-нибудь.
Существует-ли какая-нибудь переменная в правилах обновления где возвращается число пакетов ? Типа RECORD_NO, RECORD_ALL для записей. Готов выслушать любые советы по этому вопросу.

Объединение в один пакет 1 млн записей? да у вас система раком встанет ....

Не проще ли в стартапе сделать чтение данных из ods ( только тех которые нужны для расчета средневзвешенной для данных в конкретном пакете) и потом уже в правилах использовать считанные данные?

Вопрос к BW-шнику.
Что подразумевается под стартап.
Программа запуска в правилах обновления ?
В настоящее время пытаемся решить проблему в правилах обновления в таблицах возврата - считыванием SELECT всех данных из таблицы активных данных ODS во внутреннюю таблицу и дальше работаем циклом по внутренней таблице. Таким образом теперь не привязаны к делению данных по пакетам и COMM_STRUCTURE в приципе.
Если я все таки угадал про программу запуска, что там должно реализовываться согласно вашего плана.

Эй, эй. вы там без фанатизма...

стратап - это подпрограмма запуска. Выполняется ОДИН раз на пакет. В ней считайте данные из ods ( только не селектами, а c помощью ФМ RSDRI_INFOPROV_READ) во внутреннюю таблицу. А в собсвтенно в правилах читайте данные из этой внутренней таблицы. А то по вашему получается, что вы на КАЖДУЮ запись будете выполнять селекты - у вас все равно база раком встанет - вы прикинте - выполнить миллион селектов! это ж застрелиться можно!

Кстати, дял таких случаев рекомендую почитать курс 360 - оптимизация. В нем все здорово расписано, что и как надо и не надо делать...

Спасибо за советы BW-шник.
Может-быть направите как вызвать или объявить функциональный модуль в программе запуска. Раньше не работал с ФМ.
Кстати по поводу миллиона SELECT - если поставить условие перед селектом IF RECORD_NO = RECORD_ALL то селект будет выполняться столько раз, на сколько пакетов поделяться записи при погрузке в ODS - а это уже разы, а не миллионы раз.

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

И последний вопрос - кто сталкивался с таким - почему в правилах обновления работает только построчный SELECT - конструкция:
SELECT * from Активная таблица.
.................
ENDSELECT.
А одной операцией не выходит:
SELECT * FROM Активная таблица into Внутренняя таблица.
Последний код работал-бы намного быстрее.

Проблему решили. Создали инфо-источник для плоского файла. Загружаем одну запись. В подпрограмме запуска считываем из ODS где лежит 1 млн. записей.
SELECT * FROM Активная таблица into table Внутренняя таблица.
И делаем все необходимые операции. Потом в таблице возврата для каждого поля данных считываем из конечной внутренней таблицы в RESULT_TABLE в конечный ODS.
Если кто знает как оптимизировать процесс - напишите.
При обновлении из одного ODS в Другой возникает вопрос, как заставить выполняться SELECT один раз, а не количество раз = количеству динамических пакетов.
В частности как узнать в подпрограмме запуска (откуда можно считать) количество пакетов данных.
Либо как применить ФМ в подпрограмме запуска о котором написал BW-шник.