Есть кубик. У него куча правил обновления, все связаны с какой-то ODS, при этом с помощью одного правила обновляется только один показатель (так сложилось исторически).
Необходимо - добавить показатель, в котором бы проставлялось 1 или 0, если при обновлении ODS все показатели, кроме одного (он всегда один и тот же) - нулевые. Показатель в BEx-отчете должен выводить сумму единичек не только для просмотра (чтобы понятнее -http://sapboard.ru/forum/viewtopic.php?t=18927 ). Комбинации признаков в ODS - разные.
Обновляться может как один показатель, так и все по очереди, цепочки пока нет.
Решаю в каждое правило обновления добавить обновление своего нового показателя. Перед тем, как загрузить абапера работой - подумала: если вопрос решается только грамотным абап-кодом в котором четко прописано:

признаки 1, 2, 3: показатель 1 <> 0 и
признаки 1, 4, 5: показатель 2 <> 0 и
признаки 2, 4, 6: показатель 3 <> 0
показатель 4 = 1
признаки 1, 2, 3: показатель 1 <> 0 и
признаки 1, 4, 5: показатель 2 = 0 и
признаки 2, 4, 6: показатель 3 = 0
показатель 4 = 0

То как система "сообразит", какой показатель из двух в правиле (старого, в который данные ложатся из ODS и нового, с подпрограммой) ей обновлять первым, какой вторым? Или это тоже прописывается в коде?
Может кто-то подскажет более красивое решение?

Делай через Start Routine.

Там все показатели/признаки в одном пакете доступны как в таблице.

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

Может дождаться пока все показатели из всех источников прогрузятся, а потом зафигачить из самого в себя с обработкой в стартапе?

Если для каждого показателя есть отдельные правила обновления, тогда лучше сделать еще один промежуточный проверочный ОДС, куда складываются все показатели. А затем из ОДС - в куб.

Коллеги, спасибо за подсказки вам и не только
Сейчас прорабатываю в голове как раз 2 варианта - промежуточный ОДС/Куб или загрузку в самого себя, и абапчегом его, абапчегом (бедный абапер, он еще болеет и ничего не знает )

Задача немного упростилась. Нашлась некая комбинация признаков Х, которая одинакова для всех показателей. Еще есть некий признак У (заполняется только для показателя 1); в совокупности с этой комбинацией Х однозначно определяется показатель 1.

Тогда абапом необходимо проверить: если комбинация Х+У есть для показателя 1, , то: если кобминация Х есть для показателя 2 или показателя 3, то показатель 4 = 1 (для комбинации Х+У). При этом у показателя 2 и показателя 3 может быть еще куча всяких признаков, различных и одинаковых.
По умолчанию показатель 4 = 0.

Сработает? Или абапер меня погонит поганой метлой?

З.Ы. Пока делала тестовый кубик - обнаружила, что правила обновления можно копировать
Только вот активироваться они хотят после небольшого танца с бубном - надо вызывать на изменение любой показатель, внимательно посмотреть, сказать "ахалай-махалай" и закрыть диалоговое окошко

Почему, на мой взгляд ОДС лучше.

1. Возможность избежать кумулятивности. Нужные показатели обновляются в нужном месте и в нужное время без проблем.

2. Есть опыт использования проверочных ОДС. Как верно подметил BW-ник данные идут пакетами, и есть вероятность, что некоторые данные будут лежать в разных пакетах. ( Не буду вдаваться в технические дебри, как у нас на проекте тут некоторые "мастера" обходили это статическими данными, накапливая нужные порции в таблицах, и так далее.) Проверочный ОДС - проще, и в нём уже доступны все данные для выборки путём использования простого оператора SELECT FROM /BIC/AИМЯ_ОДС

Подобный успешный опыт у меня перед глазами. У нас такая же байда с интерфейсом из APO. Всё сделано на update rules/start routine и проверочных ОДС.

Решила попробовать загрузку кубика самого в себя, пока что без обработки в стартапе, просто нолики забить
1) Загрузила в куб данные из всех ОДС
2) Добавила в куб показатель 0AMOUNT
3) Создала инфоисточник, правила обновления, пакет.
4) Запустила пакет - монитор висел час в желтом статусе с 0 из 0 записей, после чего мои нервы закончились.
5) Однако показатель 0AMOUNT в изменении кубика из черного стал синим, т.е. в нем есть данные (нолики эти самые) и для удаления он не доступен
Что я сделала не так?

Уже на этом этапе в 0AMOUNT записались нолики. И удалить теперь его нельзя...

йасно, спасибо!!! ЭТО ЖЕ ХОРОШО!!!

Все ок, надо было ждать 2 ЧАСА!!!
Данные конечно же задвоились, ну ладно, пока поковыряюсь сама