Взаимодействие с сотрудниками и клиентами из одного окна конфигурации 1С (Телеграм, ВКонтакте, Facebook, Discord). Преимущества, технические особенности, подводные камни

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

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

Омниканальность при работе с клиентами

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

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

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

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

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

Предпосылки к разработке

Проект для взаимодействия обслуживающих организаций с клиентами мы начали еще в 2013 году.

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

• Сотрудники организации работали из 1С – отправляли простые сообщения.

• А клиенты работали просто из личного кабинета на сайте.

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

• Кроме этого, в мире активно развивался тренд интеграции – появилось API у Telegram, самое первое из хороших. У ВКонтакте API появилось чуть раньше, но с Telegram сообщество быстрее пошло в сторону развития интеграции.

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

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

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

• WhatsApp, потому что он наиболее популярный;

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

• ВКонтакте – достаточно популярная социальная сеть;

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

• И Viber – тоже довольно популярный мессенджер

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

• популярен;

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

Что касается интеграции:

• Отправляем команды через REST API. Обычные HTTP-запросы сериализуются в JSON, а если мы передаем файлы, Telegram их сериализует в multipart/form-data.

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

• Так как период пилота пришелся на блокировку Telegram со стороны Роскомнадзора, мы организовали обход этой блокировки – исходящие запросы шли через специальный прокси-сервер. Арендовали виртуалку в Голландии и там подняли реверс-прокси – получилось довольно просто.

Наша реализация омниканальности

Что нам пришлось реализовать на стороне 1С:

• Для приема call-back-сообщений в 1С используется такой объект метаданных как HTTP-сервис. Некоторые нюансы работы с ним я расскажу дальше, в технической части доклада. Соответственно, простой набор методов позволяет нам принимать информацию о поступлении новых сообщений, о редактировании сообщений, о нажатии кнопок и т.д.

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

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

Сценарии, которые мы поддержали – это:

• все виды текстовых сообщений,

• файлы и картинки,

• команды,

• кнопки в сообщениях.

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

Что из себя представляет приветственный скрипт?

• Нам пишет новый пользователь – мы о нем знаем только идентификатор Telegram.

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

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

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

Взаимодействие с мессенджерами из 1С – итоги пилота и выводы

Как итоги – в целом в функциональности получилось достигнуть скорости работы и скорости обмена сообщениями, сравнимой с десктопом. Мы переписываемся между двумя клиентами в Telegram или мы переписываемся Telegram + приложение на 1С – скорость обмена сообщениями примерно схожая.

Наиболее трудоемкая техническая часть, с которой мы столкнулись – это формирование тела multipart/form-data. Это связано с передачей файлов. Такой тип тела HTTP-запроса 1С не поддерживает из коробки. При этом Telegram отдает и принимает файлы именно в этом формате. Соответственно, пришлось ручным формированием двоичных данных строк это все делать.

Дальше мы пошли в сторону других мессенджеров.

• Реализовали взаимодействие с ВКонтакте. По опыту – очень похожее API на Telegram, там похожая схема взаимодействия.

• Реализовали интеграцию с Facebook. Там чуть сложнее API. Единственное, уже когда мы это реализовали, нас настигло изменение правил регистрации бизнес-аккаунтов в Facebook. Если раньше можно было просто зарегистрироваться и подключить бота – этого было достаточно, чтобы общаться со своей группой в Facebook, сейчас там стало достаточно сложно – нужно подтвердить, что ты реально являешься организацией, отправить учредительные документы. Поэтому этим ботом довольно мало пользуются.

• Skype и Viber – смотрели, но за время пилота для Skype изменились условия создания бизнес-аккаунтов. Они вообще очень недружелюбно настроены к бизнесу из России, создание бота платное, еще и из России недоступное. Поэтому от Skype отказались. По Viber тоже пытались выяснить, а как создать бота, как предоставить обслуживающим организациям, которые пользуются нашим продуктом, возможность от имени этого бота общаться с клиентами – в итоге понятных условий выяснить не удалось, и тоже отказались.

• WhatsApp – интересный кейс. С одной стороны, очень хочется, но пугают сторонние и промежуточные неофициальные сервисы – пока не очень хочется с ними интегрироваться. А создание бизнес-аккаунта опять же напарывается на бюрократию Facebook, поэтому с ним пока боремся. Рано или поздно мы его победим. Технически – мы общались с партнерами, которые реализуют бизнес-подключение – в целом все точно так же. Есть API, через которое мы взаимодействуем, есть call-back, по которому мы получаем информацию о входящих сообщениях и какой-то активности со стороны клиентов. Соответственно, дальше заворачиваем это в свою бизнес-логику.

Итоговая функциональность

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

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

Демонстрация

Покажу, как оно выглядит и как работает.

У нас здесь есть рабочее место, где в контексте «единого окна» достаточно быстро прогружаются сообщения для каждого из клиентов организации. Видно, как история взаимодействия с клиентом быстро выводится в ПолеHTML-документа при выделении конкретной строки в левой части окна.

Также можно просматривать каждый конкретный канал взаимодействия с клиентом по отдельности.

Сейчас здесь во вкладках показано две карточки клиентов – одному подключен чат ВКонтакте, другому подключен Telegram.

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

Аналогично и с ВКонтакте. Могу оттуда отправить сообщение, и буквально в течение нескольких секунд оно приходит в ленту.

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

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

Инструменты для взаимодействия с сотрудниками

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

• уведомляют сотрудников о новых задачах;

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

• отправляют уведомления систем мониторинга, в том числе пересылают сообщения от сисадминов из Telegram в Discord;

• обрабатывают заявки;

• и многое другое.

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

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

Вопрос «Зачем себя автоматизировать» имеет довольно логичный ответ:

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

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

Отдельно несколько слов скажу про Discord. Исторически мы сидели в Skype и в Telegram, но у них есть существенный минус – там все равно с каждым нужно переписываться в отдельном чате, из-за чего открывается несколько сотен таких чатов.

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

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

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

Это гораздо быстрее, чем по одному добавлять человека в разные чаты.

Аналогичная функциональность есть и у других корпоративных мессенджеров Microsoft Teams, Slack. У них также есть средства интеграции. Но с Discord как-то у нас пошло быстрее. Плюс он легкий для старта в части бесплатного использования. Ты создал сервер, сделал API и полетели.

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

Расскажу про особенности интеграции Discord с 1С, которые вызвали неудобства.

• Во-первых, Discord не поддерживает call-back на сценариях получения сообщений, в нем мгновенное получение сообщений реализовано через технологию веб-советов. А 1С не умеет работать с веб-сокетами. Даже если для получения данных написать на клиентской стороне JS-код, сообщение все равно придется вытаскивать.

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

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

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

Технические решения

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

Первое – это журналирование работы HTTP-сервисов. Под журналированием я имею в виду:

• Регистрацию ошибок – потому что если у нас возникают ошибки, пользователи не всегда сразу о них сообщают. Желательно знать об ошибках самим и заранее – и исправить их до того, как пользователь успел заметить.

• Замер скорости работы – к скорости работы крайне чувствительны некоторые мессенджеры, которые работают с call-back. Если вызов завершается по таймауту, они считают, что сообщение не доставлено, начинают отправлять повторно. Из-за этого могут возникнуть дубли сообщений, ошибки, может вообще остановиться весь транспорт сообщений.

• И третье решение – это логирование запросов, которое позволяет расследовать какие-то нештатные ситуации, какое-то нетипичное поведение.

Первое – это универсальная обертка для HTTP-сервисов. Мы разрабатываем на базе «Библиотеки стандартных подсистем», поэтому часть вызовов здесь ведут в БСП.

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

• Далее – замер производительности. Для замера производительности используем подсистему «Оценка производительности БСП» и пишем замеры в регистр технологических замеров.

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

Вот пример взаимодействия с подсистемой «Оценка производительности». Мы просто вызываем соответствующие методы подсистемы, и все.

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

Следующее решение – это логирование запросов.

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

• HTTP-метод (GET или POST);

• относительный URL;

• тело запроса;

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

• если есть сложная бизнес-логика, то дополнительно сохраняем еще и информацию об ответе.

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

Логирование позволяет:

• во-первых, лучше разобраться, что же отправил нам сервер, если у нас вызов не отработал;

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

Следующее техническое решение – это разделение приема и обработки сообщений.

Внешний сервис вызывает наш call-back с указанием определенного таймаута – несколько секунд. Если выполняется какая-то долгая операция, она может отвалиться по таймауту:

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

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

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

• во-первых, это нас лишний раз нагружает;

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

Поэтому мы разделили обработку сообщений на две очереди. Обработка внешнего вызова выполняется по следующему алгоритму.

• Если на запрос требуется мгновенный ответ, мы отрабатываем выполнение бизнес-логики синхронно – такой быстрый ответ нужен, если пользователь нажал кнопку или выполнил команду (ввел что-то интерактивно). Например, он попросил нас скинуть ему список товаров – мы должны ему сразу ответить. Или он прислал свой email – мы должны ответить: «Все хорошо, мы тебя нашли». Соответственно, если команда пользователя требует мгновенный ответ, мы отрабатываем выполнение бизнес-логики непосредственно в методе HTTP-сервиса.

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

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

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

• Выполняем алгоритм обработки данных, исходя из тела запроса и относительного URL.

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

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

Такая реализация с одной стороны увеличивает стабильность работы системы, но, с другой стороны, она обязывает нас настраивать обязательный мониторинг:

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

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

• И входящих не должно быть слишком много – количество необработанных не должно подниматься выше определенного порога.

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

На демонстрации я показывал отправку сообщения в Telegram, которое в течение 2-3 секунд появилось у меня в ленте. Такая скорость достигается именно с помощью системы взаимодействия.

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

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

Как выглядит работа системы взаимодействия?

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

• Дальше мы подписываемся на это служебное обсуждение – фактически, назначаем ОписаниеОповещения, которое размещено в каком-то глобальном клиентском модуле. Это оповещение будет срабатывать, если в служебное обсуждение, на которое мы подписаны, добавится новое сообщение.

Клиент, запущенный с такими настройками, просто ждет новых сообщений.

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

• При поступлении входящего сообщения и сохранении его в базу данных, срабатывает оповещение.

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

• Широковещательно рассылаем в открытые формы через метод «Оповестить».

• И выполняем прочие обработчики, если они у нас указаны и настроены.

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

Там мы просто фиксируем ключ служебного обсуждения, получаем это обсуждение и подписываемся на него.

Получение обсуждения выполняется тоже достаточно просто – через программный интерфейс системы взаимодействия.

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

И когда на клиенте срабатывает оповещение, здесь мы просто эти данные десериализуем и в зависимости от того, что у нас там есть – например, у меня если есть флаг «ОтправитьШироковещательноеУведомление» я вызываю метод Оповестить().

Могут быть любые другие параметры в структуре и любые другие алгоритмы обработки.

Отладка HTTP-сервисов

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

Здесь нам на помощь приходит сервис ngrok. Он предоставляет домен третьего уровня, который пробрасывается на веб-сервер нашей локальной машины и переадресовывает весь трафик от call-back-ов. Причем этот домен предоставляется уже с SSL-сертификатом.

Таким образом, если у вас файловая информационная база опубликована локально на Apache или IIS, вы можете спокойно сделать ей публичный адрес, который дальше можно прописать в Telegram либо в любом другом мессенджере, поддерживающем call-back. И отлаживать все взаимодействия.

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

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

Через Postman мы можем отправить любой запрос. Более того, мы можем создать библиотеку запросов и делиться с коллегами ими. И мы можем написать с помощью него автотесты. Единственно, что для написания автотестов нужно знать JavaScript – он используется в качестве языка движка.

Ограничения платформы

Резюмирую, что какие недостатки в платформе 1С мешали нам реализовать задачу.

• Отсутствие нативной обработки multipart/form-data. Достаточно много сил ушло на то, чтобы это реализовать.

• Также мешало отсутствие библиотечной реализации работы с HTTP – то, что сделано в платформе, все равно приходится довольно сильно докручивать, чтобы можно было удобно переиспользовать. Это касается: обработки входящих HTTP-запросов; отправки HTTP-запросов и их сериализации в JSON; mime-типов; работы с заголовками и других стандартных для веба вещей.

• Отсутствие возможности подключения через websocket. Это ограничивает интеграцию с Discord и Slack – с корпоративными мессенджерами, которые построены на технологии websocket.

• Многие алгоритмы, реализованные в существующих библиотеках на других языках, приходится писать с нуля на встроенном языке 1С. Здесь наибольшую боль я испытал, когда интегрировался с Discord, потому что там, чтобы бот завелся, нужно подключиться по веб-сокету. Скачал библиотеку на Node.js – подключение к боту с Nome.js и отправка туда тестового сообщения заняла минут 10 при том, что я с JavaScript практически не работаю. Но чтобы аналогичную вещь реализовать на 1С, я потратил несколько часов. Т.е. 1С быстрый, когда мы разрабатываем вещи для товароучетной системы. Но 1С становится медленным из-за отсутствия библиотек, когда мы разрабатываем интеграционные решения.

Вопросы

Как логируются ошибки в теле HTML-документа?

Ошибки в теле HTML-документа не логируются. Их можно отследить через встроенные инструменты разработчика.

Начиная с версии платформы 8.3.14 в ПолеHTMLДокумента используется встроенный webkit, и если там нажать сочетание клавиш Ctrl+Alt+Shift+F12, открываются инструменты разработчика.

Тут есть информация об ошибках и консоль, в которой можно отлаживать любые алгоритмы на JS.

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

Дублируются ли сообщения в системе взаимодействия?

В систему взаимодействия дублирование сообщений не сделано.

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

Система взаимодействия используется исключительно как техническая шина для транспорта пуш-уведомлений.

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

Как реализовано ограничение прав?

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

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

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

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

Данная статья написана по итогам доклада (видео), прочитанного на митапе Мессенджеры и 1С.

Больше статей можно прочитать здесь.