Есть инфокуб, в котором хранятся данные за несколько лет
хотим изменить модель таким образом, чтобы на каждый год был отдельный куб
создали несколько кубов в них прописали константы соответствующие для признака год и повесили эти кубы на один ОДС
слышал такое, что можно настроить все так чтобы из ОДС автоматом данные при обновлении в кубы попадали в нужный куб в зависимости от года
но у нас все равно BW gdnftncz загрузить данные из ОДС во все кубы и при этом возникают ошибочные загрузки в кубах, в которых год не совпадает с прописанной константой (пишет что ожидалось значение 2007 например вместо 2008)
можно ли как-то сделать чтобы данные из ОДС грузились по тольк нужным кубам без ошибок?

Подпрограмма в правилах обновления?
Грузить полностью за все года во все кубы и если в текущем кубе год <> константе то эту запись не обновлять?

Есть такое, "правила обновления" называются... Но лучше фильтрануть в инфопакете...

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

А что разве на каждый куб не надо своё правило обновления делать? (по крайней мере у меня в 3.5. так)

На самом деле в SAP есть такая галка - ее только нужно найти и чекнуть - и SAP будет внедрен!

Только тс-с-с-с, никому!

1. Создаёшь кубы для каждого года.
2. Объединяешь их в мультипровайдер.
3. Делаешь трансформацию ODS -> куб
4. Создаёшь DTP с полной загрузкой и фильтром на год.
5. Создаёшь DTP с дельта загрузкой и фильтром на год.
4й DTP запускается при первоначальной загрузке данных,
5й DTP ставишь в цепочку, следом активация данных.
Фильтры на DTP работают хорошо и проблем не должно быть (если стоят все обновления на системе и т.д.).
Всё написано для 7-ки. Если будут вопросы - задавайте.

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

LOOP AT DATA_PACKAGE.
if DATA_PACKAGE-FISCPER(4) ne '2007'.
DELETE DATA_PACKAGE.
endif.
ENDLOOP.

для 2008
LOOP AT DATA_PACKAGE.
if DATA_PACKAGE-FISCPER(4) ne '2008'.
DELETE DATA_PACKAGE.
endif.
ENDLOOP.
и т.д.

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


To Vitaly V.V.:
Если я пишу на форум вопрос, то ожидаю, что мне ответят.
А если Вы не в состоянии или не хотите нормально отвечать, то просьба молчать.

Не всегда одинаковый код является хорошим решением. Если последний созданный куб предназначен для 2008 года, то он должен будет принять и данные 2009 года, если куб-2009 по каким-то причинам не будет создан вовремя.
И, возможно, следующая конструкция работала бы быстрее:

И не стОит так нервно реагировать, Vitaly V.V. Вам мягко намекнул, что не следует ожидать, что на все случаи будут галки, потому что кубы могут понадобиться, например, и для отдельных кварталов и для месяцев.

спасибо,
попробуем и такой вариант, может и правда быстрее будет

delete DATA_PACKAGE where not ( FISCPER between '200701' and '200716').

Дались Вам правила обновления. Они уже морально устарели.
Пользуйтесь фильтрацией на DTP для трансформации.

Только, конечно, не '200701' и '200716', а '2007001' и '2007016'.
Похоже, можно было пойти и Вашим путем, но только

http://help.sap.com/saphelp_nw04/helpdata/en/33/dc2038aa3bcd23e10000009b38f8cf/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/0a/cd6e3a30aac013e10000000a114084/content.htm

Кубы, объединённые в мультик представляют собой как-бы фзический индекс на уровне объектов хранения. Стейджинг машина при выборе с ограничением года не будет трогать объекты, где этого года нет, а выборка по меньшему числу записей (по кубу одного года) будет быстрее.
Так что такая сегментация имеет определенные преимущества. Задумка изначально правильная. Только надо сделать, чтобы быстро и правильно работало.

вы путаете физическое партицирование таблицы E и логическое партицирование провайдерами.
В приведенном примере кубы логически разделяются константой...это вовсе не обязательно год, просто чаще всего именно год.
Физически их я бы еще побил либо по 0CALMONTH либо по 0FISCPER - смотря что в отчетности используется.

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

Обратите внимание на режим выполнения запроса в RSRT - будет ли он выполняться у вас параллелmно или последовательно. И сделате выводы

Так же проанализируйте поведение "точки сбора" данных на реальном объеме данных - и так же сделайте выводы и соответствующие настройки

Полезно еще подумать о количестве выделяемых диалоговых процессов на выполнение запроса на мультике и сделать коррекцию настроек с учетом ваших реальностей

так же рекомендую просмотреть ноту 911939 - она явно вам поможет

По всем этим вопросам смотрите ноты - в них очень подробно все расписано.