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

Разработка обмена данными между стационарной базой на ПК и мобильным устройством — это классическая задача при создании мобильных рабочих мест. Часто начинающие разработчики путают назначение объектов метаданных, считая, что ПланОбмена сам по себе передает данные. В этой статье мы разберем, как правильно выстроить архитектуру обмена, используя планы обмена в качестве фундамента для отслеживания изменений.

Понимание роли Плана обмена в архитектуре

Прежде всего, нам необходимо уяснить критически важный момент: План обмена в 1С — это механизм регистрации изменений, а не транспорт. Рассмотрим подробнее, что это значит. Когда мы создаем узел в плане обмена, система начинает вести специализированную таблицу регистрации. Как только в основной базе создается или редактируется объект (например, СправочникСсылка.Контрагенты или ДокументСсылка.ЗаказКлиента), 1С ставит "метку" в этой таблице для конкретного узла мобильного устройства.

Таким образом, план обмена отвечает на вопрос "Что именно изменилось?", но он не знает, как доставить эти данные на телефон. Для доставки нам потребуется использовать дополнительные инструменты, такие как EnterpriseData, HTTP-сервисы или Web-сервисы.

Настройка Плана обмена для мобильного клиента

Разберем по шагам создание и настройку плана обмена. При создании нового объекта ПланОбмена в конфигураторе обратим внимание на следующие настройки:

1. Состав: Здесь мы перечисляем все объекты (справочники, документы, регистры), которые должны синхронизироваться с мобильным приложением. Важно установить режим Авторегистрация в значение Разрешить, если мы хотим, чтобы система сама фиксировала изменения при записи объектов.
2. Распределенная информационная база (РИБ): Для мобильных приложений чаще всего не рекомендуется включать этот признак. РИБ накладывает жесткие требования на идентичность конфигураций. Для мобилок лучше использовать "обмен по правилам" или через EnterpriseData, так как структура данных на мобильной платформе обычно сильно упрощена.

Программная регистрация изменений

Иногда типовой авторегистрации недостаточно. Например, нам нужно передавать на конкретное мобильное устройство заказы только одного торгового представителя. В этом случае мы проанализируем ситуацию и воспользуемся методом ПриЗаписи в модуле объекта или подпиской на событие. Выясним причину, по которой объект должен попасть в обмен, и зарегистрируем его программно:

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    // Определяем узел мобильного устройства
    УзелМобильный = ПланыОбмена.МобильныеУстройства.НайтиПоРеквизиту("Ответственный", ЭтотОбъект.Менеджер);
    
    Если ЗначениеЗаполнено(УзелМобильный) Тогда
        ПланыОбмена.ЗарегистрироватьИзменения(УзелМобильный, ЭтотОбъект.Ссылка);
    КонецЕсли;
КонецПроцедуры

Выбор формата данных: XML или JSON?

Для мобильных систем вопрос трафика и производительности стоит очень остро. Рассмотрим, какой формат лучше выбрать. Исторически 1С активно использовала XML (в частности, в механизмах EnterpriseData). Однако для современных мобильных приложений стандартом де-факто стал JSON. Он легче, быстрее парсится мобильным процессором и занимает меньше места. При реализации обмена через HTTP-сервисы мы рекомендуем упаковывать данные именно в JSON.

Организация цикла обмена через HTTP-сервисы

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

1. Запрос данных: Мобильное приложение обращается к HTTP-сервису в основной базе.
2. Выгрузка изменений: На стороне сервера 1С мы находим узел, соответствующий устройству, и выбираем изменения:
   Скопировать код

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

3. Фиксация номера сообщения: Мы отправляем пакет данных и запоминаем НомерСообщения.
4. Подтверждение получения: Когда мобильное устройство успешно приняло и сохранило данные, оно отправляет ответный запрос "Ок, получил сообщение №...".
5. Очистка регистрации: Только после подтверждения мы удаляем регистрацию изменений в основной базе, чтобы не передавать их повторно: ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, НомерПринятогоСообщения);

Фильтрация и оптимизация данных

Проанализируем вопрос производительности. Мобильное устройство не должно хранить всю историю за 10 лет. В плане обмена крайне важно настроить фильтры:

• Период: Передавать документы только за последние 30 дней.
• Остатки: Передавать только актуальные остатки по тем складам, к которым имеет доступ пользователь мобильного приложения.
• Справочники: Исключить тяжелые реквизиты (например, изображения товаров в высоком разрешении), если они не критичны для работы.

Для ускорения процесса подготовки данных на сервере 1С рекомендуем использовать Фоновые задания. Это позволит мобильному приложению отправить запрос и продолжить работу, а затем получить результат, когда сервер закончит формирование тяжелого пакета данных.

Разрешение конфликтов (Коллизии)

В процессе совместной работы над данными может возникнуть ситуация, когда один и тот же документ изменили и в офисе, и на выезде. Разберем, как с этим бороться. В плане обмена нет встроенного механизма разрешения конфликтов. Вам придется реализовать логику "кто последний, тот и прав" или "приоритет сервера" самостоятельно в коде загрузки данных.

Важный совет: При загрузке данных из мобильного приложения в основную базу всегда проверяйте версию объекта ВерсияДанных, чтобы случайно не затереть изменения, внесенные другими пользователями в офисе.

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