Как организовать обмен данными между самописными конфигурациями 1С?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Организация обмена данными между двумя нетиповыми (самописными) конфигурациями — это задача, требующая не только написания кода сериализации, но и выбора правильной архитектуры. Чаще всего разработчики сталкиваются с необходимостью передачи данных через файлы (JSON/XML) или HTTP-сервисы. В данной статье мы подробно разберем, как правильно обрабатывать сложные типы данных, и какие инструменты платформы 1С помогут сделать обмен надежным.

Метод 1. Ручная сериализация в JSON: обработка ссылок и объектов

Если перед нами стоит задача передать данные через JSON, основной проблемой становится представление ссылочных типов. В 1С ссылка — это уникальный идентификатор (GUID). Рассмотрим, как правильно организовать поиск и создание объекта в базе-приемнике, чтобы избежать дублирования данных.

Проанализируем алгоритм: при получении данных мы сначала пытаемся найти объект по его УИД. Если объект не найден, мы создаем новый и принудительно устанавливаем ему тот же УИД, который был в базе-источнике. Это обеспечит идентичность ссылок в обеих системах.


// Пример обработки справочника "ФизическиеЛица"
УИД_Строка = СтруктураСообщения.ГУИД;
СправочникСсылка = Справочники.ФизическиеЛица.ПолучитьСсылку(Новый УникальныйИдентификатор(УИД_Строка));

Если ОбщегоНазначения.СсылкаСуществует(СправочникСсылка) Тогда
    СправочникОбъект = СправочникСсылка.ПолучитьОбъект();
Иначе
    СправочникОбъект = Справочники.ФизическиеЛица.СоздатьЭлемент();
    СправочникОбъект.УстановитьСсылкуНового(СправочникСсылка);
КонецЕсли;

// Заполнение реквизитов
СправочникОбъект.Наименование = СтруктураСообщения.Наименование;
СправочникОбъект.Записать();

Обратите внимание на метод УстановитьСсылкуНового(). Он критически важен, так как позволяет зарезервировать конкретный идентификатор для нового объекта до его первой записи в базу данных.

Метод 2. Работа с перечислениями

Перечисления в 1С не являются ссылочными типами в классическом понимании, и их нельзя создать программно в пользовательском режиме. Рассмотрим два способа их передачи:

  1. Передача через имя значения (строкой): Это наиболее прозрачный метод. Мы передаем строковое имя значения перечисления, которое задано в конфигураторе.
  2. Использование метаданных: Для универсальности можно использовать обращение к метаданным для поиска индекса или имени.

Разберем пример кода для универсальной обработки перечислений на стороне отправителя и получателя:


// На стороне Отправителя:
ИмяПеречисления = ЗначениеПеречисления.Метаданные().Имя;
ИндексЗначения = Перечисления[ИмяПеречисления].Индекс(ЗначениеПеречисления);
ИмяЗначения = Метаданные.Перечисления[ИмяПеречисления].ЗначенияПеречисления[ИндексЗначения].Имя;

// На стороне Получателя:
// Предположим, мы знаем, что реквизит имеет тип ПеречислениеСсылка.ПолФизическогоЛица
ИмяЗначенияИзФайла = "Мужской"; 
СправочникОбъект.Пол = Перечисления.ПолФизическогоЛица[ИмяЗначенияИзФайла];

Важно помнить: если в базе-приемнике отсутствует значение с таким именем, система выдаст ошибку. Поэтому всегда рекомендуется добавлять проверку через Метаданные.Перечисления[ИмяПеречисления].ЗначенияПеречисления.Найти().

Метод 3. Обработка составных типов данных и ПВХ

Сложнее всего обстоит дело с Планами видов характеристик (ПВХ) и реквизитами составного типа. Чтобы корректно восстановить значение в приемнике, нам нужно передать не только данные, но и информацию о типе. Посмотрим, как это можно реализовать через передачу строкового представления типа.


// Отправка информации о типе
ТипЗначенияСтрока = ОбщегоНазначения.СтроковоеПредставлениеТипа(ДанныеИБ.ТипЗначения.Типы()[0]);

// Получение на стороне приемника
СписокТипов = Новый Массив;
СписокТипов.Добавить(Тип(ТипЗначенияСтрока));
НовыйПВХ.ТипЗначения = Новый ОписаниеТипов(СписокТипов);

Для реквизитов составного типа данных (например, когда поле может быть и СправочникСсылка.Контрагенты, и СправочникСсылка.ФизическиеЛица), в JSON структуре рекомендуется передавать дополнительный маркер ТипОбъекта. На стороне приемника используйте конструкцию Если...ИначеЕсли или соответствие (массив структур), чтобы определить, к какому менеджеру справочника обращаться для поиска ссылки.

Метод 4. Использование механизмов Конвертации данных (КД 2.0 / КД 3.0)

Проанализируем ситуацию: стоит ли писать обмен «с нуля»? Если объектов много (десятки справочников и документов), ручная поддержка кода станет крайне трудоемкой. В этом случае целесообразно использовать конфигурацию «Конвертация данных».

Преимущества использования КД:

Если ваши самописки будут развиваться, внедрение Библиотеки стандартных подсистем (БСП) и подсистемы «Обмен данными» позволит вам использовать готовые механизмы регистрации изменений, обработки очередей сообщений и настройки расписаний обмена.

Метод 5. Использование Планов обмена для регистрации изменений

Чтобы не выгружать всю базу каждый раз, выясним, как передавать только измененные данные. Для этого в 1С существует объект ПланыОбмена. Создав свой план обмена и включив в него нужные объекты, вы сможете использовать метод ПланыОбмена.ВыбратьИзменения().

Рассмотрим пример регистрации изменений для узла:


// Регистрация изменения объекта для конкретного узла обмена
ПланыОбмена.ЗарегистрироватьИзменения(УзелСсылка, СсылкаНаОбъект);

// Выгрузка только измененных данных
ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(УзелСсылка, НомерСообщения);
Пока ВыборкаИзменений.Следующий() Цикл
    Данные = ВыборкаИзменений.Получить();
    // Сериализуем данные в JSON и отправляем
КонецЦикла;

Рекомендации по безопасности и производительности

При организации обмена через FTP, помните о безопасности. Протокол FTP передает данные в открытом виде. Рассмотрим возможность перехода на HTTP-сервисы. Это позволит базе-источнику передавать данные напрямую в базу-приемник без промежуточных файлов.

Основные советы:

  1. Используйте XDTO: Механизм СериализаторXDTO позволяет одной командой превратить объект 1С в XML/JSON и обратно, автоматически обрабатывая типы.
  2. Контроль уникальности: Кроме УИД, всегда передавайте «естественные» ключи поиска (ИНН/КПП для контрагентов, Артикул для номенклатуры) на случай, если объекты были созданы в двух базах независимо.
  3. Логирование: Обязательно записывайте результаты загрузки в ЖурналРегистрации или отдельный регистр сведений, чтобы оперативно находить ошибки десериализации данных.

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

← На главную