Онлайн режим обработчиков Simple через шину c веб-сокетами на 1С 8.3.27. И пара полноценных конфигураций-примеров для 1С БП 3 и 1С УТ 11
В Simple появился еще один онлайн-режим, не через REST-API, а через веб-сокеты. Показываю, что это дает, ради чего было сделано. А также два чисто онлайновых примера с такими обработчиками еще и с использованием новой ActiveCV 2.0. Дополнение к основной статье https://infostart.ru/1c/tools/1153616/
- Описание
- Подробнее
Описание
Для чего нужно?
Задачи, которые ставятся перед такой архитектурой:
- Возможность не публиковать 1С HTTP-сервис во внешний интернет. Вместо этого публикуется маленький скрипт, по желанию — либо на собственном сервере/компьютере, либо на VPS. Это позволяет работать даже тем клиентам, у кого нет ни серверной 1С, ни как такового сервера, при этом не нужно выносить данные в облако. Безопасность остается на уровне.
- Повышение производительности за счет архитектуры и технологии. Отзывчивость таких запросов значительно выше, чем у HTTP-запроса, за счет того, что не нужно устанавливать соединение. Также архитектура выполнения обработчиков не синхронная, как в случае обычного online, а всегда асинхронная, что позволяет разгрузить приложение.Можно разгрузить бек систему за счет распределения нагрузки на шину
- Приложение может работать с бесконечным количеством серверов, либо распределенных серверов
Как это работает?

1. Публикуется скрипт «шина». Для целей именно обработчиков полноценная шина SimpleBus не нужна, поэтому я сделал упрощенный скрипт из полутора сотен строчек. Оттуда убраны очереди, кеширование данных, http-интерфейс и все что не нужно, осталось только необходимое. GitHub тут https://github.com/dvdocumentation/simplebuslite
Это если вы хотите разместить шину у себя. По умолчанию можно работать через мою такую же шину на VPS, настройки прописаны в расширениях по умолчанию.
По умолчанию авторизация отключена, но можно завести пользователей (в СУБД на шине) и включить авторизацию.
Скрипт можно переписать, в т.ч. на более быстром языке. Это не принципиально, важно задать архитектуру и стандарт.
2. В 1С устанавливается расширение, которое работает как клиент для этого скрипта-шины. Там нужно прописать настройки – URL шины, токен (об этом далее)

3. Вся адресация работает на «токенах». Например, у вас есть конфигурация 1С: ERP , вы публикуете от нее токен SimpleConnect_erp_692f4a8d_2c68_40be_82df_4f4b9224ee1e (имя сгенерировано автоматически) и шина теперь «знает», что владелец токена – это вот этот клиент SimpleConnect_erp_692f4a8d_2c68_40be_82df_4f4b9224ee1e. Но клиенты, подключенные к шине (Simple), не знают такой длинный токен, у них в конфигурации прописано просто “erp” – это псевдоним токена. На клиенте хранится БД соответствия токенов и их псевдонимов. Клиент, например, через QR считывает настройки вашей ERP и теперь его Simple запомнил, что erp это SimpleConnect_erp_692f4a8d_2c68_40be_82df_4f4b9224ee1e. Теперь, когда он передает запрос, он в назначении указывает именно это токен. Звучит сложновато? На самом деле это все делается автоматически. А нужно это для того, чтобы: 1) клиент мог работать с несколькими базами одновременно в рамках одной конфигурации 2) чтобы можно было работать в облаке с одной конфой, но разными серверами (например, эти примеры к статье – у всех прописано bp, шина допустим одна (моя на VPS) но токены у всех разные, за счет такой архитектуры каждый работает в рамках своего токена)
4. В Simple один раз сканируются настройки (их также можно установить из кода) и он начинает отправлять синхронные и асинхронные запросы. Работает это так. Возникает событие, запускается обработчик onlinews. Он может быть синхронным, асинхронным или «с прогресс-баром». Для каждого вызова приваривается уникальный номер execute_id, который уходит в запросе на шину, а потом в бек-систему, а потом возвращается в виде «ответа». Ответ в кавычках, потому что в архитектуре веб-сервисов нет ответов, это просто сообщения. Все это время Simple терпеливо ждет сообщения от шины с таким execute_id. В случае синхронного запуска он блокирует UI и «подвешивает» систему. В случае runprogress показывает крутилку. В случае асинхронного обработчика ничего не блокируется, но когда будет получен ответ, может быть выполнен обработчик postExecute
Вместе с запросом туда-сюда ходит стек переменных/команд. Ожидание ограничено временем ожидания (по умолчанию 10сек, задается в настройках)
Таким образом вся обработка выполняется на стороне 1С. Отладка, естественно, тоже доступна на стороне 1С.
Вот пример обработчика события new_barcodes_detected. Тут он берет из массива найденных штрихкодов кадре штрихкод, ищет по базе, подкрашивает надпись в предпросмотре камеры и открывает диалог для ввода количества.
