Решение получилось масштабируемое. Интересно, сталкивались ли вы с проблемой ограничений на число строк в excel ? Допустим, используя pivot table, пользователю надо проанализировать данные, выполняя drilldown до уровня документа и его позиции. А это означает, что такие детальные данные уже должны быть в excel-файле - ведь excel-файл не выполняет подключение к БД. Это Java backend app “набивает” файл данными из субд, и затем «отдаёт» его пользователю вместе с pivot table над ними.
Если пользователь с полномочиями на большой регион выберет ещё и большой период времени для анализа, то при ваших розничных объемах максимальный миллион строк на листе в книге excel будет легко достигнут.
Python довольно простой, его даже в средней школе изучают. В отличие от M :)
А процесс довольно обычный. Несколько упрощая, на сервере, по расписанию или по событию запускается процесс, который сначала делает csv, потом запускает python-код, делающий xlsx и публикующий его. Другой вариант - процесс запускает python-код, который подключается к БД, забирает данные, делает xlsx и публикует его.
Если запуск PQ можно планировать (можно ли?) на сервере (на Windows, надо полагать. только :) ) и затем PQ не только в статическую xlsx-таблицу выгрузит, но и стили к ячейкам применит, комменты к ячейкам добавит, смерджит ячейки, сгруппирует строки и колонки, добавит автофильтр и бизнес-графику и зафиксирует области прокрутки, то будет, в общем-то, очень похоже, да :)
Поправьте меня, но тогда это будет комбинация кода на M и VBA, который может вызываться вперемешку. Верно? И VBA для git придется "копи-пастить".
Да, не просто. С PowerQuery знаком на начальном уровне. Архитектурное решение использовать PowerQuery требует ответов на многие вопросы:
лицензии на PowerQuery (PQ)
лицензии на доступ к SAP HANA (при обращении к ней напрямую), в т.ч. инсталляция библиотек доступа на каждую рабочую станцию с PQ
требования отказаться от MS Excel в пользу LibreOffice (например)
повторное использование логики, стилей и т п. в разных книгах с PQ. Не знаю, может это и можно там сделать. Не уверен
контроль версий кода PQ. Не знаю, можно ли PQ прикрутить к git, не уверен.
доступ через планшет/телефон. Открыть статический xslx-файл, даже немаленький, там легко и быстро. А вот как быть с PQ - не знаю.
Мне кажется, PQ очень удобен для персонального использования, либо в очень небольших командах. Когда пользователь достаточно компетентен в модели данных, в инструменте, и сам отвечает только перед собой за то, что он там создал. Делать же отчет на PQ для пользования сотням пользователей можно, конечно, но поддерживать это все крайне сложно будет. Не претендую тут на истинность, потому что с PQ знаком, как уже писал, поверхностно.
По 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.
Спасибо, интересный подход. Но не могли бы подробней рассказать про него?
п.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) вобщем случае, все же приводит к более наглядному и компактному коду, чем вписывание в шаблон.
Для преодоления 1M-limit вы не рассматривали выгрузку в MS Access с последующим подключением к файлу Access из Excel?
Решение получилось масштабируемое. Интересно, сталкивались ли вы с проблемой ограничений на число строк в excel ? Допустим, используя pivot table, пользователю надо проанализировать данные, выполняя drilldown до уровня документа и его позиции. А это означает, что такие детальные данные уже должны быть в excel-файле - ведь excel-файл не выполняет подключение к БД. Это Java backend app “набивает” файл данными из субд, и затем «отдаёт» его пользователю вместе с pivot table над ними.
Если пользователь с полномочиями на большой регион выберет ещё и большой период времени для анализа, то при ваших розничных объемах максимальный миллион строк на листе в книге excel будет легко достигнут.
Python довольно простой, его даже в средней школе изучают. В отличие от M :)
А процесс довольно обычный. Несколько упрощая, на сервере, по расписанию или по событию запускается процесс, который сначала делает csv, потом запускает python-код, делающий xlsx и публикующий его. Другой вариант - процесс запускает python-код, который подключается к БД, забирает данные, делает xlsx и публикует его.
Если запуск PQ можно планировать (можно ли?) на сервере (на Windows, надо полагать. только :) ) и затем PQ не только в статическую xlsx-таблицу выгрузит, но и стили к ячейкам применит, комменты к ячейкам добавит, смерджит ячейки, сгруппирует строки и колонки, добавит автофильтр и бизнес-графику и зафиксирует области прокрутки, то будет, в общем-то, очень похоже, да :)
Поправьте меня, но тогда это будет комбинация кода на M и VBA, который может вызываться вперемешку. Верно? И VBA для git придется "копи-пастить".
Да, не просто. С PowerQuery знаком на начальном уровне. Архитектурное решение использовать PowerQuery требует ответов на многие вопросы:
лицензии на PowerQuery (PQ)
лицензии на доступ к SAP HANA (при обращении к ней напрямую), в т.ч. инсталляция библиотек доступа на каждую рабочую станцию с PQ
требования отказаться от MS Excel в пользу LibreOffice (например)
повторное использование логики, стилей и т п. в разных книгах с PQ. Не знаю, может это и можно там сделать. Не уверен
контроль версий кода PQ. Не знаю, можно ли PQ прикрутить к git, не уверен.
доступ через планшет/телефон. Открыть статический xslx-файл, даже немаленький, там легко и быстро. А вот как быть с PQ - не знаю.
Мне кажется, PQ очень удобен для персонального использования, либо в очень небольших командах. Когда пользователь достаточно компетентен в модели данных, в инструменте, и сам отвечает только перед собой за то, что он там создал. Делать же отчет на PQ для пользования сотням пользователей можно, конечно, но поддерживать это все крайне сложно будет. Не претендую тут на истинность, потому что с PQ знаком, как уже писал, поверхностно.
Да, спасибо, моменты правильно подмечены.
По 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.
Спасибо, интересный подход. Но не могли бы подробней рассказать про него?
п.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) в общем случае, все же приводит к более наглядному и компактному коду, чем вписывание в шаблон.