#TOREFRESH

Для того, чтобы избежать ошибки #TOREFRESH в ячейке webi отчета при добавлении какого-либо нового показателя на лист можно пойти на хитрость и в юниверс-дизайнере принудительно установить способ требуемой агрегации для показателя (меры). Обычно это SUM. 

По умолчанию агрегация делегируется от источника - "БД делегирован".

Так же иногда помогает при #UNAVAILABLE

Не отображаются сведения в webi

Была такая проблема, которую никак не могу объяснить.

Имеем бекс на кубике. В кубике есть инфообъект. У него есть атрибут - "Дата создания".

Бекс вытягивает этот инфообъект и его атрибут, и отлично отображает.

Webi как известно, игнорирует атрибуты, которые мы выводим в бексе. Он видит абсолютно все атрибуты признака, поэтому в бексе их можно не выводить дополнительно. Но, отображает, к сожалению, не все. Например, в данном примере не отображает дату.

Атрибуты webi видит как "Сведения". 

Проблема самоустранилась с переходом на 7.4 on HANA.

Формула

В правиле преобразования формулы RIGHT, LEFT работают в два раза быстрее, чем SUBSTRING:

Мелочь, а приятно.

DTP перестал забирать записи

Возникла странная ситуация на BI7.4 on HANA. Запросы загружались в PSA в нулевую таблицу /BIC/B000xxx000. Далее забирались вверх потоком. Через 16 минут они почему-то стали загружаться уже в первую таблицу /BIC/B000xxx001. Дельта DTP их по прежнему забирал, но передавал 0 записей. 

Источник не был изменен за это время. Объем - примерно 40-50 записей.

Исправить удалось так:

1. Откатил все последние запросы из таблицы /BIC/B000xxx001

2. Убрал в DTP оптимизацию под HANA

3. Заново запустил DTP - процесс увидел записи

4. Снова включил оптимизацию под HANA

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

Ошибка при активации DSO

В исходной ERP системе была одна запись из трех миллионов, в котором одно поле было, видимо, null. 

При инициализации дельты эти три миллиона записей из PSA передавались в DSO и активировались там около 3х часов. В итоге на одной записи активация падала со словами что-то вроде "Can'not generate SID for object 'iOBJ' value ''". Соответственно даже зная объект, отловить эту некорректную запись было не возможно. 

Коллега подсказал такой кусок кода в rule routine к этому объекту:

data: lv_char(60) type c.

lv_char = source_fields-iobj(60).

replace all occurrences of regex '[[:cntrl:]]' in lv_char with ''.

result = lv_char.

Что такое '[[:cntrl:]]' мне не понятно, но кривого значения как небывало.

Импорт объектов

При импорте запросов особенно часто возникают ошибки из-за отсутствия объектов в целевой системе. Я для себя выработал следующую стратегию:

• Разделяю все активируемые объекты на разные запросы, и импортирую их в следующем порядке:

1. Инфопровайдеры
2. ABAP
3. Источники
4. Инфопакеты
5. Инфообъекты
6. ETL  - Трансформации, DTP, рутины
7. Цепочки процессов
8. BEx

• Перед импортом захожу в RS09. Транзакция показывает объекты в запросе с соответствующими иконками - визуально можно оценить все ли хватает
• Перед деблокированием копий жму Shift + F12 - Моделировать деблокирование. 
• Захожу в "Связь с переносом", выбираю просмотр списком, выбираю нужный измененный объект. Как известно инструмент этот опасный, может захватить лишнего, поэтому отменяю весь выбор и вручную прощелкиваю объекты и расфасовываю их по разным запросам.

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

Неудачный импорт объекта ELEM

Часто бывает так, что при импорте запроса возникает ошибка с восьмеркой - объект ELEM такой то не импортирован. Без объяснения причин. Скорее всего это происходит, когда мы корректируем BEx запрос, в котором присутствуют некоторые объекты, созданные непосредственно на инфопровайдере, а не в запросе. При этом объект может находится в локальных объектах, либо не донесен до целевой системы по ландшафту. Поэтому при импорте объектов запроса в целевую систему TMS не пишет ошибок, однако на стадии активации  BEx запроса выясняется что тот или иной объект отсутствует, поэтому активация query (объект REP) не возможна.

Понять какой именно объект отсутствует в целевой системе можно двумя способами. Посмотреть в таблице RSZELTDIR описание объекта, вспомнить в каком query он используется и добавить его в запрос на импорт, либо непосредственно найти через "Связь с переносом". Тип объекта (запрос, фильтр, показатель, расчетный показатель и т.д.) можно узнать из таблицы. Так же можно посмотреть в SE03, может быть он уже где то блокирован, поэтому не захватился при активации query.

Визуально заранее оценить целостность запроса на импорт к сожалению не возможно. При импорте двух-трех более менее сложных отчетов можно получить более двухсот объектов в запросе.