Эта статья будет интересна в первую очередь архитекторам и консультантам по решениям на основе популярного продукта компании 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.