Всем привет! Меня зовут Денис Гладкий, я руководитель отдела мобильной разработки компании ZENDEN Group. В этой статье я хочу поделиться нашим опытом создания приложения для терминала сбора данных (ТСД) на Flutter с интеграцией 1С, которое мы внедрили на фабриках в Китае.

Почему я решил написать статью на эту тему?

Современные компании сталкиваются с множеством технологических вызовов, особенно в области мобильной разработки и интеграции с корпоративными системами. Я решил написать эту статью, чтобы поделиться практическим опытом и решениями, которые помогли нашей команде справиться с такими вызовами. Надеюсь, что наш опыт будет полезен другим специалистам, работающим над аналогичными проектами.

Как всё начиналось

 Изначально мы использовали готовое решение для ТСД, но вскоре поняли, что оно не справляется с нашими задачами. Наши операторы нуждались в возможности работать оффлайн с большими объемами данных, а лицензии на текущее ПО были слишком дорогими для масштабирования. Итак, мы решили создать своё собственное приложение!

Что мы хотели от нового приложения

Наша цель была проста: сделать удобное и мощное приложение для ТСД, которое могло бы:

  • Легко авторизовать пользователя и привязывать его к нужной фабрике.

  • Обеспечивать обмен документами с 1С, включая товары, их характеристики и коды маркировки.

  • Работать со сканером штрихкодов: считывать, записывать данные, проверять формат и находить дубли.

  • Сравнивать количество и характеристики товаров с запланированными данными.

  • Сохранять данные даже при непредвиденных обстоятельствах.

  • Предоставлять настройки для технических специалистов: адреса баз, выбор фабрики, язык интерфейса и авторизация.

  • Позволять работать с одним документом на двух и более ТСД одновременно.

  • Обрабатывать документы объемом до 1 миллиона записей.

  • Обновляться централизованно и удаленно, без необходимости вмешательства техподдержки.

Почему Flutter?

Вот несколько причин почему я решил выбрать Flutter:

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

Использование наработок: Мы могли использовать наработки из предыдущих проектов на Flutter. Для меня это было значительным плюсом, так как позволило сократить время разработки и использовать уже проверенные решения.

Команда разработчиков: Наша команда мобильной разработки целиком состоит из Flutter‑разработчиков. Нанимать нативного специалиста для одного проекта было бы нецелесообразным вариантом, учитывая, что проект нужно будет поддерживать. Это решение позволило нам эффективно использовать внутренние ресурсы и избежать дополнительных затрат.

Интеграция с 1С

Интеграция с 1С была ключевой частью проекта. Мы разработали REST API с нуля, используя JSON для обмена данными. Разместив наш бэкэнд в Китае, мы решили проблему с «Великим китайским файрволом» и обеспечили стабильное соединение.

База данных бэкэнда использует 1С на MS SQL. Для обеспечения высокой скорости обработки запросов с ТСД мы создали оптимизированную структуру хранения данных. Потенциально востребованные данные заранее рассчитываются в 1С, что позволяет мгновенно выдавать результаты после сканирования штрих‑кода.

Часто требуется работа с одной и той же системой из России и Китая. Решением этой задачи было выбрано развертывание распределённой информационной базы (РИБ).

  • Центральный узел 1С: ERP в России для создания заявок и заданий на фабрики.

  • Подчинённый узел 1С: ERP в Китае для интеграции с мобильным приложением для ТСД.

Узлы в свою очередь синхронизируются с помощью Kafka.

Как мы оптимизировали трафик

Создание нескольких мелких таблиц вместо одной большой позволил значительно снизить объем данных, который мы должны передать, что особенно полезно при плохом интернет‑соединении. Да, приходится делать больше запросов к базе данных, но это компенсируется улучшением скорости работы всей системы.

Еще мы убрали лишние символы из сообщений, такие как переносы строк и пробелы. Это помогло сократить объем данных на 11% без потери читаемости текста.

Но самое впечатляющее — сжатие JSON в ZIP. Оно уменьшило объем трафика на целых 85%! То есть сообщение размером в 31 мегабайт сжалось до 4.7 мегабайт. Теперь наша система работает еще стабильнее и быстрее, что особенно важно для надежности работы приложения.

На стороне Flutter мы использовали пакет archive для разархивирования данных:

Map<String, dynamic> unzipData(final String source) {
  final Map<String, dynamic> json = {};
  final Uint8List bytes = base64Decode(source);

  final Archive archive = ZipDecoder().decodeBytes(bytes);
  if (archive.isEmpty) {
    throw const ApiException(‘…');
  }

  for (final ArchiveFile file in archive) {
    if (file.isFile) {
      json.addAll(jsonDecode(utf8.decode(file.content as List<int>)));
      break;
    }
  }
  if (json.isEmpty) {
    throw const ApiException(‘…');
  }
  return json;
}

Выбор локальной базы данных

Для локальной базы данных мы выбрали SQLite + Drift. Это позволило нам эффективно работать с данными и обеспечивать высокую производительность. Приведем один из примеров реализации:

@DriftAccessor(include:{'../../../table/task/aggregation/aggregation_task.drift'})
class AggregationTaskDao extends DatabaseAccessor<AppDatabase> with _$AggregationTaskDaoMixin {
  AggregationTaskDao(AppDatabase db) : super(db);
  Future<bool> hasActiveTask() async {
    // Реализация
  }

  Future<void> saveTask($a.AggregationTask task, {final bool onlineMode = false}) async {
    // Реализация
  }

  Future<$a.AggregationTask?> getTask(String guid, {final bool onlineMode = false}) async {
    // Реализация
  }

  Future<void> removeTask(String guid) async {
    // Реализация
  }

Реализация нативной части сканирования на Flutter

На фабриках в данный момент используются две модели ТСД:

  • Newland MT90 ORCA

  • Mindeo M40 (Hyatta model 5)

Так как каждая модель ТСД использует свою инфраструктуру, был создан общий интерфейс, содержащий два метода:

Для Newland мы настроили обработчик через BroadcastReceiver, чтобы принимать данные и команды.

А для Mindeo у нас SDK, который интегрирован через build.gradle и позволяет взаимодействовать с устройством.

Все это управляется классом, который использует Dart‑часть нашего приложения через MethodChannel. Он реализует необходимые методы для работы с ТСД, что дает нам единый способ управления и мониторинга обеими моделями. Такой подход делает нашу жизнь проще, скрывая технические детали каждой модели за общим интерфейсом.

Выбор остальных пакетов достаточно стандартен и не требует детального рассмотрения. Среди них: dio для работы с Rest API, bloc для управления состоянием, sentry_flutter для отслеживания ошибок и другие.

У нас в 1С есть еще одна удобная функция: пользовательские сообщения можно хранить и править прямо на сервере. Мы сделали так, чтобы бизнес‑пользователи могли легко менять тексты сообщений и добавлять переводы на разные языки без привлечения технарей.

Теперь вся работа с формулировками и диалогами приложения происходит прямо в интерфейсе 1С. Это дает бизнесу большую гибкость и позволяет быстро адаптировать приложение под разные рынки и пользователей.

 

С каким проблемами мы сталкивались и как их решали?

Трудоемкость тестирования: Каждое изменение на бэкенде или фронтенде требовало обширных тестов, включая создание примеров в 1С, загрузку на ТСД и анализ результатов. Мы разработали чек‑листы тестов и внедрили систему фиксации результатов, что позволило нам систематизировать процесс тестирования и упростить его координацию между разработчиками.

Удаленная работа с устройствами в Китае: Внедрение нового приложения усложнялось необходимостью работы с оборудованием, находящимся в другой стране.

Для работы в Китае мы организовали пилотное внедрение, включив в рабочую группу представителей бизнеса и IT‑специалистов, что позволило активно участвовать в процессе и оперативно решать возникающие вопросы.

Создание примеров документов большого объема: Для дальнейшего развития нам требовались примеры документов с большим количеством строк, которые не были доступны на момент начала проекта.

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

Итоги

Мы разработали пилотное приложение за 6 месяцев, что значительно быстрее, чем аналогичные проекты у других компаний. Наше приложение успешно работает на более чем 200 фабриках в Китае. В первые 4 месяца около 30% устройств перешли на новое приложение, несмотря на ограниченные ресурсы технической поддержки.

В первые 3 месяца над проектом работало 8 IT‑специалистов, во вторые 3 месяца команда работала в составе 5 человек.

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

  • Интуитивный интерфейс позволяет сотрудникам осваивать ПО за несколько минут.

  • Мы сократили простои контейнеров благодаря быстрому выявлению ошибок в онлайн‑режиме.

  • Отгрузка товара стала быстрее, потому что сбои теперь решаются быстро и оперативно.

  • Кладовщики теперь могут одновременно работать с несколькими заказами, что повысило общую производительность.

Эффект от нашего проекта весьма внушительный:

  • Мы сэкономили до 5 миллионов рублей на лицензиях для ТСД, используя наше новое приложение на 250 устройствах. Экономия будет только расти с увеличением числа установок.

  • Новое приложение существенно сократило затраты на техподдержку, освобождая ресурсы для других важных задач.

А вот еще фото прямо с рабочего процесса

Надеемся, что наш опыт будет полезен для вас и поможет в решении аналогичных задач. Если у вас есть вопросы или хотите поделиться своим опытом, пишите в комментариях!

Комментарии (8)


  1. In2mI
    16.08.2024 08:47

    Во-первых спасибо за статью. Читаю уже третью подряд историю о внедрении этих девайсов в Китае и наблюдается некоторая приемтсвенность между ними. Потратить 10 мультов на приложения, которое проблематично раскидать по рынку, чтобы сэкономить 5 на готовом. Или 12?


    1. Denisgladkiy Автор
      16.08.2024 08:47
      +1

      Спасибо за комментарий! Приятно видеть, что тема находит отклик. Понимаю, что вложения в разработку собственного приложения могут вызвать вопросы.
      Однако мы потратили меньше, чем вы подумали, и с учетом того, что установки будут продолжаться, экономия на лицензиях только увеличится. С точки зрения экономики проект уже окупился.
      Но главное, что мы вышли за рамки ограничений стороннего решения. Теперь операторы могут спокойно работать с огромными объемами данных даже без интернета. Приложение легко подстраивается под наши нужды, и мы полностью контролируем процесс разработки и поддержки, внедряя новые функции именно тогда, когда они нужны. Плюс, наши сотрудники могут работать с одним документом на нескольких устройствах одновременно, что сильно упрощает и ускоряет работу.


  1. Roffild
    16.08.2024 08:47

    Почему не "1С: Мобильная платформа"?
    Какой протокол обмена с 1С?


    1. tavadyan_david
      16.08.2024 08:47
      +1

      Как Архитектор 1С на данном проекте, отвечу на ваши вопросы.

      Почему не "1С: Мобильная платформа"?

      Рассматривали вариант с "1С: Мобильная платформа". Однако, после консультаций с профильными компаниями, получили информацию, что в реализации с 1С могут быть проблемы с железом/драйверами. Даже если бы проект был бы успешно реализован на имеющемся оборудовании, мы не могли гарантировать работоспособность решения, при смене оборудования.

      Какой протокол обмена с 1С?

      Бэк-энд для мобильного приложения полностью был написан на 1С. На стороне 1С развернули HTTP-Сервис, и разработали REST API с нуля. Получается HTTP, формат сообщений JSON. 


      1. copenhagen72
        16.08.2024 08:47

        Стандартные решения 1С настолько "прекрасны", что лучше их не использовать, понятно.

        Не постесняюсь спросить, а вообще в целом у вас 1С Управление Торговлей стоит? Сколько там осталось от дефолтной конфигурации, половина наверно? Или уже чисто сама 1С платформа для вас как фреймворк стала?


  1. Melexion
    16.08.2024 08:47

    А почему не использовали objectBox? Там ускорение при обмене было бы на порядки.

    И чем выводили большие таблицы? Плагин использовали внешний или сами писали виджеты?


    1. Denisgladkiy Автор
      16.08.2024 08:47

      В любом случае, основным ограничением для нас оставалась скорость передачи данных по интернет-каналам. Откровенно говоря, мы выбрали SQLite, потому что были уверены в его надежности и стабильной работе. ObjectBox также мог бы стать хорошим вариантом, но мы сделали ставку на SQL-запросы.
      По поводу таблиц- собирали виджетами. Сторонние пакеты для UI стараемся не использовать.


  1. Alexufo
    16.08.2024 08:47

    А что за открытие со сжатием трафика, данные не умели ранее сжиматься на уровне протокола самим вебсервером?

    ( Zip может быть не самым оптимальным вариантом на ваших данных, бинарный json может тоже дать буст в размере)