Как правильно организовать архитектуру мобильного приложения 1С для сбора заказов

← На главную

При разработке мобильного решения для торговых агентов («сбор заказов в полях») перед разработчиком встает ключевой вопрос архитектуры: как связать центральную учетную систему (например, УТ, КА, ERP, УТП или УПП) и мобильное устройство. Основные сложности заключаются в обеспечении автономной работы при нестабильном интернете, оптимизации структуры данных и минимизации нагрузки на центральную базу.

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

Архитектурная схема взаимодействия

Попытка использовать механизм распределенных информационных баз (РИБ) напрямую между сервером и мобильным приложением не подходит, так как создание полноценного образа РИБ для мобильной платформы не поддерживается. Перегружать мобильное устройство тяжелой структурой метаданных из центральной базы также нельзя из-за ограничений встроенной СУБД SQLite и ресурсов смартфона.

Оптимальная архитектура состоит из трех основных компонентов:

Центральная база (ЦБ): Содержит полную номенклатуру, цены, остатки и заказы. В ней создается объект метаданных ПланОбмена (без признака РИБ) для фиксации изменений и публикуются HTTPСервисы для взаимодействия с устройствами.
Мобильное приложение (МП): Самостоятельная легковесная конфигурация, содержащая только необходимые реквизиты и таблицы (упрощенные справочники номенклатуры, контрагентов, документ заказа).
Транспортный слой: REST-запросы (JSON по протоколу HTTP/HTTPS), передающие только зарегистрированные дельты изменений и отправляющие созданные заказы в ЦБ.

Проектирование структуры данных в мобильной конфигурации

Проанализируем структуру объектов мобильного приложения. Справочники в МП создаются с теми же именами, что и в центральной базе (например, Справочник.Номенклатура, Справочник.Контрагенты), однако состав их реквизитов сокращается до минимума.

Для мобильного приложения важны следующие правила проектирования:

Хранение уникальных идентификаторов: Сопоставление объектов выполняется по УникальныйИдентификатор (UUID), который хранится в базе или сопоставляется на этапе сериализации.
Денормализация данных: Встроенная в мобильную платформу СУБД SQLite медленнее выполняет тяжелые запросы со множеством соединений. Поэтому актуальные цены, остатки и скидки рекомендуется хранить в плоских регистрах сведений без сложных связей.
Отказ от лишних метаданных: Из мобильной конфигурации исключаются бухгалтерские счета, сложные виды субконто, реквизиты печати и неиспользуемые табличные части.

Регистрация изменений и передача данных через План обмена

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

Рассмотрим, как устроен процесс обмена по шагам:

При изменении цен, остатков или карточек номенклатуры в ЦБ система автоматически выполняет регистрацию изменений на узле конкретного торгового представителя.
Мобильное приложение инициирует HTTP-запрос на получение данных, передавая идентификатор своего узла и номер последнего принятого сообщения.
HTTP-сервис ЦБ считывает зарегистрированные изменения с помощью объекта ВыборкаИзменений, формирует JSON-пакет и возвращает его мобильному клиенту.
После успешного разбора пакета в SQLite мобильное приложение подтверждает прием, и в ЦБ вызывается УдалитьРегистрациюИзменений().

Посмотрим на пример обработки изменений в коде HTTP-сервиса на стороне центральной базы:


Функция ПолучитьИзменения(УзелОбмена, НомерСообщения) Экспорт

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

КонецФункции

Прием заказов и асинхронная обработка

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

Рассмотрим важные рекомендации по обработке входящих заказов в ЦБ:

Асинхронная запись через буфер: Не рекомендуется выполнять проведение тяжелого документа непосредственно в контексте HTTP-запроса. При медленном интернете или блокировках таблиц мобильное приложение получит таймаут. Надежнее записать сырой JSON во входящую очередь (буферный регистр или вспомогательный документ) и сразу вернуть статус 200 OK.
Фоновое проведение: Регламентное задание в ЦБ разбирает очередь, создает типовой документ ЗаказПокупателя / ЗаказКлиента, выполняет валидацию остатков и проводит его.
Исключение коллизий: Идентификация переданного заказа строится по UUID, сгенерированному на мобильном устройстве. Это гарантирует, что при повторной отправке одного и того же пакета заказ не продублируется.

Пример структуры входящего HTTP-сервиса для регистрации заказа:


Функция ПринятьЗаказ(ЗапросHTTP)
    
    ТелоСтрокой = ЗапросHTTP.ПолучитьТелоКакСтроку();
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(ТелоСтрокой);
    ДанныеЗаказа = ПрочитатьJSON(ЧтениеJSON);
    ЧтениеJSON.Закрыть();
    
    // Запись во входящую очередь без мгновенного проведения
    ЗаписьОчереди = РегистрыСведений.ОчередьВходящихЗаказов.СоздатьМенеджерЗаписи();
    ЗаписьОчереди.ИдентификаторЗаказа = ДанныеЗаказа.ИД;
    ЗаписьОчереди.ДатаПолучения = ТекущаяДатаСеанса();
    ЗаписьОчереди.ДанныеJSON = ТелоСтрокой;
    ЗаписьОчереди.Статус = Перечисления.СтатусыОбработкиЗаказов.ВХранилище;
    ЗаписьОчереди.Записать();
    
    ОтветHTTP = Новый HTTPСервисОтвет(200);
    ОтветHTTP.УстановитьТелоИзСтроки("{""Статус"": ""Принято""}");
    Возврат ОтветHTTP;
    
КонецФункции

Оптимизация передачи больших объемов данных

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

Пагинация (порционная выгрузка): Данные передаются пачками (например, по 500–1000 элементов) с использованием параметров запроса Страница или Смещение. Это предотвращает нехватку оперативной памяти на мобильном устройстве.
Сжатие трафика: Большие JSON-ответы упаковываются на стороне сервера с помощью сжатия (Gzip / Zip) и распаковываются перед записью в мобильную базу.
Раздельная передача картинок и файлов: Медиафайлы не включаются в состав основных пакетов обмена. Изображения запрашиваются мобильным приложением отдельными асинхронными вызовами по мере необходимости и кэшируются локально.

Альтернативный вариант: Мобильный клиент с автономным режимом

Если нет необходимости разрабатывать собственную конфигурацию с нуля и вручную настраивать сериализацию через HTTP-сервисы, можно рассмотреть технологию Мобильный клиент с автономным режимом. В этом случае используется основная конфигурация предприятия (например, 1С:Управление торговлей 11), для которой адаптируются мобильные формы. Платформа 1С берет на себя автоматическое переключение в автономный режим при потере связи и последующую фоновую синхронизацию данных встроенными механизмами.