Why do we need chat bots, or the story of Bitrix24
We are often asked what the Microsoft Bot Framework can be used for, except to create bots and chat with them, and whether there are real cases of using chat bots in projects in nature. So, there are. We asked one of our partners, Bitrix24, to share our experience and technical details on how to integrate bots into the project. I give the floor to Sergey Pokoev, a system developer who tells about its architecture and the use of the Bot Framework to connect to Skype.
The company's communication with customers has long been transformed: to replace emails and phone calls, social networks came first, and then instant messengers. Agree, it is now much more convenient, and, most importantly, to quickly ask a support question on Facebook, VKontakte, the What's App or Telegram.
The abundance of channels not only gives ample opportunities, but also creates some problems:
')
Therefore, many companies are thinking about data aggregation in one place, which is easily controlled and controlled. For them in the service "Bitriks24" * just there is a tool "Open lines" , which we will discuss below.
By the way, we’ll immediately answer the question that worries many people: “Why do we need chat bots?” In our case, their use depends on the tasks that need to be solved: starting from simple - chat bots that can send a request to one of the company's departments, complex - to automate customer support.
* Reference: Bitrix24 service is a set of online tools for organizing a company's work. It includes task and project management, omni-channel CRM, the company's internal messenger, a working social network, work time management, document management and other functionality.
The client writes to the company's official account in social networks or in instant messengers. This message is sent to the processing queue common to all channels. From it, messages are distributed among employees who respond to them inside the Bitrix24 messenger. As you could understand, this is an automated process and for the respondent there is no difference in which of the channels the client wrote.
The Microsoft Bot Framework is an environment that allows you to create an intelligent chat bot in the cloud, with which you can then communicate via various communication channels: from Skype and Telegram to Slack and SMS. It can also be used as a proxy. This is convenient, since it is not necessary to implement integration separately for each of these channels.
For integration with the Microsoft Bot Framework, the existing Open Lines operating scheme was used with some modifications.
We have created a special server connectors. It is a link between external communication channels - social networks, instant messengers, online chats, forms on the website, and so on - and client Bitrix24. The main advantages of the server:
Data exchange between the client Bitrix24 and the connector server is performed using its own protocol. At the same time, the server acts as a router, with preprocessing of incoming and outgoing data.
It has slightly different server environment requirements than Bitrix24: PHP starting from 5.4, MySql 5.5.3, InnoDB.
To minimize the overhead of data exchange between client Bitrix24 and the server of connectors, it was decided:
The message queue on the server is based on MySQL. At the moment there is no need for more complex, but flexible tools like Redis. A database-based queue avoids additional overhead, is easier to maintain and easily withstands current workloads.
The queue guarantees delivery of messages, even if the portal has been unavailable for some time. The incoming message is processed and placed in the database. A separate process continuously selects messages in the database for sending. At the same time, he forms packets of several messages and sends them to the portals.
If delivery confirmation does not arrive at the server, then the next sending to this portal in this “Open Line” will occur only after the end of the blocking period. After each attempt, the duration of the blocking increases. If the last attempt fails, the sending of messages will be blocked for 12 hours. In total, it turns out 24 hours since the first attempt to send messages to the portal. After the last attempt, all messages for this portal of the “Open line” are deleted, and the blocking is removed.
If the server receives a confirmation, the delivered messages are removed from the queue, and the blocking of this “Open Line” is removed. That is, new messages will be immediately sent to the portal.
We applied the “factory method” pattern to organize the code responsible for each communication channel. Defined a standard set of methods that each connector should support. In addition, each channel can have its own unique methods.
For the channel to work, you must perform the initial setup on the portal. It is done by users, and the portal manages the connection using special methods. Settings for different types of connectors differ significantly in their method sets. For the Microsoft Bot Framework, a simple configuration option is used. From the portal, the remote
The portal then calls the remote
Webhook is specified when creating a bot on the Bot Framework website. We give the required address when setting up the user.
The configuration interface on the portal side looks like this.
Beginners can use the step-by-step wizard, which will help you quickly register a new bot.
After successful connection, we get records in three data structures.
Record with information about the site . An important parameter is the portal domain. The server will access it in certain cases.
Record of the open line / connector . It uniquely identifies:
Records of connection parameters of a specific connector of a specific "Open line" . For different types of connectors, the set of parameters can vary greatly.
Bot Framework contains a whole set of channels. Therefore, we have introduced the concept of "real channel" and "virtual channel."
To work the connector you need:
1. In the settings of the bot, specify the desired WebHook.
2. In the channel settings in Bitrix24, specify the correct ones:
Thanks to WebHook, the connector server determines which “open line” this bot is associated with. If the binding could not be found, an error is returned.
If there is no error, then we process the received data:
After all conversions, the message is added to the message queue.
When sending messages from “Bitrix24” to an external messenger, a reverse conversion from one format to another is performed. The message is sent using the POST method
In this case, binary data is not transmitted. All attached files are put into “Bitrix24.Disk” and sent as links. This saves traffic. And if necessary, you can close access to the file at any time.
Chat begins with a message from a social network user or messenger. A single entry point is used. This is a single URL, characterized by the GET parameter, which contains the Open Line Hash. By hash, the system determines where to send the incoming message.
There are situations when the same essence of an external system (group, bot) is attempted to be connected to several portals or to different “Open Lines” within one portal. If such cases are not handled, then abnormal situations and failures may occur. Therefore, we implemented a uniqueness check mechanism.
Attempts to reconnect for different channels are defined differently. The Microsoft Bot Framework checks for the presence of a specific bot ID in the system. If the current connection is not the only (repeated), then it continues to work in normal mode, and the data of the previous connection is completely removed from the server. At the same time, a request is sent to the portal that marks this “open line” connector as “emergency”, requiring the attention of the administrator.
The client connector module is used for:
The Open Lines module is responsible for routing messages, creating a message queue, referring to operators and other functions.
In the "Open Lines" module, the
In the
Disadvantages : the speed of the "magic" methods is somewhat lower. But they are used to work with external systems, so the delay is not so noticeable.
Advantages : you can work with external methods as with internal ones. That is, the developer locally calls remote methods. All work is standardized. You do not need to keep a list of methods on the client, you do not need to synchronize this list. It is enough to add a method to the server, and you can use it on the client.
Some external server methods have local wrappers. They perform various tasks before sending a request to a remote server. For example, they cache data (to reduce the load on a remote server), do preprocessing, and so on.
All incoming requests are handled by the
Types of incoming requests:
The
Received messages are additionally processed. Shortname Emoji is converted to a special
All attached files are processed. They are downloaded and registered in the internal system. And in the array describing the files, the links to them are replaced with internal IDs.
The presence of the internal user created under the external user of the social network or messenger is checked on the portal. If not, it is created. If there is a user, then the md5 hash of the user data is checked. It is compared with the received data, and if the hashes are different, the user data is updated. Then they are replaced in the incoming array with the user ID inside the Bitrix24 portal.
Such a converted data array is placed in the
Outgoing requests are practically not processed. They are routed to a remote connector server. For the Bot Framework, an additional handler is made on the client.
This connector is different from all the others in that in outgoing messages you need to send information about the sender. It is not transmitted to us when you connect. But we can get it in the incoming data. Therefore, a separate table has been created to store supporting information about each chat and each dialogue.
For incoming messages, this method calls the
Currently, the majority of Bitrix24 users connect the Bot Framework channel to work with their audience via Skype. At the time of publication of the article the number of connected bots is 9 thousand.
Prehistory
The company's communication with customers has long been transformed: to replace emails and phone calls, social networks came first, and then instant messengers. Agree, it is now much more convenient, and, most importantly, to quickly ask a support question on Facebook, VKontakte, the What's App or Telegram.
The abundance of channels not only gives ample opportunities, but also creates some problems:
')
- Sales data is difficult to account for and analyze.
- Personnel errors lead to customer dissatisfaction.
Therefore, many companies are thinking about data aggregation in one place, which is easily controlled and controlled. For them in the service "Bitriks24" * just there is a tool "Open lines" , which we will discuss below.
By the way, we’ll immediately answer the question that worries many people: “Why do we need chat bots?” In our case, their use depends on the tasks that need to be solved: starting from simple - chat bots that can send a request to one of the company's departments, complex - to automate customer support.
* Reference: Bitrix24 service is a set of online tools for organizing a company's work. It includes task and project management, omni-channel CRM, the company's internal messenger, a working social network, work time management, document management and other functionality.
How it works: user view
The client writes to the company's official account in social networks or in instant messengers. This message is sent to the processing queue common to all channels. From it, messages are distributed among employees who respond to them inside the Bitrix24 messenger. As you could understand, this is an automated process and for the respondent there is no difference in which of the channels the client wrote.
How it works: a developer’s view
Integration with Microsoft Bot Framework
The Microsoft Bot Framework is an environment that allows you to create an intelligent chat bot in the cloud, with which you can then communicate via various communication channels: from Skype and Telegram to Slack and SMS. It can also be used as a proxy. This is convenient, since it is not necessary to implement integration separately for each of these channels.
For integration with the Microsoft Bot Framework, the existing Open Lines operating scheme was used with some modifications.
We have created a special server connectors. It is a link between external communication channels - social networks, instant messengers, online chats, forms on the website, and so on - and client Bitrix24. The main advantages of the server:
- provides guaranteed delivery of messages from social networks and instant messengers to Bitrix24;
- works with both cloud Bitrix24 and boxed;
- allows you to quickly connect the official account of the company in the social network or messenger to "Bitrix24".
Data exchange between the client Bitrix24 and the connector server is performed using its own protocol. At the same time, the server acts as a router, with preprocessing of incoming and outgoing data.
It has slightly different server environment requirements than Bitrix24: PHP starting from 5.4, MySql 5.5.3, InnoDB.
To minimize the overhead of data exchange between client Bitrix24 and the server of connectors, it was decided:
- Do not transfer files attached to messages from external channels and from the server. The server sends only links to files from external sources to Bitrix24. And the client’s Bitrix24 downloads them independently;
- when sending files from Bitrix24, transfer only download links to them. The files themselves are stored on "Bitrix24.Disk";
- for frequently used actions (receiving, sending a message, sending delivery statuses, reading a message and the like), after sending the message, do not expect a response and close the connection.
Connector Server Message Queuing
The message queue on the server is based on MySQL. At the moment there is no need for more complex, but flexible tools like Redis. A database-based queue avoids additional overhead, is easier to maintain and easily withstands current workloads.
The queue guarantees delivery of messages, even if the portal has been unavailable for some time. The incoming message is processed and placed in the database. A separate process continuously selects messages in the database for sending. At the same time, he forms packets of several messages and sends them to the portals.
If delivery confirmation does not arrive at the server, then the next sending to this portal in this “Open Line” will occur only after the end of the blocking period. After each attempt, the duration of the blocking increases. If the last attempt fails, the sending of messages will be blocked for 12 hours. In total, it turns out 24 hours since the first attempt to send messages to the portal. After the last attempt, all messages for this portal of the “Open line” are deleted, and the blocking is removed.
If the server receives a confirmation, the delivered messages are removed from the queue, and the blocking of this “Open Line” is removed. That is, new messages will be immediately sent to the portal.
The mechanism of the connector server
We applied the “factory method” pattern to organize the code responsible for each communication channel. Defined a standard set of methods that each connector should support. In addition, each channel can have its own unique methods.
For the channel to work, you must perform the initial setup on the portal. It is done by users, and the portal manages the connection using special methods. Settings for different types of connectors differ significantly in their method sets. For the Microsoft Bot Framework, a simple configuration option is used. From the portal, the remote
saveSettings method is saveSettings , in which the necessary parameters are passed. They are stored in the database and are used in the work of the channel in the future.The portal then calls the remote
testConnect connector testConnect , which checks the connectivity with the specified data, and also checks the availability of the connected portal.Webhook is specified when creating a bot on the Bot Framework website. We give the required address when setting up the user.
The configuration interface on the portal side looks like this.
Beginners can use the step-by-step wizard, which will help you quickly register a new bot.
After successful connection, we get records in three data structures.
Record with information about the site . An important parameter is the portal domain. The server will access it in certain cases.
Record of the open line / connector . It uniquely identifies:
- connector type;
- id of the open line on the client;
- link to the site;
- special hash to determine which “open line” the request refers to when accessing via WebHook;
- Information for a message queue: the number of attempts to send messages to the client and the blocking time for sending
Records of connection parameters of a specific connector of a specific "Open line" . For different types of connectors, the set of parameters can vary greatly.
Work on the server directly with the Microsoft Bot Framework
Bot Framework contains a whole set of channels. Therefore, we have introduced the concept of "real channel" and "virtual channel."
Botframework is a real channel, since it uses one point of contact. Botframework.skype is a virtual channel that implements work with the Skype bot through the Microsoft Bot Framework.To work the connector you need:
1. In the settings of the bot, specify the desired WebHook.
2. In the channel settings in Bitrix24, specify the correct ones:
- bot handle;
- Application ID;
- application secret.
Thanks to WebHook, the connector server determines which “open line” this bot is associated with. If the binding could not be found, an error is returned.
If there is no error, then we process the received data:
- we form an array of data in the format of exchange between the client and the server;
- Parsim the text and transform all the entities into the format understandable to the Bitrix24 messenger. For different channels, these transformations are different;
- convert all incoming emoticons in the universal format Emoji. We tried to cover a maximum of smiles supported by all channels.
After all conversions, the message is added to the message queue.
When sending messages from “Bitrix24” to an external messenger, a reverse conversion from one format to another is performed. The message is sent using the POST method
/v3/conversations/{conversationId}/activities . All the data you need to send come along with the message.In this case, binary data is not transmitted. All attached files are put into “Bitrix24.Disk” and sent as links. This saves traffic. And if necessary, you can close access to the file at any time.
The principle of "Open lines"
Chat begins with a message from a social network user or messenger. A single entry point is used. This is a single URL, characterized by the GET parameter, which contains the Open Line Hash. By hash, the system determines where to send the incoming message.
Connection uniqueness
There are situations when the same essence of an external system (group, bot) is attempted to be connected to several portals or to different “Open Lines” within one portal. If such cases are not handled, then abnormal situations and failures may occur. Therefore, we implemented a uniqueness check mechanism.
Attempts to reconnect for different channels are defined differently. The Microsoft Bot Framework checks for the presence of a specific bot ID in the system. If the current connection is not the only (repeated), then it continues to work in normal mode, and the data of the previous connection is completely removed from the server. At the same time, a request is sent to the portal that marks this “open line” connector as “emergency”, requiring the attention of the administrator.
The mechanism of the client part of "Bitrix24"
The client connector module is used for:
- communication channel connection settings;
- receiving messages, processing and converting to the Bitrix24 messenger format. With the subsequent generation of the event;
- processing users: registering or updating user data Bitrix24, which is associated with an external user;
- download files coming with messages.
The Open Lines module is responsible for routing messages, creating a message queue, referring to operators and other functions.
Implementation of data exchange on the client
In the "Open Lines" module, the
Output class is responsible for sending messages to the server and additional processing. The query method directly generates outgoing packets to a remote server and signs messages.In the
Output class, “magic” methods are used, allowing you to call the methods of the remote server as if they were local. This has advantages and disadvantages.Disadvantages : the speed of the "magic" methods is somewhat lower. But they are used to work with external systems, so the delay is not so noticeable.
Advantages : you can work with external methods as with internal ones. That is, the developer locally calls remote methods. All work is standardized. You do not need to keep a list of methods on the client, you do not need to synchronize this list. It is enough to add a method to the server, and you can use it on the client.
Some external server methods have local wrappers. They perform various tasks before sending a request to a remote server. For example, they cache data (to reduce the load on a remote server), do preprocessing, and so on.
All incoming requests are handled by the
Input class. It parses the incoming packet, verifies the signature (that the request actually came from the server), and redirects the data to the Router class, which routes incoming requests.Types of incoming requests:
- Connection testing This method is called by the remote server when it checks the availability of the client.
- Incoming messages (all types) . More details below.
- Delivery status Together with the delivery status comes the external message ID, which then allows you to manage the external data. For example, we cannot delete a message on a remote server without knowing its external ID.
- Read status .
- Deactivating the connector . Called when this connector is connected to another portal or Open Line.
Receiving messages by the Bitrix24 client
The
input class accepts an incoming message (message array) from the portal and begins processing. A message delivery notification is sent to the server. It removes them from the queue and removes the blocking of further sending messages.Received messages are additionally processed. Shortname Emoji is converted to a special
icon tag, supported by the Bitrix24 messenger. This is how all available Emoji are supported.All attached files are processed. They are downloaded and registered in the internal system. And in the array describing the files, the links to them are replaced with internal IDs.
The presence of the internal user created under the external user of the social network or messenger is checked on the portal. If not, it is created. If there is a user, then the md5 hash of the user data is checked. It is compared with the received data, and if the hashes are different, the user data is updated. Then they are replaced in the incoming array with the user ID inside the Bitrix24 portal.
Such a converted data array is placed in the
OnReceivedMessage event that is OnReceivedMessage . His "catches" the module "Open lines".Outgoing requests "Bitrix24"
Outgoing requests are practically not processed. They are routed to a remote connector server. For the Bot Framework, an additional handler is made on the client.
This connector is different from all the others in that in outgoing messages you need to send information about the sender. It is not transmitted to us when you connect. But we can get it in the incoming data. Therefore, a separate table has been created to store supporting information about each chat and each dialogue.
For incoming messages, this method calls the
furtherMessageProcessing method, which selects and saves the necessary information. And when sending a message to the Botframework channel, the sendMessageProcessing method mixes the necessary data.Instead of conclusions
Currently, the majority of Bitrix24 users connect the Bot Framework channel to work with their audience via Skype. At the time of publication of the article the number of connected bots is 9 thousand.
Source: https://habr.com/ru/post/327258/
All Articles