Skype-bot with a human face (on the Microsoft Bot Framework V3 and Slack API)

Skype is an excellent channel for quick communication with customers. He has all and provides fast live communication without unnecessary gestures and costs (for example, on the telephone). However, when the number of customers is in the thousands, the benefits of Skype begin to turn into disadvantages. In this article we will talk about our Skype bot, in fact, performing the role of a telephonist from the early 20th century: it connects the client with a free manager and maintains this connection until the issue is resolved.

Skyeng School has always had the task of creating a convenient communication channel between messengers and operators of customer support services. The instant messenger that now receives the largest number of applications from us is Skype. When the number of contacts in Skype amounts to thousands, communication directly through the Skype client becomes problematic. First, the performance of this client during such work drops to almost zero, the contact list is loaded prohibitively long. Secondly, often several operators need to maintain parallel communication with users; Using one Skype account on several devices is possible, but incoming messages from all conversations are visible to all operators, which hinders the work. In addition, all communications in Skype remain in Skype itself, in order to retrieve them into internal CRM or HelpDesk systems, you have to copy-peist.

These difficulties led us to the decision to create a chat bot that will serve as an entry point for messages to the support service. The topic of chat bots has been very popular lately, and Microsoft has provided access to the Skype REST API, which includes an SDK with examples for C # and Node.js.
')
For full-fledged multi-channel communication, receiving messages is not enough; they must also be delivered somewhere where the operator can read them. Since our school actively uses Slack in its internal communications, and this messenger has good support for the concept of channels, it was decided to forward incoming messages there.

As a result, we have created a model with entry and exit points, within which we have complete control over the data flows.

Architecture

The system does not imply any complicated calculations on the server; Its main tasks are receiving, storing and routing data. Therefore, Node.js was chosen as the main platform, which is well suited for such tasks. They took the latest available LTS version, at the time of the start of the project - 6.3.0. According to node.green, the six covers 95% of ES 2015, which is very nice, and the nodesource blog promises its operation until April 2018, after which the maintenance phase will begin. It fits.



There are no special requirements for the database, so we took the classic reliable relational in the form of PostgreSQL .

To ensure sufficiently high fault tolerance, the ability to scale and at the same time low connectivity of components, it was decided to include in the message queue architecture in the form of RabbitMQ for data exchange between system modules.

The result is the following scheme of work:



The system consists of three main services (Skype service, Logic service, Slack service) and the additional micro service Slack messaging micro-service. The main task of Slack service is to ensure endpoint's work for the Skype bot and send messages to Skype. Logic service is responsible for routing messages, storing messages, processing commands and providing an API for integration with the school’s internal services. Slack service has a subscription to Slack RTM and is responsible for the endpoint for accepting commands from support operators on Slack.

An additional Slack messaging micro-service was needed in order to confidently send messages to Slack, without fear of exceeding the limits of the Slack API , so messages are sent by long-polling reading them on a timer from RabbitMQ and sending to Slack.

Can you trust the preview? Migration to Microsoft Bot Framework

The use of preview versions of the tools always carries a certain risk, since by the time of release serious changes may occur to them or, even worse, this release will not take place at all . This is the fate that befell the SDK for the development of Skype bots: it appeared in the form of a preview and grew old in the same form (received the status of deprecated). After that, the creation of new bots exclusively for Skype became impossible, and then a redirect to the Microsoft Bot Framework and a warning about the need to migrate in the near future appeared.





The Microsoft Bot Framework is an attempt by Microsoft to cover multiple communication channels in a single tool. Currently supported: Facebook Messenger, Kik, Slack, Telegram, Skype and even channels such as Email, Twilio (SMS) and Direct Line. All this is interesting, but at this stage we were only interested in Skype (although it was a good start, of course, you can add support for other instant messengers with lower labor costs).



We did not wait and migrated immediately. Registering a new bot in the Microsoft Bot Framework is simple, just have a Microsoft account.

The algorithm is as follows:

• follow the link ;
• fill in all fields with an asterisk;
• click Create Microsoft App ID and Password;
• a new page will open where you need to enter the name of the application, for example, TestBotApp;
• next button Generate a password to continue;
• The generated password must be saved somewhere, because you can’t re-see it, but you will need it to work with the Framework and the App ID;
• further button Finish and go back to Bot Framework;
• On the registration page, you need to accept the agreement and click Register, after which we have a ready registered bot for the Microsoft Bot Framework

On the registration page there is a Messaging endpoint field, it is not necessary for registration, but it is the entry point for the bot, without which it will not function. The main requirement for endpoint is that it should be a working HTTPS link.

In terms of migrating the code , there was no need to make big changes, since all that our bot should be able to do is receive and send messages. Nevertheless, the code for the same functionality has become bigger:

bot.send( '8:skype.username', 'message from bot to user', true, // escape (error) => console.log(error) ); 

turned into

 bot.send( new builder.Message() .address({ channelId: "skype", user: { id: "29:some-long-hash-here", name: "User Display Name" }, bot: { id: "28:bot-uuid", name: "Bot Name" }, serviceUrl: "https://skype.botframework.com", useAuth: true }) .text('Message from bot to user'), (err) => console.log(err) ); 

And small changes in message reception:

 bot.on('personalMessage', (bot, data) => { console.log('Got message from user'); }); 

Since the Bot Framework has such a thing as dialogs, but we just needed to receive messages, we subscribed to the most general dialogue, which is represented by a slash; it will accept all incoming messages:

 bot.dialog("/", [ (session) => { console.log("Got message from bot", session.message); } ]); 

In the above bot code snippets in the case of the Skype Bot SDK, there is an instance of the BotService class, and on the Bot Framework this is already UniversalBot .

It is also worth noting that if in the Skype Bot SDK we hoped to be able to understand by user id, who we are dealing with, then in the Microsoft Bot Framework all users are represented as long hashes, which makes the interlocutors anonymous. The task of identification can be solved only in a lively dialogue with the user.

Another interesting point is editing the messages sent by the bot. In the Skype Bot SDK, as some github users say, there was such an opportunity, but in the Microsoft Bot Framework it is not for Skype (although for other platforms, in particular Telegram and Slack, it is possible).

Nevertheless, the Microsoft Bot Framework is a good step towards unifying the bot development platform for various communication channels. It is hoped that Microsoft will continue the development of this product and add the missing features for Skype bots now.

We meet messages in Slack

To organize multi-channel message acceptance, we used the Slack tool such as private channels; in Slack API terminology, this is groups .

Initially, we expected that the creation of a single Custom Bot would be enough for us, which would cover all the functionality of sending messages to Slack: create a private channel there, add an operator to it and continue to provide proxy communication. It turned out, however, that bots in Slack do not have the right to create private channels.

Therefore, in addition to the Slack- connected RTM Api Custom Bot, we also created a Slack application, which, on behalf of the average Slack user, creates private channels and invites operators to them.

The Slack API is fairly stable, well documented, and even contains an online tester that allows you to check the method call, so fortunately there were no other surprises. To work with him, we took this very simple npm package : it is convenient, since its methods are mostly the same as the Slack API methods.

Not so simple!

In order for your bot to work, it must be approved by Microsoft. It would seem a simple formality, but it took us a lot of time and effort. We will tell you about the rake that you stepped on yourself, but this does not mean that you will not step on any more; be prepared for this.

So, two weeks after the first submission, we received this:



with an explanation: Bot content is in Russian language. At this time, Skype Bots only support English Users. Please “your bot is in Russian, but you need to be able to communicate with users in English”). As it turned out, to solve this problem, it is enough to have the Terms of Service and Privacy Policy in English; OK, wrote, posted , sent a new application.

This time the fail came faster:


Our bot is only intended to connect the client with the operator. According to Microsoft, this is not enough. It was necessary to fasten the minimum functionality - a couple of commands to which the bot can react independently (help and lessons-count).

While we were fulfilling these requirements, a new one appeared: a bot should be able to issue Terms of Service and Privacy Policy on command (just having them on the site is not enough). Okay, did that too. It turned out that this is not enough, the conditions must be present in each message. Good. Meanwhile, in the London office of Microsoft, massive reshuffles began, which is why approval was postponed again and again ...

But in the end we got a long-awaited apruv:



All these machinations have taken away a huge amount of time from us, be prepared for unforeseen and sometimes unexplained delays.

Conclusion

As a result, we received a Skype bot that provides a quick, high-quality response to incoming messages and talking to the client “as alive” (which is not surprising, considering that the operator controls it). Gone are the answers to the wrong channel and missed incoming contacts; “Your question is very important for us” - not empty words, now not a single message will be lost, and the conversation will not die out through our fault. At the same time, the problems of regular Skype were solved, and communications acquired a structured form, which we integrated into our internal user support services. And all the “magic” is in the uncomplicated architecture of routing messages between different platforms.

PS We remind you that our doors are open for different talented professionals !