помогите все-таки разобраться!

из справки по FOX'у нашел:

т.е. перед выполнением кода функции выполняется две выборки: из фильтра- original selection и из определения функции- reference data selection, и одна другой дополняется...
У меня вопрос - если "original selection" не содержит ни одной записи данных, то reference data selection не выбирается? и функция соответственно выполниться не может?

Выбирается. Может. Если есть FOREACH ... IN REFDATA

а если не нужен foreach?

простой пример
в кубе содержиться:
amount Rate version
'0' '0,1' '1'
'100' '0' '2'

нужно переложить amount на версию 3 умножив на rate, т.е. создать запись:
amount Rate version
'110' '0' '3'
ставлю в фильтре версию 3 (соотв. выборка будет пустой), код фокса:

{amount}={amount|version=2}*{rate|version=1}.

не работает), 0 считано, 0 создано, 0 изменено, 0 удалено.
почему? ведь поидее выборка ссылочных данных должна сработать по условиям "version = 2 or 1"

Введите версию в операнд.
А в фильтре оставьте все как есть.
Есть нюанс с обращением к реф.данным через "|", они действительно не работают если нет данных в блоке.
Это как обмен между блоками данных (сквозной).

P.S. К сожалению не встречал вменяемого описания работы с ними. Все опытным путем.

Придумайте, как его вставить. Цикл, который отработает только один раз - это тоже цикл
С FOREACH все начинает работать

Мне кажется, что из другого уровня агрегации данные точно не могут попадать в функцию планирования, но в рефдата, наверное, могут попадать данные не из фильтра?
Но я бы все равно хотел бы услышать более полное объяснение, что такое foreach ... in refdata. Объяснение типа "refdata - это правая часть формулы" выглядит непонятно.

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

Нет. Refdata - это данные из того же уровня агрегации, но которые могут выходить за ограничения текущего фильтра. Для полного просветления надо гонять функции планирования в режиме трассировки, чтобы понять какие записи появляются в Before, какие в After, а какие в reference data. Формирование Refdata происходит в момент компиляции функции планирования перед запуском.

http://help.sap.com/saphelp_nw73/helpda ... ameset.htm - тут есть про refdata

Спасибо за ответ.
Увы, просто я выразился не совсем по-русски. Я также имел ввиду, что данные с того же самого уровня агрегации, но, что набор данных получается во время запуска-компиляции экземпляра функции выборкой всех записей уровня агрегации, если выборку ограничить теми признаками и их значениями, которые представлены в блоке, для которого была запущена функция. Вот это предположение правильное?


Ну, я трассировку смотрел, на ее основе вот сделал предположение, но до конца не уверен в нем.

С одной стороны, в документации советуется по возможности избегать операторов foreach, поскольку они сильно влияют на производительность.
С другой, на этом форуме читал совет, что в фильтре и в изменяемых признаках надо указывать только тот срез, который действительно меняется.
С третей стороны, создавать дополнительные уровни агрегации тоже не очень хочется.
Чем же поступиться с точки зрения "бестпрактис" в моем случае?
Случай, например, такой:
в мультипровайдере два куба - для ввода и из ЕРП, в обоих есть признаки "счет", "партнер" и "статус", но в форме ввода нет аналитики "партнер" и введенные пользователем значения записываются с пустой аналитикой на "статус" = "рабочий".
мне надо написать функцию, которая для каждого счета проверяет общую сумму значений из ЕРП и введенную - они должны быть равны. Если не равны, надо вывести сообщение о том, по какому счету они не равны.
Нюанс в том, что следующая функция, если проверка прошла успешно, должна копировать данные со статуса "рабочий" на статус "утвержденный" и при этом аналитика "партнер" в данных из ЕРП не должна теряться, а копироваться как есть.
Варианты, как я понимаю, у меня такие:
1. Сделать для функции проверки отдельный уровень агрегации, с аналитиками "инфопровайдер" и "счет", без партнера, добавить счет в изменяемые признаки и в функции планирования просто сравнивать {KF,ERP, account} и {KF, manual, account} в конструкции foreach.
2. Запускать все функции на одном и том же уровне агрегации (на нем, соответственно, есть "партнер"), но сделать отдельный фильтр, который вернет данные с обоих провайдеров, добавить партнера в изменяемые признаки, чтобы исключить эту аналитику из определения блока, и делать вложенный foreach по партнеру.
3. Запускать все функции на одном и том же уровне агрегации (на нем, соответственно, есть "партнер"), использовать тот же фильтр, который используется для ввода, добавить партнера в изменяемые признаки, чтобы исключить эту аналитику из определения блока, и делать вложенный foreach in refdata по партнеру.

Я пока склоняюсь к варианту №3, но хотел бы уточнить, может быть лучше делать отдельный уровень агрегации, зато исключить вложенный foreach (вариант 1)? Или, с учетом того, что довольно много отзывов остранной работе refdata плюс, насколько я понимаю, foreach in refdata более затратная по ресурсам, поэтому сделать дополнительный и избыточный фильтр, но зато не использовать refdata (вариант 2)?

С моей точки зрения лучше всего выглядит вариант 1, но ему требуются изменения:
- account включается в уровень агрегации, но в функции он в свободных признаках, а не в полях для изменения
- функцию желательно запускать на фильтре ограниченном только инфо-провайдером = "manual"

т.е. что-то вида

FOREACH KF in refdata
razn = {KF} - {KF | 0INFOPROV = 'ERP'}
-- какая-нибудь проверка razn на равенство 0
ENDFOR.

C такой реализацией вы обезопасите себя от возможных проблем с блокировками в будущем, когда какой-нибудь другой пользователь захочет тоже прочитать данные из ERP-кубика, но не сможет этого сделать, из-за блокировки вашей функцией.

Также интересует опыт форумчан, занимающихся BI IP, в части выбора языка для функций планирования. В курсе написано, что использовать ABAP рекомендуется для функций с тяжелой логикой. В остальных случаях рекомендуется использовать FOX. Есть ли смысл использовать ABAP для простых функций? Возможно, есть увеличение производительности или какие-нибудь другие аспекты?

Практика показывает, что производительности хватает. FOX всё равно в ABAP интерпретируется. А поддерживать FOX попроще (код понятнее).
Для производительности работайте с фильтрами, чтобы в них как можно меньше данных попадало.

Наиболее производительно - это использовать функцию на абапе без создания блока.

Есть только одно правило - в фильтре должны быть только целевые данные. Остальные берутся из refdata.

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


Я бы не назвал это правилом. Например: есть несколько шагов расчета некоторого среза данных, лучше их все сделать на одном фильтре, чтобы объекты не плодить или вообще использовать для расчета фильтр запроса из книги. Вариантов много есть.

Для однопользовательского режима может и прокатит. Для одновременной работы большого числа пользователей - это прямой путь к срочному фиксу разных багов во время опытно-промышленной эксплуатации