Комментарии 16
В целом, решение рабочее, главное чтобы базу сильно не реструктуризировали :) Если с обычными типами все довольно просто, и их служебные имена в пределах базы не должны изменяться, то поля составных типов имеют не столь очевидную структуру, т.е. при расширении какого-то ссылочного поля до составного его структура может заметно измениться и запросы придется изменять. Красивого решения по автоматической генерации таких запросов я пока не встречал, правда не уверен, что в нем вообще есть такая уж необходимость. Хотя, когда поддерживаешь несколько предприятий с идентичной конфигурацией, имена хранения у них все равно будут отличаться — в таком случае было бы неплохо автоматизировать эти преобразования.
Здесь в конце статьи - про использованные обработки. https://infostart.ru/1c/articles/1639249/
Почему было принято решение оставить интеграцию через SQL запросы? Решение довольно странное, с моей точки зрения, т.к. QlikView это аналитика, то возможна не нужна online интеграция, но можно было через 1С сделать универсальное решение. а не привязанное к конкретной БД по именам полей...
Скорее всего, как указано в статье, была задача мигрировать 1 к 1. Переделывать архитектуру при миграции иногда бывает плохой практикой. Может выйти ситуация, когда старое "уже" не работает, а новое "ещё".
Плюс взаимодействие с другим интегратором, накладывает свои ограничения.
Сложно судить, не достаточно информации.
"..Составили сводный документ, содержащий список источников данных (около 20 блоков) ...", но мне кажется это очень маленький объем, чтоб 8 месяцев на это потратить... в худшем случаем можно было сделать прослойку, отражающую данные в другую БД MSSQL, если со стороны QlikView есть ограничения на используемые источники данных, в любом случае решение стало бы универсальным.
А разве прямые SQL запросы к базе 1с не являются нарушением лицензии 1с? Несколько лет назад изучал этот вопрос, и встречался пункт о запрете.
на диске ИТС есть рекомендация:
"… для специальных задач интеграции может потребоваться более тесное взаимодействие между 1С:Предприятием и другими программами.
Для решения таких задач разработана «Технология создания внешних компонент». Данная технология позволяет создавать программы, которые будут динамически подключаться и тесно взаимодействовать с системой 1С:Предприятие, расширяя ее возможности."
Думаю это наверно был правильный путь в данном случае, а не прямые запросы к БД
Согласен тем более на 8.3 появилось довольно много других возможностей для синхронизаций(web серверы, oData и.т.д.)
Сталкивался с PowerBI, пробовал данные о продажах передавать через OData, но это нереально по времени. В итоге остановились на варианте регламентной выгрузки данных обработкой раз в сутки во внешнюю базу на SQL за несколько последних месяцев, либо по требованию. Зато получился довольно гибкий инструмент, позволяющий сразу запросами внутри 1С сформировать необходимые данные в том виде, в котором они требуются для PowerBI. Минус — задержка в данных в течение дня, но это некритично в моем случае, можно было бы и чаще запускать выгрузку.
Лицензионное соглашение это важный закон, его нарушать нельзя. Вот ссылка на него https://v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8/?
Соглашение не запрещает, например, сделать вторую копии базы 1С на СУБД (отрубить её от 1С Сервера, база теперь только на СУБД и к 1С не имеет отношения, работоспособность не нарушает), и с неё считывать данные. Материя тонкая согласен в ней надо понимать и быть осторожным.
Прикрепленные файлы:
Ну и если есть отдельная копия, то можно сделать прокси-базу с подготовленными view-хами, в которых уже использовать понятные имена, и управлять мэппингом полей на уровне СУБД. Кроме того можно «расшивать» всякие непонятности типа полей составного типа.
Это все понятно, я даже не спорю, меня другое "настораживает", что привязка идет к именам полей конкретной БД и реализация вызывает у меня глубокое недоумение в связи "...Дмитрий Малышев, специалист Внедренческого центра «Раздолье», разработчик «1С» с 2004 года на платформах 1С 7.7, 8.1, 8.2, 8.3, сертифицированный 1С-эксперт по технологическим вопросам, участник 30-ти проектов внедрения 1С:УПП и 1C:ERP. "...
Согласен с @yukon39
Делаем RO асинхронную реплику (вам же не нужно прям в realtime получать данные, 100-1000 мс задержки вполне норм, при этом не нагружаем прод. базу ожиданиями фиксации транзакций в RO реплике).
В реплике на основании информации о соответствии полей таблиц и объектов метаданных в той же базе генерируем View с названиями таблиц и полей соответствующими именам метаданных.
В итоге имеем отдельный сервер где можно крутить разные аналитики и SQL интеграции не нагружая основной сервер. При этом запросы пишутся почти как в 1С Конечно итоги и срезы последних нужно самим подключать, и какой то навык нужно иметь, лучше конечно первый раз писать в консоли и потом транслировать в SQL и затем уже писать через View что бы меньше ошибок. Основные плюсы потом в сопровождении, проще читать, проще менять запросы и.т.п.
Переход с 1С: УПП на 1C:ERP: Переделываем интеграции с SQL-запросами к СУБД (на примере УПП — QlikView — ERP)