Здравствуйте, меня зовут Сергей Шаблыкин. Я работаю архитектором домена BI в компании «Лента». Сегодня поделюсь описанием архитектуры рассылки отчетов SAP BW, которая помогает отказаться от тяжеловесного стандартного SAP-решения и получить много дополнительных преимуществ в части экономия времени сотрудников и ресурсов Компании.

Предыстория

Мы используем SAP BW на SAP HANA уже более 10 лет. Когда-нибудь мы напишем статью об успешном импортозамещении SAP BW, но пока это время еще не пришло. За все годы у нас сложился успешный сценарий получения пользователями отчетов через рассылки: сотни пользователей получают их в определенном формате и с требуемыми фильтрами. Есть выгоды и для ИТ в целом: мы получаем меньше жалоб на производительность SAP BW, ведь без рассылки все эти сотни людей заходили бы в систему, причем примерно в одно и то же время.

С выходом SAP BW/4 вендор поменял реализацию сценария и теперь для него требуется SAP Business Objects BI Platform – мощное, но тяжеловесное решение. Так сложилось, что от этой платформы нам нужна только рассылка. Другие компоненты платформы проиграли в свое время конкурентную борьбу. Но из-за рассылок приходится ее «терпеть», в том числе все нынешние сложности с ее обновлением, поддержкой и рядом функциональных недостатков. И это становится проблемой, которая не только усложняет эксплуатацию того, что есть, но и не позволяет расширяться.

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

Эта статья будет интересна в первую очередь архитекторам и консультантам по решениям на основе популярного продукта компании SAP – корпоративного хранилища данных SAP BW.

Если вы отвечаете за развитие корпоративного хранилища данных на базе SAP BW on HANA или SAP BW/4 HANA, вы рано или поздно (лучше – рано) задумаетесь о контроле роста объемов данных «колоночных» таблиц, которые загружаются в оперативную память сервера БД SAP HANA. По рекомендации SAP, суммарный объем табличных данных («поколоночных» и «строчных») таблиц в памяти не должен превышать эмпирического значения 50% от выделенной на SAP HANA памяти сервера(ов). В противном случае, процессы в SAP HANA станут выполняться менее предсказуемо в части длительности, а порой и просто стабильности. Это относится и к процессам трансформации данных в BW (т.н. DTP), и к выполнению пользовательских отчетов.

Столкнувшись с нехваткой памяти, SAP HANA инициирует процессы вытеснения из памяти сегментов (колонок поколоночных таблиц или их партиций), которые использовались наиболее давно и имеют более высокий приоритет к вытеснению. В SAP HANA за это отвечает параметр UNLOAD PRIORITY, который устанавливается на “поколоночную» таблицу и может быть изменен впоследствии. Однако, в ситуации, когда одновременно десяткам, а порой и сотням параллельных процессов требуется больше памяти, внутренним методам выделения и освобождения памяти в HANA приходится «в авральном режиме» решать задачу определения, сколько нужно вытеснить, что именно можно вытеснить и выполнить само вытеснение. Очевидно, что это не добавляет производительности процессам, ради которых это вытеснение и выполняется. И даже при наличии таких совершенных алгоритмов возникают ошибки нехватки памяти в HANA (OOM), что приводит к проблемам уже на уровне приложения SAP HANA, а именно – SAP BW. Это выражается в аварийном прерывании процесса. И хорошо еще, если этот процесс- некритичный пользовательский отчет. Совсем другое дело, если это ночная загрузка. Без должного реагирования пользователи утром могут не увидеть в отчетах свежие данные.

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

В настоящее время все большую популярность набирают облачные решения для визуализации данных, демонстрируя двузначный рост год-к-году по большинству показателей. Однако не все компании - клиенты поставщиков облачных решений могут позволить себе использовать “облака” по самым разным причинам: от требований безопасности данных до недостаточной функциональности или даже более высокой стоимости владения по сравнению с on-premise. 

Поэтому время от времени возникают задачи подготовки отчетности для визуализации в on-premise-инструментах. Автор долгое время работал и продолжает работать с решениями SAP, поэтому именно решения SAP (SAP BW/4, SAP S/4), как поставщики данных для отчетности, наиболее близки. Однако предлагаемый подход может быть скопирован и на другие системы-источники. Никаких препятствий к этому нет.

Задача формулируется так: реализовать on-premise решение по автоматической и регулярной подготовке отчетов по бизнес-данным SAP-систем (BW/4 или S/4) в формате XLSX.

• Нестандартными относительно инструментов SAP требованиями к форматированию;
• Фиксированным числом столбцов;
• Значительным количеством столбцов и строк (соответственно, десятки и десятки тысяч и более);
• Требованием наличия Excel-представления;
• Требованием к времени выполнения не более нескольких минут

• в зависимости от используемого Excel-инструмента SAP BW, пользователь запускает BW-BEx Analyzer или SBOP Analysis for Office, подключается к серверу SAP BW, выбирает из роли рабочую книгу и запускает ее на выполнение.
  Через несколько секунд (иногда – десятка секунд) появляется селекционный экран.
  На экране пользователь выбирает значения параметров. Например, год-месяц, балансовую единицу, группу материала и т.п. Затем нажимает кнопку «выполнить».
• Теперь настала очередь «поработать» для SAP BW: все BW-BEx-отчеты рабочей книги выполняются последовательно, отчет за отчетом, передавая на рабочие листы Excel свои данные.
• После получения в Excel данных каждого отчета запускается VBA-макрос. Логика работы макроса такова, что он ничего не делает, пока данные всех отчетов не будут получены на Excel-листы.
• Когда данные последнего отчета поступили на Excel-лист, VBA-макрос выполняет основную работу по подготовке форматирования отчета.
• Когда VBA-макрос завершил работу, пользователь может увидеть результат отчета в своем Excel.