Лицензионное соглашение не позволяет использовать недокументированные фирмой "1С" средства для построения решений на платформе "1С:Предприятие"
Это означает, что средства СУБД (или любые другие внесистемные средства) можно использовать только в том случае, если документация по продуктам линейки "1С:Предприятие" (включая 1С: ИТС) содержит явную рекомендацию использовать данное средство для решения данной задачи.
Во всех остальных случаях лицензионное соглашение позволяет использовать для построения решений только штатные средства платформы. В частности, можно обращаться к данным информационной базы только при помощи объектов "1С:Предприятия", специально предназначенных для работы с данными (запросы, справочники, документы и т. д.).
Нельзя обращаться к данным информационной базы напрямую, минуя уровень объектов работы с данными "1С:Предприятия", например, при помощи средств СУБД или при помощи внешних компонент, которые реализуют прямой доступ к СУБД. Это ограничение распространяется на любые действия с данными, в том числе на изменение их структуры, а также на чтение или изменение самих данных информационной базы или служебных данных "1С:Предприятия".
Вычислить инкремент в самом общем случае можно, использовав механизм регистрации изменений данных. Для этого необходимо управлять изменениями в рамках плана обмена. Регистрируя к обмену изменившиеся объекты и снимая регистрацию с тех объектов, которые переданы успешно.
Я разделяю Ваши сожаления, но мой пост немного про другой инструмент) Cloud - потому что он используется в облачной версии BI. В дальнейшем будет и on-prem
Да, конечно, можно вывести сумму (не вручную). Обычно выбор типа визуализации зависит от задачи. Этот график, например, показывает соотношение двух показателей одинаковой размерности. Например, для СЗАО - 1600 к 90, а для САО 692 к 279.
Получается ли у вас декларативно выкатывать в прод one-time скрипты/код которые должны менять/исправлять структуру данных?
Есть gitlab. Но используется не для CI/CD, а для анализа изменений и просмотра истории кода. Для CI/CD используется Jenkins, который выполняет автоматическую сборку проекта, прогон unit и сценарных тестов, статический анализ код, рассылку отчетов. Только после этого принимается решение перенести код в основную ветку и собрать дистрибутивы. Развертывание на наш внутренний прод. автоматизировано, есть скрипты которые деплоят все изменения, с созданием бэкапов, блокировками и рассылками в телегу. Для этого активно используется OneScript (https://oscript.io/) и пакеты из библиотеки для него (https://github.com/oscript-library).
Автотесты (unit/интеграционные). Насколько сложно, автоматически поднять отдельный инстанс приложения со всеми данными в контейнере и натравить на него UI тесты? А unit тесты вы пишите?
Тесты есть - unit, сценарные. По поводу контейнеров - для 1С контейнеры использовать не так просто в силу лицензионной политики 1С и разных организационных тонкостей, но в целом это возможно. Примеры использования докера есть, но не у нас :-). Для решения наших задач докер нам не нужен. У нас отдельный инстанс приложения - это отдельная информационная база. Разворачивается очень легко (либо из бэкапа с применением актуальной конфигурации, либо создается чистая база), натравить различные тесты на любую базу тоже никаких проблем. OneScript с богатой библиотекой поможет.
И еще интересно, как можно без ООП не превратить бизнесовый код в полотно спагетти-кода, без явных архитектурных границ?
ООП же не про архитектурные границы. Превратить приложение в полотно спагетти-кода можно и с ООП, и без ООП, дело не в парадигме. Чтобы контролировать качество, нужно формулировать принципы, соглашения, границы. Доносить их до команды, постоянно следить за их следованием, проводить обзоры кода и т.д.
Соблюдаем соглашение о написании кода, выделяем функции программного интерфейса и не трогаем служебный, держим с самого начала архитектора решения, проводим ревью, держим грамотных аналитиков, коммитим изменения под задачи из трекера, контролируем задачи, входящие в релиз - и код от 10+ программистов через 5 лет будет читаемый.
А когда задачи решаются за 5 минут, исходя из подхода «сделай как можно быстрее, это нужно было вчера», и так на протяжении нескольких лет, то волшебства ждать не придется.
Пару лет назад для одного холдинга мы писали интеграцию зарплатного блока с блоком HR SAP, там не хвалило нескольких аналитик в карточках сотрудников (в SAP один физик может быть только одним сотрудником, о ужас!), так добавление аналитик для обмена стоило чуть ли не 10% от всего бюджета нашего проекта (6 месяцев, 10 человек). Вокруг SAP мы как могли изгалялись, лишь бы его не дорабатывать.
Да, система ограничена своим функционалом, и заставляет «играть по ее правилам». Если вы имеете в виду «конечных пунктов» – «функциональные возможности», то зачем их в рамках одной ИС закрывать?
Например, для действительно крупного федерального сегмента в проекте вы увидите не одну только 1С и не в единственном экземпляре.
Вот конкретный пример: внедряли подсистему учета кадров и ЗП в одном федеральном ведомстве, где пользователями были все кадровые службы этого ведомства в регионах и центральном управлении (представляете количество человек, да?). И могу сказать, что каждая функциональная подсистема была реализована отдельным решением. Связь между этими решениями была через общую шину (которая тоже, кстати, на 1С была реализована).
Старт эксплуатации случился в 2018 году, и сейчас система уверенно существует и развивается, причем за последние 4 года количество программистов поддержки не увеличилось.
Это означает, что средства СУБД (или любые другие внесистемные средства) можно использовать только в том случае, если документация по продуктам линейки "1С:Предприятие" (включая 1С: ИТС) содержит явную рекомендацию использовать данное средство для решения данной задачи.
Во всех остальных случаях лицензионное соглашение позволяет использовать для построения решений только штатные средства платформы. В частности, можно обращаться к данным информационной базы только при помощи объектов "1С:Предприятия", специально предназначенных для работы с данными (запросы, справочники, документы и т. д.).
Нельзя обращаться к данным информационной базы напрямую, минуя уровень объектов работы с данными "1С:Предприятия", например, при помощи средств СУБД или при помощи внешних компонент, которые реализуют прямой доступ к СУБД. Это ограничение распространяется на любые действия с данными, в том числе на изменение их структуры, а также на чтение или изменение самих данных информационной базы или служебных данных "1С:Предприятия".
Ссылка на источник: https://v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8/
Вычислить инкремент в самом общем случае можно, использовав механизм регистрации изменений данных. Для этого необходимо управлять изменениями в рамках плана обмена. Регистрируя к обмену изменившиеся объекты и снимая регистрацию с тех объектов, которые переданы успешно.
Скорее, это no-code инструмент, Вы правы. Workflow в классическом понимании мы используем в ETL
Я разделяю Ваши сожаления, но мой пост немного про другой инструмент) Cloud - потому что он используется в облачной версии BI. В дальнейшем будет и on-prem
Если нужно видеть точные значения, то это тоже решается без каких либо проблем настройками диаграммы.
Да, конечно, можно вывести сумму (не вручную). Обычно выбор типа визуализации зависит от задачи. Этот график, например, показывает соотношение двух показателей одинаковой размерности. Например, для СЗАО - 1600 к 90, а для САО 692 к 279.
Отвечу по порядку:
Есть gitlab. Но используется не для CI/CD, а для анализа изменений и просмотра истории кода. Для CI/CD используется Jenkins, который выполняет автоматическую сборку проекта, прогон unit и сценарных тестов, статический анализ код, рассылку отчетов. Только после этого принимается решение перенести код в основную ветку и собрать дистрибутивы. Развертывание на наш внутренний прод. автоматизировано, есть скрипты которые деплоят все изменения, с созданием бэкапов, блокировками и рассылками в телегу. Для этого активно используется OneScript (https://oscript.io/) и пакеты из библиотеки для него (https://github.com/oscript-library).
Тесты есть - unit, сценарные. По поводу контейнеров - для 1С контейнеры использовать не так просто в силу лицензионной политики 1С и разных организационных тонкостей, но в целом это возможно. Примеры использования докера есть, но не у нас :-). Для решения наших задач докер нам не нужен. У нас отдельный инстанс приложения - это отдельная информационная база. Разворачивается очень легко (либо из бэкапа с применением актуальной конфигурации, либо создается чистая база), натравить различные тесты на любую базу тоже никаких проблем. OneScript с богатой библиотекой поможет.
ООП же не про архитектурные границы. Превратить приложение в полотно спагетти-кода можно и с ООП, и без ООП, дело не в парадигме. Чтобы контролировать качество, нужно формулировать принципы, соглашения, границы. Доносить их до команды, постоянно следить за их следованием, проводить обзоры кода и т.д.
Соблюдаем соглашение о написании кода, выделяем функции программного интерфейса и не трогаем служебный, держим с самого начала архитектора решения, проводим ревью, держим грамотных аналитиков, коммитим изменения под задачи из трекера, контролируем задачи, входящие в релиз - и код от 10+ программистов через 5 лет будет читаемый.
А когда задачи решаются за 5 минут, исходя из подхода «сделай как можно быстрее, это нужно было вчера», и так на протяжении нескольких лет, то волшебства ждать не придется.
Пару лет назад для одного холдинга мы писали интеграцию зарплатного блока с блоком HR SAP, там не хвалило нескольких аналитик в карточках сотрудников (в SAP один физик может быть только одним сотрудником, о ужас!), так добавление аналитик для обмена стоило чуть ли не 10% от всего бюджета нашего проекта (6 месяцев, 10 человек). Вокруг SAP мы как могли изгалялись, лишь бы его не дорабатывать.
Да, система ограничена своим функционалом, и заставляет «играть по ее правилам». Если вы имеете в виду «конечных пунктов» – «функциональные возможности», то зачем их в рамках одной ИС закрывать?
Например, для действительно крупного федерального сегмента в проекте вы увидите не одну только 1С и не в единственном экземпляре.
Вот конкретный пример: внедряли подсистему учета кадров и ЗП в одном федеральном ведомстве, где пользователями были все кадровые службы этого ведомства в регионах и центральном управлении (представляете количество человек, да?). И могу сказать, что каждая функциональная подсистема была реализована отдельным решением. Связь между этими решениями была через общую шину (которая тоже, кстати, на 1С была реализована).
Старт эксплуатации случился в 2018 году, и сейчас система уверенно существует и развивается, причем за последние 4 года количество программистов поддержки не увеличилось.