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

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

В этом выступлении я расскажу о технических особенностях проекта и о программистской части.

 

 

Немного о проекте. Кордиант – крупнейший производитель шин в России. Компания управляет двумя заводами – в Омске и в Ярославле. Наше мобильное приложение для учета маркировки шин они используют с ноября 2020 года – в производстве и на складах. При этом в одной сети с приложением работает порядка 100 ТСД.

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

С ТСД в центральную базу 1С в секунду проходит порядка 2,5 транзакций – это двухсот тысяч транзакций в сутки.

Соответственно, у нас стояла задача автоматизировать эту большую сеть, где работает много ТСД вместе с центральной базой 1С.

 

Что мы внедряли и что такое БИТ.MDT

 

 

У нас есть коробочное решение БИТ.MDT. Оно состоит из:

• мобильного приложения;

• расширения для типовых конфигураций УТ11/ERP/KA, которое обеспечивает интеграцию с мобильным приложением.

Функциональные возможности БИТ.MDT:

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

• Поддерживает все операции с маркированным и не маркированным товаром;

• Поддерживает все складские операции, реализованные в 1C:ERP 2, 1C:УТ 11, 1C:KA 2.

Сегодня расскажу об особенностях мобильной платформы и двух архитектурах – о той архитектуре мобильного приложения, с которой мы начали, и той, к которой мы пришли в версии 2.0.

 

Общая архитектура системы v1.0

 

 

БИТ.MDT состоит из нескольких частей.

• расширение, которое встраивается в типовую конфигурацию;

• мобильное приложение, которое работает на ТСД;

• транспорт между этими компонентами обеспечивается через:

  • брокер сообщений на базе RabbitMQ;

  • и через Web-сервис.

Что дает использование RabbitMQ:

• RabbitMQ позволяет доставлять сообщения даже тогда, когда какие-то участники обмена вне зоны доступа, в том числе, когда центральная база недоступна. Например, мы обновляем центральную базу ERP, – база большая, обновление длится несколько часов, но в это время с двух ТСД можно собирать один заказ.

• ТСД обмениваются информацией напрямую через брокер между собой, даже если в этот момент центральная база недоступна. Это позволяет обеспечить работу 24/7 на ТСД.

• Кроме того, RabbitMQ позволяет гибко маршрутизировать сообщения между базами и доставлять их до устройств центральной базы тогда, когда они становятся доступными и выходят на связь.

Web-сервис используется только при первоначальной инициализации, когда подключают новый ТСД и нужно однократно передать на него большой объем информации. Тогда мы используем Web-сервис, чтобы 7 гигабайт прокачать на ТСД за раз.

 

Архитектура мобильной части

 

 

Что касается внутренней архитектуры, то на ТСД мы используем обычное мобильное приложение на 1С, у которого есть единственная особенность – так называемые «документы-события». Каждое событие, которое отражает фактическую операцию – например, сканирование марки при погрузке в грузовик или на паллет – оформляется в отдельный документ и сразу отправляется в RabbitMQ. Мы не используем многострочный документ с табличными частями. Одно событие – один маленький документ.

Все взаимодействие мобильного приложения с внешними системами у нас реализовано через внешние компоненты:

• для обмена с RabbitMQ по протоколу AMQP мы используем внешнюю компоненту;

• для хранения больших объемов информации и редко используемых данных мы используем внешнюю базу SQLite, информацию в которую тоже передаем через внешнюю компоненту;

• и дополнительно у нас используются внешние компоненты для работы с оборудованием – с тем же сканером, клавиатурой и т.д.

 

Особенности, с которыми мы столкнулись

 

 

Кто не знает – в мобильном приложении 1С используется обычный движок файловой базы, там внутри такая же файловая база данных, как на десктопе. Более того, можно сделать бэкап мобильного приложения и открыть на десктопе, чтобы посмотреть содержимое. Движок тот же самый.

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

Ограничен максимальный размер базы. Мы можем затолкать в мобильную базу не более 3,5 гигабайт. А нам нужно 7 гигабайт. Что делать?

• Для хранения больших объектов мы используем внешнее хранилище SQLite. Например, используем его для хранения 7 миллионов марок – это самое массовое, что у нас есть по объему. Добавляем марки в мобильную базу 1С только по необходимости. Просканировали марку, проверили, что ее нет в 1С, получаем марку из базы SQLite и добавляем в базу 1С;

• Также используем SQLite для хранения редко используемых объектов, таких как «снимок» данных центральной базы (который актуализируется);

• Не храним в мобильном приложении лишней информации, поэтому структура метаданных отличается от ERP/УТ 11.

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

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

Низкая скорость записи, особенно у ссылочных объектов. Ссылочные объекты в мобильную базу 1С пишутся со скоростью 1-10 объектов в секунду, а у нас 2,5 транзакции в секунду. Мы никак не успеваем. Что делать?

• Сообщение пришедшее по обмену пишем в базу SQLite, а затем по мере необходимости достаем оттуда и восстанавливаем объект в 1С. Объекты в 1С создаются в основном из-за интерактивных действий пользователя, а он не может нажимать кнопки чаще, чем 1 раз в секунду.

В редких случаях – когда на мобильном устройстве не хватает места или возникают проблемы с блокировками – файловые базы могут разрушиться. Что делать?

• Мы стараемся как можно быстрее отправить с мобилки информацию в центральную базу;

• Мы сделали простую повторную инициализацию. Если все сломалось, можно за 10-20 минут все на ТСД восстановить и работать дальше. Даже если базу мы разрушили, то легко сделать новую.

 

 

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

В мобильной платформе 1С не поддерживаются регл. задания. Поэтому мы организовали свой «менеджер» заданий – из обработчика ожидания форм запускаем специальное фоновое задание, которое, фактически, управляет всеми процессами: запускает обмены, обрабатывает результаты обменов и т. д.

Фоновые задания выполняются только в один поток – так же, как в файловой базе. Из-за этого мы не можем параллельно выполнять много фоновых заданий.

• У нас есть одно фоновое задание, которое вызывает последовательно: отправку сообщений, получение сообщений, обработку сообщений. В эти процедуры мы передаем количество секунд – время, сколько они могут работать.

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

Из фоновых заданий нельзя писать в те же таблички, в которые пишет пользователь при текущей работе.

• Отделяем данные, которые приходят по обмену, от данных, которые вводятся на текущем ТСД;

• Если не удалось, то максимально уменьшаем время транзакций.

 

 

Еще одна особенность заключается в том, что в мобильной платформе нет средств для организации массового обмена «все со всеми».

Классические планы обмена подразумевают обмен «один к одному» – когда мы в каждом узле регистрируем изменения для каждого узла.

Это хорошо, когда 2-3 базы, но когда 100 баз, и они обмениваются между собой – такой подход перестает работать.

Способ решения – это использовать брокер сообщений. Мы используем RabbitMQ. Мы регистрируем событие один раз, отправляем его в брокер, а дальше уже брокер сам рассылает его в нужные базы. Он этим занимается, а не мы.

Альтернативное решение – сделать Web-сервис в центральной базе, который возьмет на себя функции брокера и будет заниматься рассылкой. Фактически, это то же самое, что написать свой брокер, но только внутри 1С – тогда мы завязываемся на доступность центральной базы.

Запись данных, пришедших по обмену, – это дорогое удовольствие, поэтому нужно стараться как можно меньше отправлять по обмену. Что мы для этого делаем?

• Отправляем только то, что нужно отправить. При регистрации изменений смотрим, изменились ли реквизиты, важные для других баз и обмена. И если в номенклатуре меняется некритичный реквизит (например, ответственный менеджер), мы не отправляем эту номенклатуру в ТСД, потому что не считаем ее изменившейся;

• Используем пакетную отправку. Мы объединяем однотипные события в одно сообщение. Например, нам выписали 10 тысяч марок, одобрили использование, мы пакуем их в одно сообщение и отправим одним сообщением, а не по отдельности;

• Помещаем объекты в «снимок». При получении данных мы сначала складываем их в SQLite, а сами объекты восстанавливаем в мобильном приложении восстанавливаем по запросу;

• Упростили структуру сообщений обмена, чтобы они занимали мало места. В сообщениях хранятся только GUIDы объектов – они помещаются в снимок «как есть», а разбираются только по требованию.

 

 

Следующая особенность – «из коробки» интерфейс мобильного приложения 1С такой же, как в десктопной платформе.

Многие считают, что интерфейс мобильной платформы 1С по внешнему виду несовременный.

• В приложениях компании «Рарус», например, перерисовывают интерфейсы с использованием HTML-документа.

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

Интерфейс мобильной платформы заточен под использование тачскрина, на тыкание пальца в экран. С шинами же работают все в перчатках, в экран тыкать пальцем невозможно, поэтому нам важно обрабатывать нажатия на клавиатуру. В последних версиях платформы сделали поддержку железной клавиатуры, но там есть особенности, из-за которых мы не можем использовать стандартные возможности.

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

• Также мы перерисовали диалоговые окна: предупреждение, вопрос, чтобы можно было работать только с клавиатуры.

Основная форма представления информации в мобильном приложении – это списки. Сделать красивые списки в мобильной платформе достаточно сложно. Мы воспользовались рекомендациями специалистов «Раруса» – их статья о том, как делать списки, чтобы с ними было удобно работать, есть на Инфостарте. И сейчас для списков мы используем таблицы формы с одной или двумя колонками.

 

 

Я здесь попытался заскриншотить, что нам нарисовал дизайнер слева, а справа – то, что получается в 1С по факту.

Обратите внимание, что в мобильной платформе 1С сделать внутри одной ячейки разный цвет и шрифт, выделить что-то, не используя HTML-поле документа, невозможно. Но для нас это оказалось некритично.

 

 

Следующая особенность в том, что в мобильной платформе 1С нет специальных средств для первоначальной инициализации.

Когда у нас к работе подключается новый ТСД, на него нужно одномоментно передать базу с 7 миллионами марок – это большой объем информации.

Как бы мы это делали, если бы использовали РИБ? Мы просто бы скопировали бы базу, подключенную к РИБ, и подключили ее как еще один узел. В случае мобильной платформы мы так сделать не можем, потому что таких встроенных средств нет.

Что мы делаем? Так как у нас основная масса данных лежит в SQLite, мы готовим базу SQLite на десктопе, а дальше при первоначальной инициализации копируем готовую базу на мобилку, подключаем и дальше ее используем. Фактически это аналог копирования базы при использовании РИБ.

Мобильная платформа 1С не содержит никаких средств Mobile Device Management (MDM) для управления мобильными устройствами. Установку, обновление, инициализацию приложения на мобилке нужно делать руками, это нельзя сделать из центральной базы. Мы у себя на первом этапе этот вопрос решили так:

• Пользователи сканируют QR-код, который скачивает приложение,

• А потом сканируют второй QR-код, в котором содержатся все настройки для подключения к RabbitMQ, к Web-сервису и т.д.

Для инициализации программы на устройстве нужно последовательно просканировать два QR-кода. Ничего не надо вводить руками.

 

 

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

У нас продукт тиражный и нам важно тестировать то, что мы делаем. И желательно автоматически, а не руками.

Какой способ обхода сейчас?

• У себя на проектах мы для тестирования прикладной логики используем Vanessa Automation. Ее же мы используем для БИТ.MDT – как вы знаете, мобильное приложение можно запускать в тонком клиенте на десктопе. Если мы запускаем его в тонком клиенте, то работают все фишки обычной десктопной платформы, в том числе тестирование через Vanessa Automation. Так мы проверяем всю прикладную логику.

• Те места, где мы используем внешние компоненты, мы обошли через директивы компилятора #Если ТонкийКлиент Тогда – не выполняем вызов внешних компонент, вместо них выполняем какие-то «заплатки».

• Особенности, связанные с внешними компонентами, пока тестируем руками. Ждем 8.3.20, где обещали появление поддержки клиентов тестирования в мобильной платформе. Сможем конкретно на устройстве тестировать с использованием Vanessa Automation.

• Пытаемся использовать штатное средство для тестирования андроид-приложений – UI Automator, но с этим тоже есть проблемы, потому что все диалоговые элементы в 1С генерируются динамически, без названий, и снаружи кликать или что-то делать с такими элементами сложно.

 

Итог Архитектуры 1.0 и предпосылки перехода на Архитектуру 2.0

 

 

С такой архитектурой проект на «Кордианте» удалось запустить на 100 ТСД.

Все это используется уже полгода без особых проблем, за прошедшее время количество ТСД увеличилось на 20 штук. Инициализация одного ТСД занимает 20 минут.

ERP за этот период уже несколько раз обновлялось – с особыми сложностями мы за это время не столкнулись.

Но все равно проблемы есть.

Первая проблема связана с архитектурой:

• При работе с большими документами, в которых несколько тысяч строк наблюдаются тормоза – они связаны с записью в одну и ту же табличку при обмене и при текущей работе;

• Процесс обновления мобильного приложения все равно сложный, он фактически ручной. Отделу ИТ нужно пойти, собрать ТСД, принести в комнату и два QR-кода просканировать. Этот процесс не может быть выполнен обычными кладовщиками.

Есть еще несколько проблем, связанных самим коробочным решением БИТ.MDT и его внедрением на массовом рынке:

• В текущей архитектуре для работы БИТ.MDT требуются сторонние инструменты – RabbitMQ и вебсервер. Простые пользователи не могут это установить и настроить самостоятельно, для них это слишком сложно.

• Мобильная часть обновляется вручную, что неудобно.

• Особенность у маленьких клиентов – при длительном отсутствии связи, например, на пару дней, скапливается много сообщений и ТСД их может разбирать часами. С этим тоже нужно как-то бороться.

 

 

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

• Мы поддержали обмен через облачные CloudAMQP и добавили использование SSL – если кто-то следит за нашей десктопной компонентой PinkRabbitMQ, там тоже в связи с этим добавился SSL.

• Вместо Web-сервиса для передачи больших данных мы теперь умеем использовать S3 – либо от Amazon, либо от YandexCloud – неважно, где.

• Теперь для обычных пользователей никакого дополнительного ПО ставить не надо – мы в рамках подписки даем доступ к отдельному хосту RabbitMQ и к отдельному бакету в S3. Ничего настраивать не надо – человек купил лицензию, ввел два параметра и сразу может обмениваться через облако, лишь бы у ТСД было соединение с интернетом.

• Для крупных предприятий оставили старый вариант, когда все хостится у себя.

 

 

Более значительные изменения коснулись внутренней архитектуры. У нас появилось отдельное приложение DataProvider, которое отвечает за обмен, хранение и обновление БИТ.MDT снаружи.

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

Расскажу о DataProvider подробнее.

 

Что умеет DataProvider

 

 

DataProvider устанавливается на ТСД как отдельное приложение/служба. Установка производится при первоначальной инициализации мобильного приложения из центральной базы БИТ.MDT. Если сервис нужно обновить – это нужно довольно редко – он обновляется тоже прямо из MDT.

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

DataProvider берет на себя следующие функции

• Умеет автоматически без участия БИТ.MDT получать сообщения из центральной базы через RabbitMQ и S3, разбирать эти сообщения на объекты и складывать их в базу SQLite, пока мобильное приложение БИТ.MDT эти объекты не попросит.

• Отправляет данные – получает из мобильного БИТ.MDT данные для отправки и когда появляется связь, отправляет их и в центральную базу в фоне;

• Хранит различные объемные данные «до востребования» и предоставляет к ним доступ из БИТ.MDT через SQL запросы.

• Умеет получать обновления и обновлять мобильное приложение БИТ.MDT снаружи.

Расскажу подробнее, как производится управление автоматическими обновлениями.

 

Обновление БИТ.MDT из DataProvider

 

 

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

Если бы мы обновлялись, у нас была бы отдельная сложно решаемая задача – как синхронизировать данные между ста устройствами, как убедиться, что у всех одинаковые данные. Задача сложная и мы ее решать не беремся.

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

Как работает DataProvider для обновления. Мы из центральной базы где-то в интернете или во внутреннем хранилище, либо на Web-сервисе публикуем файл-манифест, в котором указано:

• какие устройства;

• на какую версию платформы нужно обновить;

• и где для этого взять apk-файл.

DataProvider знает, что файл-манифест лежит в таком-то месте по такой-то ссылке, и периодически следит за ним.

• Если DataProvider видит, что файл-манифест поменялся, и устройство нужно обновить, он передает через внешнюю компоненту в мобильное приложение сообщение: «Я тебя скоро буду обновлять, предупреди пользователя».

• Пользователь получает предложение обновиться и обновляет мобильное приложение.

Это нам позволило прямо из центральной базы 1С:ERP через справочник мобильных устройств определять: «Эту версию apk раскидай на эти устройства по списку». Теперь не надо ходить и собирать физически устройства.

Все делается снаружи, управляется через интернет. Получилась MDT-система на минималках.

 

Отправка и получение данных из мобильного приложения через DataProvider

 

Как я говорил, с мобильным приложением есть две проблемы.

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

• Вторая – блокировки на таблицах, мы не можем одновременно записывать данные и обеспечить текущую работу пользователю.

Чтобы решить эти две проблемы, мы вынесли отправку и получение данных во внешнее приложение.

 

 

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

• При возникновении события (записи объекты), регистрировали это событие в специальном справочнике или в плане обмена;

• В фоновом задании выгребали все зарегистрированные события из плана обмена или справочника, формировали текст сообщения и отправляли через RabbitMQ.

Теперь при возникновении события сразу формируем сообщение и высылаем в DataProvider.

• Никаких фоновых процессов, связанных с отправкой, в 1С больше нет.

• DataProvider сам при появлении связи отправляет это сообщение в RabbitMQ.

• Так как пользователь практически никогда не может генерировать события чаще, чем раз в секунду, то нет проблемы в том, что мы в этой же транзакции записи объекта сразу формируем сообщение и сразу его передаем – пользователь никого не блокирует, потому что он на своем устройстве в базе работает один.

 

 

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

• Мы периодически опрашивали RabbitMQ в фоновом задании и забирали сообщения;

• В отдельном фоновом задании пытались формировать объекты по этим сообщениям – при этом сталкивались со всем набором проблем файловой базы.

Теперь забором и хранением сообщений в базе SQLlite занимается DataProvider.

• Забором сообщений занимается DataProvider и хранит их у себя бесконечно долго – до востребования мобильным приложением БИТ.MDT;

• DataProvider понимает по сообщению, что это за сообщение, и, если оно должно храниться в базе SQLite, то сразу его туда складывает вообще без участия 1С;

• 1С, когда ему это удобно, берет нужные данные из DataProvider, с которым у него всегда есть связь.

 

Пример работы приложения

 

 

На слайде показан пример пакетной передачи марок из центральной базы в мобильном приложении и складывание в базу SQLite.

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

Обратите внимание, что хотя это JSON, он без названий полей – это способ побороться с объемом передаваемых сообщений. Заголовки полей для марок нам не нужны, потому что мы и так знаем последовательность реквизитов. Поэтому боремся за место.

Сообщение через RabbitMQ пришло в DataProvider, и тот сразу нераспарсенным складывает его в базу SQLite.

DataProvider ничего не знает про структуру объектов 1С – он просто разбирает массив из JSON в конкретный элемент и складывает сообщения в базу данных в отдельные записи.

В отдельную колонку складывает имя объекта метаданных и его GUID, и теперь, когда нам этот объект из 1С потребуется, мы его по GUID быстро найдем и только в этот момент его распарсим и создадим объект в 1С.

 

 

Как это выглядит при сканировании марки.

• Мы просканировали марку на устройстве, поискали в 1С – ее там не оказалось.

• Мы идем в базу SQLite, там есть типовой регистр сведений «Штрихкоды объектов», который хранит соответствие между штрихкодом и GUID объектов системы.

• По этому штрихкоду нашли GUID соответствующего элемента и дальше по нему нашли текст нужного сообщения.

• Создали элемент справочника штрих-кода упаковок в 1С и вернули его в вызвавшую процедуру.

С точки зрения прикладной логики это выглядит так: получить штрихкод упаковки для марки с таким-то кодом. На выходе он получает ссылку на элемент справочника 1С, но под капотом программа лезет в базу SQLite, находит соответствующее сообщение, создает элемент справочника «Штрихкод упаковок» в 1С и возвращает на него ссылку. Вот так выглядит извлечение из базы SQLite по требованию.

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

Таким образом мы решили проблему с объемом базы, которая лежит в мобильном приложении.

 

Итоги и выводы по использованию мобильной платформы на крупных предприятиях

 

 

При использовании Архитектуры 2.0 мы решили проблемы с хранением и обменами, а также адаптировали продукт для использования на массовом рынке за счет того, что:

• функции транспортировки и хранения вынесли в отдельное приложение;

• сделали возможность обмениваться через облачные сервисы.

Вся прикладная разработка у нас как была, так и осталась в 1С. Мы можем быстро адаптировать наше решение под нужды заказчика.

 

 

Выводы:

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

• Есть особенности, которые нужно учитывать.

• Преимущества мобильной платформы никуда не делись – прикладная разработка и адаптация под требования конкретного предприятия легко делается обычными специалистами 1С, которые до этого под мобилку ничего не писали. Всю механику и особенности можно скрыть на более нижнем уровне, и тогда прикладные разработчики не будут с этим иметь дело напрямую.

 

Вопросы:

 

Для чего копировать базу SQLite на локальные устройства, когда ее можно держать в централизованном облаке? Если скорость доступности не устраивает, то может быть в локальной сети держать?

Основное требование – возможность работы в режиме офлайн. Если требований к офлайну нет, то и нет нужды использовать мобильную платформу, а можно использовать мобильный клиент и тогда не надо держать нигде базу.

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

Мы тоже работаем с маркировкой и логически приходим все к тому, что нужен онлайн. Это проблема не программистов, а системных администраторов в том, чтобы повесить соответствующие точки доступа. Мы не можем хранить маркировки на локальных устройствах. Это очень дорогое и ненужное решение.

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

Второй пример, когда для маркировки нужен офлайн, – это где-нибудь на Дальнем Востоке , где 600 километров до цивилизации, и интернет встречается только изредка, и то через GSM. Там невозможно обеспечить достаточную скорость соединения и стабильность, чтобы обеспечить работу в тонком клиенте или в других онлайн-сервисах. Там связь может пропасть на день и даже не доедешь никуда, чтобы подключиться.

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

У вас большая команда разработки, которая все это делает и поддерживает?

Всего семь человек, из них штатных программистов – три человека. Плюс мы привлекаем дополнительных разработчиков на проект.

Почему мобильный клиент с автономным режимом вам не подошел?

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

Зато не нужен зоопарк всех дополнительных систем.

А как вы эти данные, которые нужны для офлайн-работы, передадите на устройства? Вам же нужно их передать.

Но если не использовать автономный мобильный клиент, нужно поддерживать одну систему, а в вашем случае – две.

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

Услышал, что вы бились за скорость передачи и за объем передаваемых данных. Зачем тогда использовался JSON, хоть и порезанный? Почему не использовали бинарный протокол? Зачем вы для хранения GUID и штрих-кодов выбрали регистр, а не справочник?

Бинарный протокол даст в полтора раза выигрыша, но, как правило, у нас передаются одинарные сообщения. Они небольшие и сжимать их особо нет смысла. Там у нас utf-8, где один байт на один символ. Ничего, кроме запятых, из лишних данных там нет.

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

Что касается регистра сведений для хранения штрихкодов – это пережиток прошлого. Когда-то мы пытались сделать в MDT такую же структуру метаданных, как в УТ, чтобы было проще разрабатывать и обмениваться. Но столкнулись с тем, что эта структура данных нерациональна, занимает много места и с ней сложно работать. Кое-где мы выпилили ее, но данный конкретный регистр не убрали. Он просто унаследован из типовых решений 1С.
 

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.