Миграция SAP Business Objects с BOXI 3.1 на BI 4.0: подводные камни

Долго ли, коротко ли...

В нашей компании недавно завершилась миграции с SAP Business Objects с BOXI 3.1 на BI 4.0. Сразу скажу, необходимость миграции была инициирована головной компанией, поэтому никакого предварительного ассесмента на применимость новой версии у нас не приходилось.

Но, как говорится, «партия сказала «Надо!», народ ответил «Есть!», поэтому миграцию мы начали с этой вводной, столкнувшись с огромным количеством подводных камней.

Итак, переводу на новую подлежало около 100 отчетов SAP Business Objects.

Большая часть была перенесена «влегкую», но те отчеты, которые содержали хоть сколько-нибудь сложную логику, благополучно перестали работать.

Основные проблемы, которые были идентифицированы:
1. Значительное увеличение скорости первичной загрузки отчетов до 20 раз (те отчеты, которые загружались 2-3 минуты на BOXI 3.1, стали загружаться по 40-50 минут). При этом объем данных не изменился, и скорость загрузки от объема данных также сильно не зависило, отчеты на 50 000 строк выгружались на 3-5 минут дольше тех, которые содержали 1500-2000 строк.
2. Невозможность настроить доступ для групп пользователей на уровне юниверса. При попытку ввести ограничение возникала ошибка Row Restriction, при этом возможности упростить код ограничения не было.
3. Невозможность «развертывания» отчетов в режиме онлайн
4. Невозможность передавать параметры при переходе из одного отчета в другой (параметры «скидывались»)
5. Невозможность опубликовать Query as a web-service (aka QaaWs или «квасы») в тех случаях, когда у получаемых данных более одного контекста в юниверсе. А значит – невозможность получить доступ к данным, получаемым из связанной системы с использованием этого функционала SAP Business Objects.

Часть этих проблемы мы смогли решить самостоятельно, часть потребовала эскалации в российский и даже немецкий SAP. Итого все проблемы были решены, как – см.ниже.

1. Значительное увеличение скорости первичной загрузки отчетов до 20 раз.

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



А остальное время затрачивается на вызов и отработку функции GetPages. Механизм построения отчета генерирует отчет и использует спецификацию отчета (XML flow) и диапазон станиц для управления визуальным отображением отчета.

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

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

2. Невозможность настроить доступ для групп пользователей на уровне юниверса

При попытке добавить New Restriction для таблица HRCY и добавить условие WHERE появлялась ошибка «wrong SQL syntax», связанная с тем, что код ограничения стал «короче», т.е. уменьшилось количество символов, которые можно было использовать.



К сожалению, сокращению наш код не подлежал, поэтому было найдено обходное решение – создание и использование аналогичной вьюшки в БД.

Позже, силами компании SAP, неожиданно было выяснено, что, несмотря на возникающую при создании New Restriction ошибку, ограничение все равно применяется и отрабатывает корректно, поэтому наши пляски с бубном вьюшкой оказались напрасны.

3. Невозможность «развертывания» отчетов в режиме онлайн

Часть отчетов содержали сложную иерархическую структуру, которая должна была «разворачиваться» по клику, но в обычном режиме просмотра отчета не разворачивалась (по клику на кнопку развертывания отчет обновлялся, но оставался прежним по структуре).

Как оказалось, в BI4.0 развертывание усложнилось.

Для этого необходимо из режима чтения отчета переключиться в режим Design -> Structure Only и уже в режиме структуры:
1.Нажать на стрелку вниз на том уровне иерархии, который нужно развернуть.
2.Выделить строку с нужным уровнем иерархии и дождаться появления вертикального столбца в области развертывания со стрелкой вниз.
3.Нажать стрелку вниз в этом столбце.
4.Переключиться обратно в режим чтения отчета.



Как мы видим, процесс сильно усложнился и стал неудобен для конечных пользователей отчетов. Поэтому нами было принято решение создать количество дублей отчета по количеству уровней иерархии (общим числом шесть), настроить в каждом из них нужную степень раскрытия иерархий и соответственно переименовать их.

Это усложнило поддержку отчетов, но упростило работу пользователей.

4. Невозможность передавать параметры при переходе из одного отчета в другой (параметры «скидывались»)

Большинство отчетов имели функцию drill-down, т.е. переход на другой отчет Business Objects для детализации текущего (например, переход к проводкам с баланса). Переход выполнялся с использованием функционала opendoc.

В ссылке opendoc передавались параметры головного отчета, определявшие объем данных для загрузки детализации. Ссылка выглядела примерно так — https: //BOXI31/OpenDocument/opendoc/openDocument.jsp?iDocID=AV9oOenNSttBja9P6142Tw8&sIDType=CUID&sType=wid&lsMYear="+URLEncode(""+[Year])+"&lsMgroup1="+URLEncode(""+[Cost Centre Group 1 Code])+"&lsMHierarchy%20Type="+URLEncode(""+[Hierarchy Type])+"\" title=\"\" target=\"_blank\" nav=\«doc\»>"+[Cost Centre Group 1]+""

При переходе по этой ссылке открывалось окно параметров, где уже был подставлен уровень иерархии и год, и пользователю оставалось выбрать только месяц(ы), данный процесс был удобен бизнес-пользователям.

В BI4.0 оказалось, что параметры головного отчета не «подхватываются», т.е. помимо месяца бизнес-пользователю необходимо выбирать год и (о, ужас!) уровень иерархии, что не всегда удобно. Более того, многие пользователи – потребители отчетов – понятия не имеют (и не должны, в общем-то, иметь) какой уровень иерархии им нужен.



К сожалению, стандартных средств для исправления этого в BI4.0 не оказалось, поэтому был найден обходной путь – подчиненный отчет был перепрограммирован так, чтобы при переходе по ссылке с головного в него загружались все месяцы года, а год и уровень иерархии передавались по умолчанию.
Теперь при необходимости изменить количество месяцев или год пользователям необходимо нажать «Обновить» в уже построенном drill-down отчете ( туда все параметры могут быть подтянуты автоматически). Это потребовало небольшого изменения логики работы, но в результате оказалось вполне приемлимым.

5. Невозможность опубликовать Query as a web-service (aka QaaWs или «квасы») в тех случаях, когда у получаемых данных более одного контекста в юниверсе.
Данные в одну из систем передавались путем забора их из другой системы через юниверс SAP Business Objects (не спрашивайте, почему, особенности корпоративной архитектуры) ч помощью предназначенного для этого функционала Query as a web-service. После миграции все QaaWs необходимо переопубликовывать для того, чтобы обновилась ссылка на сервис, но, к сожалению, переопубликование оказалось невозможно выполнить как минимум для одного QaaWs. При нажатии кнопки «Publish» появлялся выбор контекста QaaWs и процесс переопубликации возвращался «на исходные позиции».



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

Неожиданно, но причиной ошибки оказалось найденное несоответствие — мы использовали Oracle Client 10 вместо Oracle Client 11 (несмотря на то, что Oracle Client 10 официально поддерживается в BI4.0).



Замена клиента решила проблему, доступ интерфейсов к данным был восстановлен.

Итоги

Вот, собственно, и вся эпопея. Пользователи начали работать на BI4.0. У нас наступило некоторое счастье и период фиксации извлеченных технических уроков из проекта, чем мы и поделились с вами.

Ну а впереди, через полгода, нас ждет переход на SAP Business Objects BI4.1, есть время подготовиться если не технически, то хотя бы морально.