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

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

При проектировании мобильного решения для крупной информационной базы (например, базы учета заявок IT-отдела, содержащей более 500 000 документов) разработчики сталкиваются с критически важным архитектурным выбором. От этого выбора зависит производительность системы, стабильность ее работы в условиях плохого покрытия сети, скорость разработки и, что немаловажно, стоимость лицензирования. Разберем подробно основные архитектурные пути, их достоинства, недостатки и технические нюансы реализации.

Вариант 1. Мобильное приложение как отдельная конфигурация с локальной базой данных

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

Проанализируем ключевые особенности реализации этого сценария:

  1. Оптимизация состава данных. Ни в коем случае нельзя пытаться переносить все 500 000 документов на мобильное устройство. Это приведет к переполнению памяти смартфона и падению производительности. В локальной базе данных необходимо хранить только самую оперативную информацию — например, только новые, незакрытые заявки, назначенные на конкретного сотрудника.
  2. Динамическая подгрузка нормативно-справочной информации (НСИ). Для экономии ресурсов устройства справочники (например, Контрагенты или Номенклатура) не следует полностью синхронизировать с мобильным приложением. Логичнее реализовать их динамический поиск в основной базе по мере ввода символов пользователем. При вводе наименования на мобильном устройстве приложение отправляет быстрый запрос к центральной базе и выводит результаты поиска на экран, не сохраняя их в локальную СУБД.
  3. Связь через HTTP или Web-сервисы. Обмен данными между мобильной базой и стационарной СУБД организуется через API. Для этого на стороне основной базы разворачиваются сервисы. Использование HTTP-сервисов предпочтительнее с точки зрения скорости передачи данных (формат JSON компактнее и быстрее обрабатывается мобильным устройством, чем XML в Web-сервисах).

Рассмотрим пример реализации простейшего REST-сервиса на стороне стационарной базы для передачи списка активных заявок по ответственному сотруднику:


// HTTP-сервис: ПолучитьСписокАктивныхЗаявок
Функция ПолучитьСписокЗаявок(Запрос)
    
    Ответ = Новый HTTPСервисОтвет(200);
    
    ЗапросЗаявки = Новый Запрос;
    ЗапросЗаявки.Текст = 
        "ВЫБРАТЬ РАЗРЕШЕННЫЕ
        |	ЗаявкаВIT.Ссылка КАК Ссылка,
        |	ЗаявкаВIT.Номер КАК Номер,
        |	ЗаявкаВIT.Дата КАК Дата,
        |	ЗаявкаВIT.Описание КАК Описание,
        |	ЗаявкаВIT.Статус КАК Статус
        |ИЗ
        |	Документ.ЗаявкаВIT КАК ЗаявкаВIT
        |ГДЕ
        |	ЗаявкаВIT.Ответственный = &Ответственный
        |	И ЗаявкаВIT.Статус В (ЗНАЧЕНИЕ(Перечисление.СтатусыЗаявок.ВРаботе), ЗНАЧЕНИЕ(Перечисление.СтатусыЗаявок.Новая))";
    
    ИмяПользователя = Запрос.ПараметрыЗапроса.Получить("ИмяПользователя");
    ПользовательСсылка = Справочники.Пользователи.НайтиПоРеквизиту("ИмяВхода", ИмяПользователя);
    ЗапросЗаявки.УстановитьПараметр("Ответственный", ПользовательСсылка);
    
    Результат = ЗапросЗаявки.Выполнить().Выгрузить();
    
    МассивЗаявок = Новый Массив;
    Для Каждого Строка Из Результат Цикл
        СтруктураЗаявки = Новый Структура;
        СтруктураЗаявки.Вставить("UID", Строка(Строка.Ссылка.УникальныйИдентификатор()));
        СтруктураЗаявки.Вставить("Номер", Строка.Номер);
        СтруктураЗаявки.Вставить("Дата", Строка.Дата);
        СтруктураЗаявки.Вставить("Описание", Строка.Описание);
        СтруктураЗаявки.Вставить("Статус", Строка(Строка.Статус));
        МассивЗаявок.Добавить(СтруктураЗаявки);
    КонецЦикла;
    
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, МассивЗаявок);
    СтрокаJSON = ЗаписьJSON.Закрыть();
    
    Ответ.УстановитьТелоИзСтроки(СтрокаJSON, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);
    Возврат Ответ;
    
КонецФункции

Преимущества мобильного приложения:

Недостатки мобильного приложения:

Вариант 2. Мобильный клиент с автономным режимом (МКА)

Мобильный клиент представляет собой аналог тонкого клиента 1С, адаптированный под экраны смартфонов. Он "на лету" транслирует формы основной базы. Начиная с версии платформы 8.3.16, появился инновационный гибридный вариант — Мобильный клиент с автономным режимом (МКА).

Выясним причину популярности этого подхода и разберем по шагам логику его работы:

МКА позволяет платформе автоматически создавать локальную базу на смартфоне на основе структуры метаданных основной конфигурации. Разработчик определяет, какие именно объекты (например, документ ЗаявкаВIT и справочник Пользователи) будут доступны автономно.

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

В современных версиях платформы (начиная с 8.3.28) существенно упростилась фильтрация данных для автономного режима. В настройках состава автономной конфигурации появилось свойство "Отбор". Теперь прямо в метаданных на языке запросов 1С можно задать фильтр (например, ограничить состав документов только теми, где Ответственный = ПараметрыСеанса.ТекущийПользователь). Платформа сама применит эти ограничения при синхронизации, исключив передачу сотен тысяч лишних документов на устройство сотрудника.

Рассмотрим особенности первого запуска МКА: важно учитывать, что самый первый запуск мобильного клиента обязательно должен происходить при стабильном интернет-подключении. В этот момент на сервере регистрируется уникальный узел обмена для данного устройства, инициализируется локальная СУБД мобильного клиента и скачивается первичный пакет необходимых данных.

Преимущества мобильного клиента с автономным режимом:

Вариант 3. Альтернативный подход — Progressive Web Apps (PWA)

Если у выездных сотрудников на объектах присутствует хотя бы нестабильный, но регулярный мобильный интернет, рассмотрим альтернативный вариант, появившийся в платформе начиная с версии 8.3.24. Это использование веб-клиента в формате Progressive Web Apps (PWA).

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

Реализация системы Push-уведомлений

Поскольку одной из ключевых задач является своевременное получение сотрудниками push-уведомлений о назначении новых заявок, проанализируем, как правильно настроить этот механизм.

Напрямую из базы 1С отправить сигнал на заблокированное мобильное устройство невозможно. Для этого требуется промежуточный сервер доставки уведомлений. Фирма "1С" предоставляет бесплатный облачный сервис "1С:Центр уведомлений", который выступает в качестве шлюза между вашей информационной базой и службами доставки Apple (APNs) и Google (FCM).

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

  1. Зарегистрировать базу на портале push-уведомлений 1С и получить уникальный API-ключ.
  2. В коде мобильного решения использовать встроенный механизм ДоставляемыеУведомления для получения и регистрации уникального токена устройства.
  3. При создании или изменении статуса документа ЗаявкаВIT в основной базе вызывать метод отправки уведомления через зарегистрированный токен.

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

Итоговые рекомендации по выбору архитектуры

Подведем итоги нашего анализа и сформируем критерии выбора архитектурного решения:

  1. Выбирайте Мобильное приложение (Вариант 1), если ваши выездные инженеры работают на абсолютно глухих объектах без какой-либо связи, интерфейс приложения требует нестандартных глубоких доработок под конкретные устройства (например, интеграция со специфическим оборудованием через внешние компоненты), а бюджет компании позволяет приобрести клиентские лицензии на мобильные рабочие места. В этом случае стройте обмен данными через эффективные HTTP-сервисы с передачей JSON.
  2. Выбирайте Мобильный клиент с автономным режимом (Вариант 2), если вы хотите минимизировать трудозатраты на программирование обмена данными, использовать преимущества автоматической фильтрации платформы версии 8.3.28 и сэкономить средства компании на покупке лицензий. На текущий момент это наиболее сбалансированное и современное решение для корпоративного сектора.
  3. Перед началом разработки обязательно изучите реализацию механизмов обмена и интерфейса в типовых мобильных конфигурациях от фирмы 1С (например, 1С:Документооборот или 1С:УНФ). Это позволит наглядно увидеть лучшие практики построения мобильного интерфейса и избежать типовых ошибок при проектировании структуры метаданных.
← На главную