Комментарии 14
Во-первых спасибо за статью. Читаю уже третью подряд историю о внедрении этих девайсов в Китае и наблюдается некоторая приемтсвенность между ними. Потратить 10 мультов на приложения, которое проблематично раскидать по рынку, чтобы сэкономить 5 на готовом. Или 12?
Спасибо за комментарий! Приятно видеть, что тема находит отклик. Понимаю, что вложения в разработку собственного приложения могут вызвать вопросы.
Однако мы потратили меньше, чем вы подумали, и с учетом того, что установки будут продолжаться, экономия на лицензиях только увеличится. С точки зрения экономики проект уже окупился.
Но главное, что мы вышли за рамки ограничений стороннего решения. Теперь операторы могут спокойно работать с огромными объемами данных даже без интернета. Приложение легко подстраивается под наши нужды, и мы полностью контролируем процесс разработки и поддержки, внедряя новые функции именно тогда, когда они нужны. Плюс, наши сотрудники могут работать с одним документом на нескольких устройствах одновременно, что сильно упрощает и ускоряет работу.
Почему не "1С: Мобильная платформа"?
Какой протокол обмена с 1С?
Как Архитектор 1С на данном проекте, отвечу на ваши вопросы.
Почему не "1С: Мобильная платформа"?
Рассматривали вариант с "1С: Мобильная платформа". Однако, после консультаций с профильными компаниями, получили информацию, что в реализации с 1С могут быть проблемы с железом/драйверами. Даже если бы проект был бы успешно реализован на имеющемся оборудовании, мы не могли гарантировать работоспособность решения, при смене оборудования.
Какой протокол обмена с 1С?
Бэк-энд для мобильного приложения полностью был написан на 1С. На стороне 1С развернули HTTP-Сервис, и разработали REST API с нуля. Получается HTTP, формат сообщений JSON.
Стандартные решения 1С настолько "прекрасны", что лучше их не использовать, понятно.
Не постесняюсь спросить, а вообще в целом у вас 1С Управление Торговлей стоит? Сколько там осталось от дефолтной конфигурации, половина наверно? Или уже чисто сама 1С платформа для вас как фреймворк стала?
Мы не используем 1С: УТ, но используем 1С: ERP. Сама ERP у нас переписана примерно на 10%, однако, мы не используем весь ее функционал. Более того, некоторая функциональность ERP у нас вынесена в отдельные конфигурации, например, маркировка товаров.
Стандартные решения 1С прекрасны... но они не всегда подходят для больших объемов данных.
А почему не использовали objectBox? Там ускорение при обмене было бы на порядки.
И чем выводили большие таблицы? Плагин использовали внешний или сами писали виджеты?
В любом случае, основным ограничением для нас оставалась скорость передачи данных по интернет-каналам. Откровенно говоря, мы выбрали SQLite, потому что были уверены в его надежности и стабильной работе. ObjectBox также мог бы стать хорошим вариантом, но мы сделали ставку на SQL-запросы.
По поводу таблиц- собирали виджетами. Сторонние пакеты для UI стараемся не использовать.
А что за открытие со сжатием трафика, данные не умели ранее сжиматься на уровне протокола самим вебсервером?
( Zip может быть не самым оптимальным вариантом на ваших данных, бинарный json может тоже дать буст в размере)
Согласен, что такой подход очень эффективный. Но Dart реализации по работе с BSON которые я видел оставляли желать лучшего (и поддержка либ не особо активна).
Можно по подробнее про состав команды? По какой методологии работали? Кажется, что 5 человек очень компактно. И еще, если есть такое, то как происходит расширение новыми образцами ТСД?
Состав команды 6 человек:
Директор по инновациям, взял на себя функции РП
Бэк на 1С, два человека: Архитектор + Разработчик
Мобильное приложение на Flutter, два человека: Архитектор + Разработчик
Аналитик, на проекте был только один
Методология проекта - классический Agile, с недельными спринтами. Спроектировали MVP версию, внедрили, далее итеративно расширяли функционал.
Как мы создали приложение для ТСД на Flutter с интеграцией 1С и внедрили его на 200 фабриках в Китае