OpenSource + 1С = ❤️. Как мы стали использовать платформу SimpleUI в своих проектах и почему это хорошо

Выбор оборудования и первые шаги в автоматизации

С блютусным или с проводным сканером работать неудобно. Так сложилось и так удачно получилось, что в нашем распоряжении оказалось Auto-ID-оборудование: терминалы сбора данных, мобильные устройства. И именно их мы решили использовать, чтобы «погрузить» физику и для учета.

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

Первым шагом к переменам стала маркировка молочной продукции – огромный поток данных, мчащийся по конвейерным линиям в режиме реального времени.

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

Требования к идеальному решению: простота и UX

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

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

И когда мы что-то искали, то хотели иметь в распоряжении нормальный набор инструментов для апгрейда UX. Это привело нас на форум «Инфостарта», где мы столкнулись с платформой SimpleUI.

История платформы SimpleUI

Если не ошибаюсь, первые следы SimpleUI были обнаружены в 2018 году. Тогда это была полностью 1С-ная история: конструктор на базе 1С, который позволяет за пару вечеров накидать себе фронт под мобильные устройства. Вся логика тогда выполнялась на стороне 1С, а на стороне мобилки было приложение, которое отрисовывает этот интерфейс и выступает мостиком, передавая и получая данные.

Но время шло, комьюнити «Инфостарта» продолжало двигать развитие этой платформы, и в нее стал заползать Python. Сначала просто в виде обработчиков, которые можно было добавить в 1С конструкторе и уже в оффлайн, на самом устройстве, эту логику повыполнять. А потом постепенно Python дошел до того, что сейчас есть отдельный конструктор, есть возможность подключать сторонние библиотеки (кстати, весь open-source откроется в подключении сторонних библиотек), есть поддержка асинхронщины и много чего интересного.

Архитектура платформы и ее преимущества

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

Эта архитектура в B2B-сегменте довольно удобная. Нам не надо постоянно пересобирать АПК или прокидывать большой АПК через корпоративную сеть. Для обновлений достаточно просто обновить эту конфигурацию, а конфигурация маленькая – весит порядка одного-двух мегабайт.

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

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

Я подробно разберу инструменты работы с данными, обмена данными, способ взаимодействия с андроидом и сбор информации. Но их существует гораздо больше. Все, о чем я буду рассказывать, – это использование инструментов, которые доступны «из коробки» примерно на 99%.

Цели разработки: скорость и эффективность

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

Все начинается с данных. Для работы с данными на базе платформы есть несколько СУБД на выбор. SQLite – из названия понятно, за что отвечает. Хорошо хранит большие объемы данных, позволяет быстро с ними работать, но ее структуру нужно знать заранее.

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

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

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

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

То, насколько быстро все это работает – это заслуга самих инструментов и правильной комбинации этих инструментов.

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

Инструменты обмена данными и интеграции

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

Файловый обмен HTTP мы рассматривать не будем – с ним все знакомы. Поговорим про сервер мобильного приложения WebSocket.

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

Теперь по части веб-сокетов. Нам, как разработчикам, был доступен инструмент клиента – WebSocket клиента. Можно было подключить мобильное устройство как клиент к чему-то и поддерживать постоянные соединения. Но платформа гибкая, Python гибкий – поэтому оказалось возможным написать WebSocket-сервер на одном из этих мобильных устройств, его запустить, и при помощи него все данные шейрить между всеми устройствами.

Работа с периферией: сканеры, модули и камера

Мы доставили данные, сохранили, теперь надо с ними как-то работать.

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

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

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

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

Поскольку мы работаем с камерой, работаем с видеопотоком – мы получаем еще возможность удобной визуализации и работы с обратной связью от устройств. Это и цветовая идентификация, и звуковая, и вибрации – все для того, чтобы выгадать немного скорости на том времени, в течение которого человек принимает решение. Отсканировать, посмотреть, подумать, сказать: «Ага, цена отличается» – долго, а когда телефон у тебя вибрирует в руке и обводит все красным, то становится быстрее.

Комбинирование детекторов и визуальная обратная связь

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

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

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

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

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

1. Готовьте данные заранее,

2. Не заставляйте пользователя постоянно переключаться между экранами.

Дополнительно применяйте цветовую идентификацию – это сильно упрощает восприятие.

Преимущества платформы для разработчиков

На этом хвастовство заканчивается, и перейдем к тому, что мы, как разработчики, получили от использования этой платформы:

• I - INCREMENT (MVP first, работа с обратной связью)

• D - DEVELOP. Быстрая разработка

• D - DELIVERY. Быстрая доставка

• Q D -QUICKLY DEPLOY. Быстрое развертывание

Во-первых, она позволяет нам немного «читерить». Нам очень нравится начинать всегда с прототипа: есть запрос – быстро делаем прототип, получаем обратную связь от пользователей, и уже на ее основе дорабатываем и модернизируем решение.

Для быстрой разработки у нас есть набор готовых инструментов. Быстрая доставка обеспечивается за счет того, что конфигурация весит мало, легко переносится и разворачивается. Она удобно интегрируется с MDM-системами, а при необходимости можно поднять у себя сервер, с которого будут распространяться обновления. При этом сам процесс установки достаточно простой.

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

Эволюция архитектуры и подход к разработке

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

Например, добавили работу с новым модулем – немного переписали код.

Перешли к множеству проверок и условий – еще доработали и пришли к модульной структуре.

Для ведения всех кастомных клиентских веток мы используем GitHub. Это оказалось удобным инструментом: почти каждый заказчик хочет внести изменения «под себя». И это логично: во-первых, сама система 1С очень гибкая, во-вторых, все привыкли, что решения можно адаптировать. Для нас это не проблема – под каждую кастомизацию мы просто создаем ветку от основной, вносим туда изменения, и она остается там навсегда. Ничего не теряется, к ней всегда можно вернуться. При этом собирать APK-файл не нужно: мы работаем только с конфигурацией, и все изменения вносятся буквально в пару кликов.

В ходе последовательной трансформации и эволюции решений мы пришли к тому, что в них хорошо работает модель MVC. Архитектурно все разделено на три уровня: данные, контроллер и визуализация. На картинке показана схема обработки сканирования: с одной стороны, задача выглядит простой, но на деле задействовано немало модулей.

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

Для ускорения сборки и доставки изменений мы используем Python как основной стек, и это дает возможность подключать любые IDE и использовать современные тестовые фреймворки. На изображении показан пример работы с APPIum: перед релизом автоматически тестируется сборка. В примере – три копии, но на практике их может быть значительно больше. При этом тесты можно писать самые разные.

Гибкость и расширяемость: сторонние библиотеки

Прототип можно создать очень быстро. Его легко менять и улучшать, и он будет развиваться дальше. Но может случиться так, что встроенных инструментов окажется недостаточно. Это не тупик – ограничиваться этим совершенно не нужно. Всегда можно подключить сторонние библиотеки, любые, которые найдете и которые помогут решить задачу:

• SQLiteUtils (для работы с БД)

• Excel 1.0.1 (для работы с файлами)

• OpenCV (для детекции)

• Pandas (для работы с данными)

• BeautifulSoup (для html)

• Pillow (для печати)

• Pydantic

• Matplotlib

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

Решение оказалось простым: скачиваем нужную библиотеку, подключаем ее к конфигурации буквально в несколько строк кода – и дальше работаем с Excel так, как требуется.

Если что-то в открытой библиотеке не устраивает, это можно изменить – в этом и сила Open Source. Так что создавайте крутые решения и не идите на компромиссы. В разработке возможно все, что вы способны вообразить.

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

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.