ДИЗАЙН И РАЗРАБОТКА АРХИТЕКТУРЫ БОТА В МЕССЕНДЖЕРАХ: КЛЮЧЕВЫЕ АСПЕКТЫ И ПРИМЕРЫ РЕАЛИЗАЦИИ

АННОТАЦИЯ

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

Ключевые слова: API, СУБД, OLTP.

Статья:

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

Боты в мессенджерах позволяют взаимодействовать с клиентами непосредственно между действиями [1]. А это означает, что клиенты не могут забыть о взаимодействии и вся процедура становится более продуктивной.

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

• Автоматическая система ответов и обработки запросов ботами в мессенджерах работает очень быстро - почти мгновенно.

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

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

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

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

Для сохранения состояния пользователя бота в базе данных требуется ее выбрать.  Как отмечается в книге Ramakrishnan, R., Gehrke, J. "Database management systems" [2], для сохранения состояния пользовательских данных, таких как история поиска и настройки предпочтений, в приложениях, использующих базы данных, требуется выбор подходящей системы управления базами данных (СУБД). Авторы отмечают, что выбор СУБД должен основываться на требованиях к производительности и масштабируемости, а также на ограничениях ресурсов и стоимости обслуживания. Кроме того, авторы подчеркивают, что приложения, которые непрерывно обновляют данные, должны использовать транзакционные базы данных типа OLTP, которые обеспечивают быстродействие и надежность в работе.

В базе данных создается таблица, в которой будут храниться данные о состоянии пользователя бота. Ее структура представлена на рисунке 1. В этой таблице есть столбцы, которые хранить информацию о пользователе (login, id), состоянии (stage), а также можно добавить любую другую информацию. Например, здесь для контроля пользователя есть поле last_action, которое сообщает о времени последней активности пользователя.

Рисунок 1. Таблица для сохранения состояние пользователя

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

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

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

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

В абстрактном виде описанный процесс можно увидеть на рисунке 2. Здесь есть основное разбиение на слоты с названием “main”, которая в свою очередь опирается на другие слоты с названием “view_intervals” и “hello”.

Рисунок 2. Разбиения состояние приложения, через стадии

Рассмотрим на пример “view_intervals” разбиение на первом уровне. Если у пользователя будет стадия 10, то в базе сохранится по такой формуле main_stage = shift + stage. Для описанного случая это будет main_stage = 100 + 10. Более сложный пример будет для “setting_intervals” на стадии 11, но здесь будет просто дважды применение этой формулы: main_stage = shift_main + (shift + stage). Подставим значение и получаем такое уравнение: main_stage = 100 + (50 + 11).

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

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

Список литературы:

1. Churchill, E. Mobile Interactions in Context: A Designerly Way Toward Digital Ecology / E. Churchill, A. Bowser, J. Preece. — Morgan & Claypool Publishers, 2017.
2. Ramakrishnan, R. Database management systems / R. Ramakrishnan, J. Gehrke. — McGraw-Hill Higher Education, 2000.