Всем привет! Меня зовут Андрей и наша команда занимается поддержкой и сопровождением системы управления нормативно-справочной информацией на платформе «1С:Предприятие». Одна из самых сложных и интересных задач технического характера для нас за последние годы — это обновление Библиотеки стандартных подсистем 1С в составе нетиповой конфигурации. В статье расскажем, как мы эту задачу решали, и поделимся опытом.

Что такое Библиотека стандартных подсистем 1С

Это набор универсальных функциональных подсистем для разработки прикладных решений на платформе «1С:Предприятие». Можно сказать, это ещё один уровень абстракции над технологической платформой. Он даёт прикладным разработчикам готовые функциональные блоки для переиспользования.

Какие области охватывают подсистемы в БСG:

• ведение нормативно-справочной информации (адресный классификатор, классификатор банков, валют и др.);

• работа с процессами и задачами согласования документов;

• работа с прикрепляемыми файлами;

• механизм дополнительных реквизитов и сведений, которые добавляются в пользовательском режиме;

• настройка доступа к данным информационной базы и отчёты о фактически назначенных пользователям правах доступа;

• обмен данными со смежными системами, включая обмен по правилам XML, обмен через универсальный формат и т.д.

Все актуальные версии типовых и отраслевых конфигураций 1С, начиная с наиболее простых и заканчивая такими гигантами, как «1С:ERP Управление предприятием» и «1С:Управление холдингом», построены на базе Библиотеки стандартных подсистем. Это обеспечивает, с одной стороны, стандартизацию программного интерфейса для работы с объектами конфигурации, с другой — унификацию интерфейса пользователя.

О конфигурации

Перейдём непосредственно к нашей информационной системе — это конфигурация «НСИ/ТИР», расшифровывается как «Нормативно-справочная информация/транспортно-интеграционный ресурс». Она содержит более 300 справочников и регистров сведений, которые выгружаются в смежные системы, и порядка 50 действующих интеграций, среди которых как обмены данными с информационными базами на платформе «1С:Предприятие» (по правилам обмена данными XML), так и с системами на других технологиях (в этом случае обмен реализуется либо через выгрузку данных в файлы CSV/XML/JSON, либо с использованием SOAP/REST-сервисов).

Данные справочников меняются через заявочную систему, а конкретно — с помощью документа «Заявка на изменение НСИ». Каждая заявка проходит цикл согласования, который зависит как от вида справочника и его данных (номенклатура, объекты управления, статьи затрат и т. д.), так и от конкретного вида операции — создаётся новый элемент либо меняется существующий. В конфигурации реализован собственный механизм согласования, схемы процессов можно настраивать, но механизм формирования и адресации задач используется стандартный, из состава БСП. Нормативно-справочная информация в системе сгруппирована в блоки — прикладные подсистемы. Они включают в себя:

• номенклатуру (как продукты основного производства, так сопутствующие товары и услуги);

• объекты управления (для управленческого, коммерческого, бухгалтерского учёта);

• общие классификаторы (адресный, единиц измерения, видов деятельности, банков, валют и т. д.);

• экономические и финансовые справочники (статьи затрат, прочие доходы и расходы, статьи движения денежных средств, центры финансовой ответственности и т. д.);

• данные контрагентов (группы контрагентов, типы заключаемых договоров и т. д.);

• данные по проектной деятельности (типы проектов, эталоны проектов, этапы жизненного цикла и т. д.).

С технической точки зрения, информационная система изначально была построена на Библиотеке стандартных подсистем первого поколения — версии 1.1.1. Конфигурация не основана на какой-либо из типовых или отраслевых конфигураций и не имеет отношения к системе «1С:MDM Управление нормативно-справочной информацией», это внутренняя разработка.

Сейчас мы полностью перевели конфигурацию на интерфейс «Такси» — и она работает на импортонезависимом ландшафте ОС Astra Linux + СУБД Postgres Pro

Как мы поняли, что нужно обновить базовые подсистемы БСП

Изначально для ввода адресов объектов управления использовали адресный классификатор КЛАДР («Классификатор адресов России»), актуальный на момент выпуска БСП первого поколения. Пока система развивалась, мы перешли на классификатор ФИАС («Федеральная информационная адресная система»). Причём с помощью фрагментарного внедрения подсистемы «Адресный классификатор» и общих модулей из состава БСП 2.х, без полноценного обновления базовых подсистем библиотеки. В 2022 году возникла задача перейти на адресный классификатор ГАР — «Государственный адресный реестр». ГАР — это новая версия ФИАС, он построен по тому же принципу, но реализует дополнительно к административно-территориальному ещё и муниципальное деление адресных объектов.

Мы проанализировали эту архитектуру и решили внедрять актуальные версии подсистем «Адресный классификатор» и «Контактная информация» из текущей версии БСП фрагментарно, подобно тому, как это делалось в момент перехода на классификатор ФИАС.

В работе мы использовали стандартные инструменты технологической платформы — конфигуратор и хранилище конфигурации. Однако уже на начальном этапе столкнулись со сложностями:

• Невозможно было приостановить доработку прикладного функционала конфигурации, пока будет выполняться обновление. Значит, нужно было вручную объединять доработки по внедрению актуальных версий со всеми другими, которые сделали за период внедрения.

• Код общих модулей БСП с версий 1.х и 2.х существенно изменился, включая списки параметров процедур и функций. Нужно было перенести большие фрагменты базовых общих модулей из БСП 3.х, причём так, чтобы не нарушить работу прикладных механизмов системы.

• Большое количество вызовов функции общих модулей было не только внутри конфигурации, но и из обработчиков правил обмена данными.

Поэтому мы приняли весьма спорное, но казавшееся нам тогда наиболее правильным решение — параллельно использовать две версии подсистем в составе конфигурации. Для этого подсистемы «Адресный классификатор» и «Контактная информация» вместе со всеми зависимостями перенесли в отдельную «чистую» файловую базу из шаблона БСП, затем выполнили рефакторинг: добавили к именам всех объектов метаданных префикс «ГАР». Соответствующие изменения внесли в программный код модулей и тексты запросов. И уже в таком виде подсистемы переносились в состав основной конфигурации.

В итоге внедрение подсистем завершилось успешно. Пользователи начали вводить адреса объектов управления через новую версию классификатора. С одной стороны, трудозатраты на выполнение доработки и её тестирование оказались весьма высоки (в сравнении с другими доработками системы в это же время), с другой — система контроля качества исходного кода SonarQube показала резкое снижение качества исходного кода системы. На это повлияло, во-первых, добавление определённого числа «заглушек» вместо функций, которые должны присутствовать в базовых общих модулях для работы подсистем из состава БСП 3.1, во-вторых — появилось много дублирующегося кода. Это видно по количеству вновь добавленных объектов метаданных с префиксом ГАР (как показано на снимке экрана выше).

Несмотря то, что мы успешно внедрили новый классификатор, подход с фрагментарным переносом подсистем из актуальной версии БСП в конфигурацию с сильно устаревшими базовыми подсистемами явно себя не оправдал. Поэтому один из членов нашей команды взял на себя обновление базовых подсистем с помощью среды 1С:EDT и системы управления версиями Git.

Обновление БСП с помощью среды 1C:EDT и системы управления версиями Git

Обновление сначала базовых, а затем и всех прочих подсистем БСП строилось по следующей схеме.

1. Создаем отдельную «чистую» файловую информационную базу, в ее конфигурацию переносим требуемые метаданные из шаблона БСП — необходимая подсистема плюс все подсистемы-зависимости.

2. Берем актуальную версию конфигурации НСИ/ТИР из хранилища и через промежуточную файловую базу загружаем в 1С:EDT. В основную ветку разработки репозитария Git переносим все изменения конфигурации из хранилища.

3. Из актуализированной ветки разработки создаем новую ветку для внедрения конкретной группы подсистем.

4. С помощью 1С:EDT выполняем сравнение-объединение с конфигурацией, импортированной из файловой базы, которая содержит требуемую подсистему или группу подсистем БСП.

5. Настраиваем подсистемы согласно документации, обеспечиваем их работоспособность.

6. Ветка с подсистемой «вливается» в основную ветку разработки, которая предварительно вновь актуализировались изменениями из хранилища.

7. Содержимое основной ветки разработки выгружается в cf-файл, и уже средствами конфигуратора метаданные с обновлённой версией подсистемы переносятся обратно в хранилище. Конфигурация из хранилища далее попадает на подготовительный (предпродуктивный), а затем и на продуктивный ландшафт.

Так мы успешно обновили сначала подсистемы БСП, которые обеспечивают базовую функциональность, а затем и подсистемы более прикладного характера:

• адресный классификатор и контактная информация (повторно);

• дополнительные отчёты и обработки;

• работа с файлами;

• загрузка данных из файлов;

• варианты отчётов.

Повторное обновление подсистем «Адресный классификатор» и «Контактная информация» потребовалось только тогда, когда в структуре метаданных БСП произошли изменения и формат данных классификатора на портале 1С:ИТС изменился. Мы сравнили трудоёмкость «цивилизованного» внедрения подсистем с выполненным ранее фрагментарным переносом — она оказалась приблизительно втрое ниже. Кроме того, повторное обновление помогло удалить дублирующие объекты метаданных с префиксом ГАР, что сразу же отразилось на оценке качества кода SonarQube.

Как показала практика, обновление подсистем БСП в составе конфигурации средней сложности вполне осуществимо даже сравнительно небольшой командой специалистов — всего три разработчика, которые при этом были заняты далеко не только актуализацией подсистем, но и выполнением текущих доработок, составлением документации и т. д. Сам процесс растянулся чуть более чем на полгода.

Мы с командой не останавливаемся на достигнутом и продолжаем обновлять другие подсистемы БСП до актуальных версий по мере необходимости. Современные средства разработки — среда 1С:EDT и репозитарий Git, — помогают в этом процессе, особенно в части объединения доработок.