2 June 2018
5 minutes read
Challenge: Amid the daily routine, programmers can forget to report their time. We were in search of an easy way to get a daily report so we could notify programmers who forgot to log their time according to the best outsourcing practices.
Solution: We designed a bot on the Microsoft Bot Framework. Every day at 11:00 am and 9:00 pm, the bot verifies that time reports are complete and notifies employees via direct messages on their corporate Slack accounts in case they aren’t.
The UKAD slack bot is built on the Microsoft Bot Framework. This framework is suitable for various platforms and doesn’t require a separate implementation for each. The Microsoft Bot Framework connects all approaches, allowing developers to implement a single bot on Facebook, Skype, Slack, and other messenger platforms. In addition to channels that are supported by the Microsoft Bot Framework, we can implement our own by creating support for any channel within the Microsoft Bot Framework or by connecting the bot with the site.
The UKAD Slack bot implements the Slack API. It helps UKAD employees to track their work hours and reminds them to enter data into the time tracker if they haven’t done so by the evening. Recently, we also added vacation schedule alerts so team leads can plan projects around the schedules of employees.
We created the UKAD bot to simplify the lives of our employees, allowing them to get the information they need with a couple of clicks. In future, we want to add more features related to project management, for example, the ability to inform about project deployment and uptime. Usually, project status notifications are automatically sent by email, but real-time bot notifications in Slack are much more reliable and convenient.
The bot has two modes.
The bot determines the intent based on what a user types.
For example, a weather-related question should be recognized as a weather intent and “today” should be recognized as the current calendar day.
The bot understands what a user wants, runs the appropriate dialogue, and validates data. For example, if we want to clarify a user request such as for which city the user wants a weather forecast or give the user the opportunity to answer a list of questions (the dialogue can be a form-fill or quiz).
Our alert system works as follows: our service sends the bot API a message and recipient and the bot sends this message to the recipient. Depending on the request settings, the message can be a single message or the start of a dialogue.
The Microsoft Bot Framework has two implementations: C# and Node.js. We chose Node.js because of its flexibility. Dialogues in the bot are list of functions. If you want to change the topology dialogues and bot architecture in C#, you have to use reflection, but in Node.js it’s much easier. The one bot, many scenarios architecture is very profitable as we can design a universal bot that gets its structure from the AP on start.
The bot has to be connected to a channel (Facebook, Slack, Skype, a web application, etc.). For this purpose, the Microsoft Bot Framework has an IConnector interface. We could use Microsoft’s implementation and connect the Azure Connector that aggregates messages from all connected channels and sends them to the bot’s API. But we chose the way of the samurai and created our own Slack Connector. This gave us more functionality than the Microsoft Slack API. Also, the Azure Connector costs money based on the number of messages, and our bot is free.
After connecting channels, you need to place the bot. We must receive messages from somewhere and send them somewhere.
The classic scheme involves an API on the internet that receives messages and sends responses to another address. Azure has a special container for the Bot Framework where we can host the application and get an endpoint, but we can do the same on our server. Our implementation consists of a Slack RTM client, which is based on a socket on which we receive messages and a Slack Web API that we use to send messages.
After this, we need to decide whether to save dialogue history and, if so, for how long. Dialogues can be stored in memory or in a database. There are implementations for Cosmos DB and RAM. However, the best way to store dialogues is to write your own implementation for your favourite database (there are only three methods). We used NoSQL.
All that remains is to fill the application with logic, for which the Bot Framework provides a huge number of tools. We created an API for sending messages from our domestic services to employees and intent dialogues (the bot uses Natural Language Processing to guess users intent from a question and answers if it can, for instance by showing an employee’s vacation plans).
A bot is a quite flexible system that can either be monolithic (including all business logic) or be an easy structure from the API generated with the help of the CMS. At the same time, this is a quite cheap technology that doesn't require a large team of developers (if we have a monolithic architecture or a ready-made bot CMS). A single I/O stream makes the system not resource-demanding. Our bot helps to make a product/service friendlier, performs promotional tasks, takes the tasks of support service, and makes people’s lives easier.
Main technology stack: Node.js, Microsoft Bot Framework, Typescript, NeDB, Slack SDK
