Нестандартное использование Системы взаимодействия

 

Меня зовут Павел Ванин, и я уже более пяти лет использую Систему взаимодействия.

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

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

Это мне открыло двери в новый мир – мир интеграции Системы взаимодействия и программы 1С:Предприятие с другими приложениями.

Об этом и будет мой доклад.

 

 

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

По каждому из кейсов я подробно расскажу:

• о контексте задачи – что вообще за задачу хотели решить;

• какие были предпосылки использования именно Системы взаимодействия в этом решении;

• какой принцип был заложен в решение этой задачи;

• какой получился результат;

• какие дальнейшие перспективы у этой задачи могут быть и подведу итог по задаче в целом.

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

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

 

Система взаимодействия

 

 

Впервые Систему взаимодействия фирма «1С» анонсировала в своем технологическом блоге «Заметки из Зазеркалья» 23 декабря 2016 года.

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

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

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

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

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

Благодаря этому, каждый пользовательский сеанс и серверная часть системы 1С:Предприятие выступают в роли клиентов для сервера Системы взаимодействия.

На сервере Системы взаимодействия для каждого приложения выделена некая область, в которой хранится информация:

• о пользователях системы взаимодействия;

• об обсуждениях;

• и о самих сообщениях.

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

Благодаря протоколу WebSocket с любого клиента Системы взаимодействия можно отправить информацию любому другому клиенту Системы взаимодействия. А так как и сервер 1С, и клиентские сеансы являются клиентами для Системы взаимодействия, мы можем отправлять данные в обе стороны, реализуя, в том числе, сервер-клиентские вызовы. Это очень важный момент, который лежит в основе кейсов.

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

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

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

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

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

Но зато с недавних пор появилась возможность отправлять в систему взаимодействия сообщения извне при помощи механизма webhook – при помощи обычных http-запросов.

На текущий момент сервер системы взаимодействия реализован в двух вариантах.

• Первый вариант – это бесплатный облачный сервис от фирмы «1С» 1cdialog.com

• Второй вариант – это дистрибутив для локальной установки. Он поставляется за рубли.

И здесь тоже ключевой момент: благодаря тому, что сервис 1cdialog.com от фирмы «1С» бесплатный, то и начать использовать систему взаимодействия в своей архитектуре можно без дополнительных вложений. От вас для этого ничего не требуется.

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

Также на сайте its.1c.ru в разделе с документацией по платформе есть подробное описание от вендора.

Теперь переходим к кейсам.

 

Кейс №1

 

 

Первый кейс – про двустороннюю интеграцию 1С со Skype.

В тот момент я удаленно трудился в крупной компании-интеграторе в должности разработчика 1С.

Помимо меня в этой компании в режиме работы «из дома» трудилось еще более 100 специалистов. И основным каналом взаимодействия как внутри команды, так и с клиентами, был Skype. Причем не бизнес-версия, а значит аккаунты у всех сотрудников были личные, без возможности администрирования и какого-либо контроля.

 

 

Основные недостатки Skype, которые отмечало руководство:

• Первое – это то, что контакты специалистов навсегда «засвечиваются» перед клиентами и остаются в их контакт-листах.

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

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

Поэтому я выступил с инициативой проекта по частичному переводу взаимодействия с клиентами и внутри компании на другой канал связи – на новый на тот момент механизм системы взаимодействия.

 

 

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

Мы создали чат-бот, к которому коннектится клиент, и организовали через него «единое окно» взаимодействия.

 

 

Все клиенты пишут свои сообщения чат-боту. А чат-бот просто переадресует сообщения в http-сервис на сервер 1С.

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

 

 

На сервере 1С есть информация о логине клиента в Skype – понятно, какие сотрудники с ним работают, поэтому адресация сообщений уходит конкретному нашему специалисту в систему взаимодействия.

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

Благодаря тому, что система взаимодействия позволяет перехватывать исходящие сообщения, мы перехватываем то, что написал специалист, пакуем в некое сообщение и через API отправляем в диалог Skype-бота – туда, где клиент и написал нам исходящее сообщение.

 

Профит: у нас сообщения пишутся, адресуются, отправляются, принимаются, перехватываются – с ними все хорошо.

Клиент работает только в Skype, пишет нам сообщения только там, мы принимаем их в Системе взаимодействия и все окей.

Но так ли все красиво, как кажется на первый взгляд?

 

Созданный MVP выявил ряд недостатков.

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

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

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

Но чтобы сделать это на стороне Skype, нам бы пришлось плодить ботов. Представьте: для одного клиента разные боты для разработчиков и консультантов, разные боты по разным задачам. Администрировать все это – просто ад.

 

Поэтому этот кейс дальше MVP у нас не пошел. Тем не менее все механизмы, которые мы в него заложили, мы в дальнейшем использовали для создания бота-помощника Skype для сотрудников внутри компании. Им долго пользовались, даже может и сейчас еще пользуются.

 

 

Были ли какие-то дальнейшие перспективы у этого кейса? На самом деле нет, потому что здесь оказалось много подводных камней – ограничения во взаимодействии разных систем, странности в развитии Skype и другие факторы.

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

 

Кейс №2

 

Переходим к следующему кейсу. Это замена библиотеки взаимодействия 1С с Asterisk.

Контекст:

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

Сотрудники этой компании работают в конфигурации на базе платформы 1С:Предприятие и используют IP-телефонию на базе Asterisk. Для повышения удобства работы пользователей, информация о входящих звонках выводится в их рабочие сеансы программы 1С. Там есть информация о том, кто звонит, какие по контакту были события и прочая информация.

Взаимодействие между Asterisk и 1С было реализовано с использованием довольно древней dll-библиотеки взаимодействия с Asterisk. На современных Windows эта dll не работала, и клиент был вынужден использовать старые версии, которые, например, перестали поддерживать другие программы.

Нам была поставлена задача изменить схему взаимодействия 1С с Asterisk таким образом, чтобы уйти от этой dll.

Здесь нужна небольшая предыстория, зачем нужна dll и почему Asterisk нельзя с 1С связать по-другому. Немного погружу вас в это.

Есть Asterisk. Всю информацию о звонках он передает в TCP-канал в виде пакетов, которые содержат, в том числе, информацию о номерах – вызывающем и вызываемом.

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

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

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

Сама dll-ка, как правило, подключается на стороне клиента 1С в обработчике ожидания. Получается, что каждый клиентский сеанс 1С через внешнюю библиотеку в режиме онлайн «перебирает» весь трафик, генерируемый Asterisk-ом, в поисках нужного именно ему содержания. Такое себе решение, но это необходимость.

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

Точкой входа в 1С для Asterisk стал http-сервис – на тот момент у Системы взаимодействия еще не было точки входа «извне» в виде Webhook.

Ну а отправку команд из 1С в Asterisk подняли при помощи интерфейса AJAM, но это не тема этого доклада.

Что у нас получилось в результате.

• Клиент был полностью удовлетворен – мы ушли от dll.

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

• Благодаря тому, что мы отказались от библиотеки, нам теперь не нужен обработчик ожидания, который постоянно мониторит TCP-трафик.

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

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

 

Кейс №3

 

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

Там так же Asterisk, так же 1С и ситуация тоже похожая.

У компании был организован достаточно большой колл-центр, и все менеджеры работали в системе на 1С:Предприятие, которая соединена с Asterisk.

Была поставлена задача организовать автообзвон клиентов. Отличие этого примера от предыдущего в том, что источником информации о вызове должна была стать сама программа 1С.

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

Здесь мы применили такое же решение, как и в предыдущем кейсе – при помощи сервер-клиентского вызова системы взаимодействия.

Отправка команд в Asterisk в данном кейсе была реализована также – через интерфейс AJAM. Как видим, в этой истории Asterisk не является источником для сервер-клиентского вызова, что говорит о возможности применения системы взаимодействия для решения не только для интеграционных кейсов.

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

Для пользователей это оказалось очень удобно. Они реально этим пользуются, им это нравится. Вся внутренняя переписка по всем клиентам у них теперь ведется в 1С. Чтобы что-то найти, никуда переходить не нужно.

Перспектив по развитию этого кейса нет, потому что механизм полностью законченный и реализованный. Они его используют и довольны.

 

Кейс №4

 

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

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

Боль здесь в том, что у нас очень большое количество каналов взаимодействия с клиентами – это почта, телефон, Skype, Viber, WhatsApp, Telegram, 1С-Коннект, Zoom и так далее. И людям, которые занимаются техподдержкой, приходится работать со всем этим зоопарком. Это очень сложно – пойди вспомни, в каком мессенджере клиент ждет ответ по своему вопросу.

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

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

Можно вспомнить первый кейс интеграцию со Skype, и сделать двустороннюю интеграцию с каждым каналом связи. Но представьте, сколько нужно будет организовать таких API-шек, а потом их поддерживать. Это, на мой взгляд, нестабильное решение. Где-то API обновилось, где-то сбойнуло, и за всем этим следить – проблем не оберешься.

Плюс клиенты говорят: «Мы не хотим использовать свой личный мессенджер, а какого-то рабочего мессенджера у нас нет», поэтому ограничить каналы мы тоже не можем, не можем сказать: «Пишите все в Skype!»

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

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

Осталось придумать: как же нам сделать это взаимодействие?

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

Так как же лучше сделать?

И нам в голову пришла идея использовать Webhook.

У нас есть Система взаимодействия, в которой есть Webhook-и. Делаем в нашей базе точку входа, в их базе точку входа, и простыми http-запросами отправляем по этим адресам сообщения.

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

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

И перед нами встала нетривиальная задача:

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

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

 

Чтобы решить второй вопрос, мы все это упаковали в расширение. И получилась у нас примерно следующая картина:

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

• В этот момент у него в Системе взаимодействия происходит создание (если это первичное подключение) интеграции через Webhook. В этой интеграции создается обсуждение с конкретным пользователем (он там один).

• А в нашу базу отправляется JSON, в котором есть информация об информационной базе клиента, об ее точке входа (Webhook), об идентификаторе обсуждения и об идентификаторе пользователя.

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

• Наш специалист просто пишет приветственное сообщение: «Добрый день, рады видеть вас на нашей линии техподдержки!» Это сообщение пакуется в JSON, в который добавляется идентификатор нашего пользователя – этот пользователь добавляется в обсуждение с клиентом в его информационной базе.

• Дальнейшее общение превращается просто в передачу текстовых сообщений в виде JSON между двумя информационными базами при помощи Webhook-ов.

Профит!

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

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

 

Помните, в истории про Skype я говорил, что важным каналом взаимодействия с нашими клиентами являются созвоны и возможность демонстрации экрана?

Чтобы это стало возможным в рамках нашей системы техподдержки, мы стали использовать относительно новый механизм Системы взаимодействия – возможность видеосозвонов с внешними пользователями.

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

• Этот внешний вызов генерируется, ссылка на него передается в чат клиенту, клиент переходит по этой ссылке, и у него интерфейс Системы взаимодействия открывается в браузере.

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

Мне уже нравится, что у нас получилось.

• У нас уже доступна переписка в текстовом варианте в режиме одного окна программы 1С.

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

• Клиенты нам уже пишут обращения.

А это значит, что все работает так, как мы и планировали.

В перспективах:

• Отправка файлов.

• И, опять же, в платформе 8.3.23 фирма «1С» анонсировала выпуск нового вида интеграции – это WebChat. Может быть, это тоже даст нам какие-то новые преимущества – тогда будем использовать WebChat вместо Webhook-ов.

 

Итоги

 

 

Подведу итоги по системе взаимодействия в целом.

За 5,5 лет существования Системы взаимодействия она обросла большим количеством возможностей, которые раньше в 1С были доступны только при помощи внешних сервисов или dll.

Все это ведет к тому, что платформа 1С потихоньку перестает быть «вещью в себе». Это же круто!

Рекомендую ли я использовать систему взаимодействия в своих проектах? Да, рекомендую. Но я обращаю внимание на то, что в этом случае вам придется столкнуться с проблемами молодых систем.

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

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

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

• Например, при помощи сервиса «1С:Бизнес сеть» контрагенты могут отправлять друг другу коммерческие предложения.

• При помощи сервиса «1С:ДиректБанк» можно обеспечить безопасное взаимодействие с банками по платежам.

• При помощи сервиса «1С:Курьер» можно отправлять запросы на доставку курьерским службам.

• При помощи сервиса «1С-ЭДО» все это подтверждать значимыми документами под значимыми подписями.

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

Но пока отсутствует важная составляющая сделки – это взаимодействие контрагентов друг с другом.

Когда нам нужно созвониться, поговорить - пользователю приходится «сворачивать» окно 1С и становиться пользователем Telegram, WhatsApp, телефона или чего-то еще.

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

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

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

 

Вопросы и ответы

 

Позволяет ли система взаимодействия инициировать с сервера выполнение произвольного кода на клиенте? Например, можем ли с сервера передавать показания весов, чтобы они в режиме онлайн отражались на клиенте без фоновых заданий и без дергания сервера http-запросами?

Да, такая возможность есть – мы можем перехватывать исходящие с сервера сообщения и обрабатывать их на клиенте – как для конкретного пользователя, так и для какого-то служебного сеанса.

А еще какое-то время назад в платформе появился объект метаданных «Боты», который как раз позволяет реализовать обработку входящих сообщений без запуска какого-то дополнительного служебного сеанса. Это все доступно и возможно без дополнительных инвестиций – просто за счет регистрации на бесплатном сервере 1cdialog.com.

 

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

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