При интеграции 1С с внешними системами, такими как веб-сервисы, часто возникает задача хранения нормативно-справочной информации (НСИ). Эти данные обычно имеют разную структуру, обновляются периодически и используются в основном для расшифровки кодов в отчетах. В рамках данной статьи мы рассмотрим основные подходы к организации такого хранения, проанализируем плюсы и минусы различных объектов метаданных и разберем программную реализацию загрузки данных.
Представим ситуацию: у нас есть 5–6 различных справочников-классификаторов, получаемых через API. Каждый из них имеет свой уникальный набор полей (реквизитов). Объем данных варьируется от нескольких тысяч до десятков тысяч записей. Пользователи не редактируют эти данные напрямую, а лишь просматривают их для проверки корректности или используют в качестве расшифровок цифровых кодов в отчетности.
Первый вопрос, который возникает у разработчика: использовать ли стандартный объект Справочник для каждого классификатора или найти более универсальное решение? Разберем по шагам достоинства и недостатки каждого варианта.
Наиболее гибким решением является использование одного непериодического регистра сведений. Проанализируем ситуацию: как нам хранить разные структуры в одной таблице? Для этого мы можем применить подход, при котором ключевые поля выносятся в измерения, а дополнительные данные — в ресурсы.
Рассмотрим структуру такого регистра:
ВидСправочника: Тип Строка (или Перечисление), куда записывается техническое имя внешнего справочника (например, "TN_MODER_GR_VAG").Код: Тип Строка или Число, содержащее уникальный идентификатор записи из внешней системы.Наименование), либо универсальное поле для хранения всех остальных данных.Если справочники имеют слишком разные реквизиты, посмотрим на пример использования ресурсов типа ХранилищеЗначения или текстового поля в формате JSON. Это позволит хранить любую структуру без изменения метаданных конфигурации при добавлении новых полей во внешнем сервисе.
Когда структура определена, необходимо реализовать механизм загрузки. Выясним причину, почему важно правильно работать с наборами записей. При обновлении классификатора нам зачастую нужно полностью заменить старые данные новыми. Использование объекта РегистрСведенийНаборЗаписей с установленным отбором по измерению ВидСправочника позволяет сделать это максимально эффективно.
Разберем пример кода для загрузки данных, полученных из веб-сервиса в виде массива структур:
// Предположим, Ответ - это массив структур, полученный от веб-сервиса
// ИмяСправочникаНСИ - строковый идентификатор, например "TN_MODER_GR_VAG"
НаборЗаписей = РегистрыСведений.СправочникиНСИ.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.ВидСправочника.Установить(ИмяСправочникаНСИ);
// Очищаем старые данные перед загрузкой новых (если требуется полная замена)
НаборЗаписей.Записать();
Для Каждого Элемент Из Ответ Цикл
НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.ВидСправочника = ИмяСправочникаНСИ;
НоваяЗапись.Код = Элемент.KOD_MODER;
// Заполняем ресурсы. Если структура фиксированная:
НоваяЗапись.Наименование = Элемент.NAME_MODER;
НоваяЗапись.ДополнительныеДанные = Элемент.SNAME_MODER;
// ... заполнение остальных полей
КонецЦикла;
НаборЗаписей.Записать();
Важный момент: если записей очень много (десятки тысяч), запись всего набора сразу может потребовать много оперативной памяти. В таких случаях проанализируем возможность записи порциями (пакетами по 1000–5000 записей).
Если вы хотите добиться максимальной гибкости, рассмотрим подробнее модель EAV. Она позволяет хранить каждый реквизит справочника как отдельную запись в регистре.
Структура регистра в этом случае будет следующей:
ВидСправочникаКодОбъектаИмяРеквизита (строка, например "YEAR" или "DOR_NSI")Значение (тип Произвольный или Строка)Этот метод позволяет добавлять новые поля во внешних справочниках без какого-либо вмешательства в код конфигурации. Однако стоит помнить, что получение полной строки справочника одним запросом в такой модели будет требовать соединения таблицы регистра самой с собой несколько раз, что может замедлить формирование сложных отчетов.
Современным стандартом для 1С 8.3 является использование формата JSON. Если вам нужно просто отображать данные в отчете и вы не планируете строить по ним сложные условия отбора в запросах, попробуем хранить всю структуру строки справочника в одном текстовом ресурсе.
При получении данных из веб-сервиса мы просто сериализуем структуру данных в строку:
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, СтруктураДанныхИзСервиса);
СтрокаJSON = ЗаписьJSON.Закрыть();
// Записываем СтрокаJSON в ресурс регистра "Данные"
Для вывода в справку или отчет мы десериализуем эту строку обратно. Это избавляет от необходимости создавать десятки колонок в регистре, которые для одного справочника будут заполнены, а для другого — пусты.
Выясним причину, по которой пользователи могут жаловаться на медленную работу при большом объеме классификаторов. В 1С регистры сведений по умолчанию индексируются по измерениям в порядке их следования. Поэтому первым измерением всегда ставьте то, по которому чаще всего делается фильтрация — в нашем случае это ВидСправочника.
Для удобства пользователей можно создать общую форму списка этого регистра, где в зависимости от выбранного типа НСИ будут программно скрываться или отображаться нужные колонки. Это создаст иллюзию работы с разными справочниками в рамках одного интерфейсного окна.
Подведем итог: выбор между справочниками и регистрами сведений зависит от того, насколько глубоко данные НСИ интегрированы в бизнес-логику системы. Если это вспомогательная информация для отчетов — регистр сведений с использованием JSON или универсальных измерений является наиболее эффективным и масштабируемым решением.