Comments 10
Есть простое решение:
1. Делаем в экселе нужную таблицу руками (с выравниваниями/заливками)
2. Сохраняем эту табличку как html
3. Используем html таблицу как шаблон для генерации отчёта на стороне основной системы(строки собирать не большие затраты)
4. только сохраняем не с расширением .html , а с .xlsx
Если таких отчётов немного(а CSV уже не хватает), то едва ли есть решение оптимальнее (по критерию затрат времени и эксплуатационных расходов в дальнейшем)
Спасибо, интересный подход. Но не могли бы подробней рассказать про него?
п.3 выполняется на ABAP-сервере? Вы написали "на стороне основной системы", но я хотел уточнить
При сохранении xlsx в html создается подкаталог с несколькими файлами (css, htm, xml) и главный файл с тем же именем, что xslx, но с расширением htm. Если в xlsx вкладок было 2, то в подкаталоге создается 2 htm-файла, и править, использовать, как шаблоны, надо их. Глядя на htm-код в этих файлах, лично мне было бы много сложнее программно добавить колонки и строки в уже существующий шаблон htm-table, чем высокоуровневыми методами Python-библиотеки конструировать xslx-файл. Только для отчетов с фиксированным числом строк и столбцов это не нужно делать.
Добавление комментария к ячейке в htm также выглядит непростым делом из-за сложности формата. А некоторые xlsx-опции (автофильтр, фиксация прокруток) вообще теряются при сохранении в html.
Буду признателен за ваши комментарии. Сталкивались ли вы с такими задачами (программное добавление строк/столбцов в htm, новые комментарии, включение автофильтров и фиксация прокрутки) когда применяли ваш подход и как решали? По-моему, конструирование шаг-за-шагом данных в формате xslx с помощью высокоуровневой библиотеки (хоть на Python, хоть ABAPXSLX) в общем случае, все же приводит к более наглядному и компактному коду, чем вписывание в шаблон.
Спасибо, было интересно почитать про Ваш опыт!
Думаю стоит обратить внимание на следующие моменты:
с учетом того, что SAP BW зачастую применяется в Enterprise среде с более высокими требованиями к безопасности по сравнению с СМБ, возможно потребуется размещение отдельной инфраструктуры под python окружение и аудит зависимостей open-source библиотек, которые будут применяться для генерации конечного XLSX, нужно будет решить вопросы их периодического обновления;
если мы говорим про получении отчетов из web-приложения при применении SAP EP / Fiori Launchpad и использовании отдельной среды для окружения питона и генерации XLSX, нужно будет проработать порядок передачи сгенерированного в отдельном окружении XLSX документа в текущую сессию в которой пользователь взаимодействует с SAP-окружением, с учетом его полномочий и исключения доступа к этому XLSX сторонних лиц;
csv-файлы как промежуточное представление выгруженной из SAP BW информации возможно не являются оптимальным способом коммуникации 2х экосистем;
по моему опыту в сложных отчетах зачастую пристуствует динамическая логика (группировка, форматирование, берем данные разных наборов при выполнении разных условий) - чтобы она успешно отработала на питоне нужно будет запихнуть все необходимое для принятие этих динамических решений в промежуточный csv.
Да, спасибо, моменты правильно подмечены.
По 1-му: как упоминал в посте, такой средой может быть SAP DI (OnPremise или Cloud). Для минимальных требований к отчету в XSLX, среди opensource python-библиотек понадобится одна из двух упомнянутых библиотек генерации xslx, pandas и numpy. Последние две де-факто - стандартные для Python. Может быть их известность и распространенность упростит требования безопасности к ним. Но это от внутренних политик зависит, конечно
По 2-му: один из вариантов - ограничиться простой публикацией готовых xslx-файлов в папки на корпоративном файловом хранилище, MS Sharepoint, где уже используются все необходимые политики разграничения доступа. Зачем xslx "вытягивать" в SAP EP / Fiori, я не совсем понимаю. Удобства работы, на мой взгляд, это не добавит.
По 3-ему. Согласен, не самый оптимальный способ. При наличии технической и, что немаловажно, лицензионной возможности, можно без большого труда забирать данные в Python-программу из БД.
Но применительно к SAP-продуктам - источникам данных, обращение к БД напрямую требует отдельной лицензии (что не у всех клиентов есть). А при наличии лицензии внутренними политиками не всегда разрешено подключаться к продуктивным БД SAP-систем иначе, как из приложений SAP. И, наконец, не всегда готовые для xslx данные хранятся непосредственно в БД и их не вытащить без специальных настроек. Например, в случае получения данных из BW-отчета, у нас не так-то много пространства для выбора. А вот BW OpenHub в csv-файл прост, работает всегда и генерирует понятный контент.
Файлы удобны еще и тем, что в случае их хранения вы всегда знаете, что и в какой момент было выгружено. Это очень легко проверять. В БД это сделать чуть сложнее, учитывая обычные требования "не раздувать" базу данных архивной информацией.
По-4-му: такую логику преобразований можно убрать в исходную систему. А если это не рационально или не возможно, обратиться к той же Python.pandas, которая позволяет манипуливать dataFrames почти как таблицами в SQL.
п.2 - генерировать XLSX в текущей веб-сессии пользователя имелась ввиду работа пользователя например в SAP Fiori с карточкой какой-либо сущности (например проекта) и необходимость по нажатию кнопки в этой карточке выгрузить печатную форму паспорта этого проекта и т.д.
п.3 - помимо csv еще можно посмотреть в сторону web-сервисов (REST, OData etc), предоставления данных посредством BICS/MDX, но посмотреть позднее что именно было выгружено из бэкенда конечно будет сложнее если такую возможность не закладывать в момент генерации конечного XLSX.
Что-то сложно. А не пробовали использовать low-code решения? Коннектор в Power Query в Excel к SAP HANA или папке с csv файлами и генерить любые отчёты либо в нём либо в Power Pivot и выводить в сводную. Зачем писать программные коды, когда это может реализовать пользовательский интерфейс?
Да, не просто. С PowerQuery знаком на начальном уровне. Архитектурное решение использовать PowerQuery требует ответов на многие вопросы:
лицензии на PowerQuery (PQ)
лицензии на доступ к SAP HANA (при обращении к ней напрямую), в т.ч. инсталляция библиотек доступа на каждую рабочую станцию с PQ
требования отказаться от MS Excel в пользу LibreOffice (например)
повторное использование логики, стилей и т п. в разных книгах с PQ. Не знаю, может это и можно там сделать. Не уверен
контроль версий кода PQ. Не знаю, можно ли PQ прикрутить к git, не уверен.
доступ через планшет/телефон. Открыть статический xslx-файл, даже немаленький, там легко и быстро. А вот как быть с PQ - не знаю.
Мне кажется, PQ очень удобен для персонального использования, либо в очень небольших командах. Когда пользователь достаточно компетентен в модели данных, в инструменте, и сам отвечает только перед собой за то, что он там создал. Делать же отчет на PQ для пользования сотням пользователей можно, конечно, но поддерживать это все крайне сложно будет. Не претендую тут на истинность, потому что с PQ знаком, как уже писал, поверхностно.
Кажется что требования 2-4 сек. на отчет конечно убивает все попытки строить отчет онлайн на стороне клиента, получается все отчеты должны быть уже построены заранее.
PQ бесплатный, к нему никакие лицензии не нужны, а начиная с 2016 Excel так вообще встроенный. Ну то, что лицензии платные к SAP - это специфика SAP. Под логикой и стилем в разных файлах не очень понял. Как построен процесс? Это один обновляемый файл, рассылаемый пользователям или множество файлов? PQ - это ETL инструмент, он выгрузит данные в точно такую же статическую таблицу в обычном xlsx файле, если это необходимо и точно также это можно будет смотреть на телефоне/планшете или выгрузить в Power Pivot, где дальше можно настроить интерактивность, если хочется большего. Любой запрос на PQ - это код на языке M, который можно зашить хоть в txt а потом из PQ ссылаться на этот txt и исполнять код, а txt можно редактировать. Ну а если вопрос о сотне пользователей, то наверное это уже не уровень Excel, а веб-интерфейсов. Хотя если это один файл, который лежит в облаке, то там хоть сто, хоть тысяча.Помню однажды реализовал безопасность на уровне строк на Power Pivot для разных групп пользователей, т. е. даже это реализуемо в Excel. В свою очередь я сам Python не знаю от слова совсем, поэтому использую сообразительность, зашёл в аналитику данных со стороны VBA, SQL, DAX, MDX, но вот до Python пока руки не дошли. Мне всегда казалось, что программирование на Python - это что то очень сложное))
Python довольно простой, его даже в средней школе изучают. В отличие от M :)
А процесс довольно обычный. Несколько упрощая, на сервере, по расписанию или по событию запускается процесс, который сначала делает csv, потом запускает python-код, делающий xlsx и публикующий его. Другой вариант - процесс запускает python-код, который подключается к БД, забирает данные, делает xlsx и публикует его.
Если запуск PQ можно планировать (можно ли?) на сервере (на Windows, надо полагать. только :) ) и затем PQ не только в статическую xlsx-таблицу выгрузит, но и стили к ячейкам применит, комменты к ячейкам добавит, смерджит ячейки, сгруппирует строки и колонки, добавит автофильтр и бизнес-графику и зафиксирует области прокрутки, то будет, в общем-то, очень похоже, да :)
Поправьте меня, но тогда это будет комбинация кода на M и VBA, который может вызываться вперемешку. Верно? И VBA для git придется "копи-пастить".
Python для генерации статических отчетов XLSX по данным SAP-систем