Комментарии 19
"Облегчение работуы"? И как, получается?
Извините, тут бесполезно по одной ошибке вам в личку таскать, вы бы свой текст перед публикацией перечитали хоть раз.
насышенным и функциональным интерфесом
А может изучить функционал Excel? И как в нем делать интерфейсы?
Каким образом вот это вот облегчит визуализацию 255 колонок и 65000 строк?
У Excel такой багаж наработок в плане анализа.
А уж в плане получения данных из гетерогенных источников…
Хорош уже заниматься велосипедостроением!
Как я понимаю, это решение для переноса данных из неструктурированных источников «Для чайников». Это реально бывает сложно, Эксель даже csv файлы не всегда корректно обрабатывает, я уже не говорю о случаях, когда на входе html. У меня кое-какая IT-подготовка есть и то бывает сложно с ним справиться. Иногда проще оказывается вообще написать скрипт или сначала загрузить в Таблицы Гугл и сохранить оттуда.
У меня, как у человека, который в этом "велосипеде" делал почти всё от колёс до руля есть ответы на ваши вопросы (надеюсь):
- А как правильно делать интерфейсы в Excel так, чтобы можно было показать пользователю конкретную страницу PDF файла из которого изначально был получен показатель, содержащийся в текущей ячейке? Неужели на связке VBA/MS Forms что-то писать в 2020 году? Может TaskPane со встроенным браузером? Или внешний процесс для отображения PDF файлов… Ну так у нас он есть — браузер называется. Если есть идеи как это сделать лучше/правильней — я с удовольствием выслушаю.
- Это решение никаким образом визуализацию не облегчит, потому что оно не для этого предназначенно. Наверное, тут проблема в том, что изначальная задача не очень понятно описана. Она не в том, чтобы получить табличные данные из базы и отобразить их в виде отчёта, она о том, чтобы из данные из разных неструктурированных внешних источников (отсканированные PDF отчёты) подготовить к загрузке в базу и дальнейшему анализу другими средствами.
Так что я двумя руками за существующие решения, но иногда приходится и велосипеды собирать из подручных материалов :)
Внешние источники данных вас спасут. Нет необходимости в этом зоопарке.
К сожалению, не спасут. Из источника данные можно загрузить, но реализовать, например, просмотр исходного документа без дополнительных инструментов тут уже нельзя. Поддержание и визуализация связей с исходным документом, было одной из основных задач.
Вообще, это задача комплексная. Не «подходят» внешние источники потому, что вы решаете задачу несистемно.
Эта задача решается практически во всех финансовых учреждениях. Поищите релевантный опыт там. Это позволит избежать много «боли».
P.S. Вообще, я два раза перечитал статью и оба раза не совсем понял целевую задачу.
- Доступ к данным должен быть ограничен. Это должно решаться через централизованное управление правами. А это AD. И если взять за основу оперирование данными через внешние источники, эта задача бы решалась на уровне, например, MS SQL.
- Excel можно рассматривать как формат входящих данных и как движок для отчетов. Но не как БД для построения других отчетов. Теоретически это возможно. Практически, это ад кромешный для сисадминов и поддержки. Потому, что за формулами и связями стоят конкретные люди не ограниченные своей фантазией. Поддержание консистентности такой системы невозможно. Т.е. совсем. Это высокий операционный риск компании. В любой момент времени она может потерять ценные данные. И просто так из бэкапа их не восстановить. Потому, что многие из документов становятся «критическими» и актуализируются в реальном времени.
- Нужно разделять шаблон отчета и отчет. Управление шаблонами необходимо организовать через системы управления версиями. Частные отчеты необходимо фиксировать «как есть». Вне зависимости от изменяющегося шаблона. В противном случае, когда задача будет — «а соберите мне данные за последние 3 года» — это будет очередной ад.
Эта задача решается практически во всех финансовых учреждениях. Поищите релевантный опыт там. Это позволит избежать много «боли».
P.S. Вообще, я два раза перечитал статью и оба раза не совсем понял целевую задачу.
- Разграничение доступа конечно же есть. У нас реализована ролевая модель и существует «подсистема» управления правами. В статье я этого не касался, т.к. предмет был немного другой.
- В некотором смысле так и есть — с помощью этого инструмента пользователи создают и поддерживают свои модели привычным им способом. Вопросы версионности моделей мы не решаем (это не задача нашего инструмента). Версионность и контроль целостности самих данных, которые они загружают реализуется в нашей системе, но это таже несколько выходит за рамки статьи.
- Хранение готовых моделей и их дальнейшее использование не является областью применения нашей системы. Клиенты реализуют их по-разному. Некоторые могут хранить, например Excel-файлы в Sharepoint, где есть какое-никакое управление версиями. А для некоторых эта модель промежуточная, как вы упоминали — способ получения входных данных для других аналитических инструментов. И то что они сделали при помощи нашей системы, они выгружают куда-то еще.
Наверное, со стороны решаемая задача, для которой пришлось все это сделать, выглядит несколько непонятной. Но у нас взгляд замылен, мы в ней давно варимся :) Задача достаточно «отраслевая» и связана с повышением удобства переноса числовых данных из неструктурированых документов с сохранением привязки к источнику. Т.е. надо:
- быстро перенести данные в Excel
- иметь возможность увидеть число из ячейки в исходном документе (например, финасовом отчете)
- прeдоставить некоторые инструменты по работе с данными в виде функций Excel
А мы пошли обратным путем (https://m.habr.com/ru/company/arcadia/blog/498032/) и позволили пользователям продолжать работу в экселе по редактированию данных и настройке бизнес рассчетов. А вот визуализацию, анализ данных, сложные рассчеты оптимизировали на бекэнде и выдавали в более удобном виде для клиента, которому интересен лишь результат и красивая картинка.
А чем аналитиков не устроили Гугл Таблицы? Помниться, я делал в Ексел расчет методом конечных элементов. Все с нуля, начиная от формирования матриц жесткости для каждого треугольника до составления результирующей системы уравнений. В общем, это была жесть чистой воды. Затем импортировал это дело в Гугл Таблицы и все заработало.
Гугл Таблицы:
1. Немного, но ощутимо подтормаживают.
2. Выглядят неряшливо (когда работаешь с таблицами по 5-6 часов в день такие вещи начинают бесить).
3. Во многих случаях их просто не принимает заказчик/целевой потребитель. Скажем, в требованиях банка к финмодели может прямо в первой строчке быть написано: «Модель представляется в виде файла Microsoft Excel версии не ниже ___».
Ну и вообще, Эксель это «наше все», устоявшийся отраслевой стандарт. Я сейчас начинаю очередной заказ, который прямо просится в Jupyter Notebook, но вместо этого делаю в Экселе, просто потому, что никто в команде кроме меня не пользуется ничем другим.
1. Немного, но ощутимо подтормаживают.
2. Выглядят неряшливо (когда работаешь с таблицами по 5-6 часов в день такие вещи начинают бесить).
3. Во многих случаях их просто не принимает заказчик/целевой потребитель. Скажем, в требованиях банка к финмодели может прямо в первой строчке быть написано: «Модель представляется в виде файла Microsoft Excel версии не ниже ___».
Ну и вообще, Эксель это «наше все», устоявшийся отраслевой стандарт. Я сейчас начинаю очередной заказ, который прямо просится в Jupyter Notebook, но вместо этого делаю в Экселе, просто потому, что никто в команде кроме меня не пользуется ничем другим.
Может банально нельзя, просто интернет не положен?
Почему мы не делали это в Google-таблицах — есть несколько причин:
1. Клиентам в основном нужно работать с Excel.
2. Для некоторых клиентов решение должно работать в сети, изолированной от Интернета или с сильно ограниченным доступом в Интренет.
3. Как уже упоминали тут в комментах, на больших таблицах Google-таблицы тормозят сильнее, чем Excel.
4. Возможностей по подключению к внешним источникам и загрузки данных в Google-таблицы меньше, чем предоставляет Microsoft.
1. Клиентам в основном нужно работать с Excel.
2. Для некоторых клиентов решение должно работать в сети, изолированной от Интернета или с сильно ограниченным доступом в Интренет.
3. Как уже упоминали тут в комментах, на больших таблицах Google-таблицы тормозят сильнее, чем Excel.
4. Возможностей по подключению к внешним источникам и загрузки данных в Google-таблицы меньше, чем предоставляет Microsoft.
А вот мы зашли в другую тему — Excel JS Addin. Это страничка прямо в документе, js-код работает с документом через js-api, с бэкендом через rest-api.
Там возможностей хватает, но сильно проще разрабатывать и обновлять аддины.
Там возможностей хватает, но сильно проще разрабатывать и обновлять аддины.
Да, JS API для Excel мы тоже смотрели. Для многих задач он намного удобнее старого нативного API для addin'ов. Но некоторые вещи через него мы бы не смогли сделать, например перехват вставок. И полтора года назад, когда мы принимали решение каким путем пойти, JS API было беднее, чем сейчас. Если я е ошибаюсь, тогда там нельзя было сделать асинхронные UDF. При этом ExcelDNA очень помогает и облегчает разработку. Установка и обновление у нас сделаны через MSI, проблем с этим нет.
Похоже, сама постановка задачи вызывает много вопросов. Поясню немного. Задача состояла в том, чтобы сохранить Excel, как инструмент, в котором работает пользователь. При этом дать возможность удобно заполнять таблицы числовыми данными из исходны документов. Для этого Пользователю надо видеть одновмеменно свою таблицуи размеченный нашей системой исходный документ. Также необходимо поддерживать связанность между ячейкой, в которую пользователь вставил «число» и исходным документом. Для этого при перемещении по ячейкам ему надо показывать исходный документ и подсвечивать числа в нем. И все это должно работать быстро.
Мы ерепробовали разные варианты решения этой задачи: и «чистый» RTD, и JS API. Но результат, удобный для пользователя предстказуемо работающий без сайд-эффектов, связанных с особенностями выполенения кода в Excel, у нас получился именно в том виде, который описан в статье.
Мы ерепробовали разные варианты решения этой задачи: и «чистый» RTD, и JS API. Но результат, удобный для пользователя предстказуемо работающий без сайд-эффектов, связанных с особенностями выполенения кода в Excel, у нас получился именно в том виде, который описан в статье.
Я всё собираюсь написать статью, которая расскажет про трудный путь к текущему решению через асинхронные UDF (которые оказались "иногда синхронными", причём в внезапно) к связке RTD + SignalR. Про некоторые неприятные сюрпризы от ExcelDNA и почему иногда мне хочется написать свою версию этой библиотеки (конечно с преферансом и институтками), а не использовать то, что есть. Ну а про то, что COM Interop в .NET вообще и в Excel в частности — это бесконечный источник боли, наверное, только ленивый не писал ещё :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как скрестить Excel c интерактивным веб-приложением