Create the structure of a simple multi-platform bot
The structure of the system makes the development of functions for different platforms uniform and simplifies the processes by an order of magnitude compared to the option of manually rewriting them in each platform-dependent API. At the same time, to start a bot on a new platform, you just need to write the appropriate adapter (connector)
I wanted to briefly talk about this structure. Perhaps this will be useful to those who want to write their cross-platform bot, but have not yet dived deep into the topic and while studying other people's experience.
Let's get acquainted with our bot. He can be found in Telegram, VK, FB, where he serves up to several thousand people at the same time (as happens at large events). By the way, we can learn about who we are and what we do from our first article. In short, we operate a huge network of free coworking and presentation spaces throughout Russia and at the same time support the Leader-ID communication platform, which is the core of the entire system. And the bot plays an important role in the whole story.
Double gun – double fun
In fact, we have two bots. The first is the main one, responsible for interacting with users. It is a convenient means of mobile registration of users for events, interaction with support and obtaining additional information from lectures and seminars, as well as exchanging contacts within the same ecosystem.
The second bot is essentially an interface for support operators. Bots work in conjunction, but their bases and interfaces are separated.
Using their example, we will show how the structure of such a system might look. However, we will begin to untwist this ball gradually, with simple cases.
The structure of the simplest bot
In the basic version, the bot will consist of only one service that sends and receives messages through the API of the messenger (platform) we need, for example Telegram.
If we have several messengers through which we want to communicate with users, it would be reasonable to write logic in a platform-independent style with the addition of connectors to the structure that translate commands and data from the internal format to the format of the corresponding platform (messenger).
This will make it possible to add new features in one place, and not duplicate them for each platform separately.
Connectors are services that receive messages from a platform for forwarding to the kernel and vice versa. In general, these are relatively independent components of the system, which, if necessary, can be located on a separate server, have several replicas, and so on.
We organize communication between the connectors and the kernel (polling the database, or how not to do it)
So, we are faced with the task of organizing the exchange of data between the connectors and the core. The first option is to send new messages through the database. We started from this. Accordingly, the database itself appears in our scheme, and the structure becomes like this: a kernel written in Python, plus a base on MongoDB (the reasons for this choice are exclusively historical), plus connectors.
This scheme did not work for us relatively long. When the number of messages exceeded 700 thousand, and the frequency in peaks reached 120 hits per second, the indices became heavier, the polling of the database became significantly more expensive. I had to connect the RabbitMQ broker here. Its main role is to generate notifications that a component (core / connector) should process a message with a specific identifier. These IDs are transmitted through it. RabbitMQ has unloaded the base and components, which now do not need to constantly check the database for new information for processing.
As a result, our basic structure began to look like this:
The work of connectors through the database has a minus – this reduces their independence and increases the connectivity of the system. However, if the data is transferred directly using the queue manager, then all the responsibility for their safety and availability lies with this broker. How this meets the demands for reliability and transparency is an open question. For ourselves, we decided that we would experiment with this in the process of further development of the system.
Adding Admins
To manage the entire kitchen you need an administrator interface. With its help, we find the necessary information in correspondence, edit data, do surveys and newsletters. Therefore, the web component appears in our diagram. In addition to the above, it provides a web interface for authenticating users and bot APIs.
The Web communicates with the database and the kernel through special system messages. They are routed as text, they only contain information not about a new message from the user, but about some other event in the system as a whole, to which the kernel should respond. For example, obtaining authorization codes.
The interface itself for administrators looks like this:
.
We connect operators through the second bot
To implement full user support, we connected operators to the system. To maintain the speed of communication with them, in the absence of suitable alternatives, Telegram was chosen as the main dialogue interface. Operators receive user questions through it and immediately send answers.
This is what the user dialog with the main bot looks like when sending a support question:
The phrase “Test Question” in the screenshot is the text of the question for technical support.
As a result, a second bot (Support Bot) appears on our circuit with its core and Telegram connector. He communicates with the main core and organizes the transfer of questions and answers between chats with users and chats in which support agents are sitting.
It also has its own database. But communication with the end user goes through the core of the main bot, which controls the overall flow of messages.
Here's what the operator’s dialogue looks like with a support bot that redirects user messages:
In our case, the operators are divided into two categories: those who are engaged in general user support, and those who are responsible for supporting individual boiling points or events. However, this has no effect on the structure.
What else can our bot do?
This information applies only to our practice, but perhaps it will be interesting as a selection of simple ideas that you can take note of.
Contact exchange
It is carried out through scanning and recognition of personal QR codes from the bot. To do this, the default image processor is added to the kernel. Images are sent by connectors, which save them to the database along with the message.
QR code recognition is also used to give the user additional information or files from seminars. It looks like this:
Notification mailing
Through the control panel in the web module, we can send notifications to participants of various events.
Conducting surveys
Similarly, surveys are conducted during lectures. But for them, we still manually generate a JSON file with logic, which we upload to the web.
Questions can be both with answers and open. And the structure of the survey may vary depending on the answers.
Auto Replies
The bot can independently select answers to frequently asked questions.
To do this, we have a special base, replenished manually. If nothing suitable was found there or the user was not satisfied with the selected answer, his appeal through the support bot is redirected to the operators.
In general, while this is our entire bothistory. At the moment, we are working on expanding the functions of networking and expect that in the near future our bot will get a little more “fat”, while its structure will remain the same.
