Microsoft BOT from the architecture point of view
Since Microsoft released BOT Framework I was excited to use it in a real environment. I started to work on enterprise and said to myself that this should be a nice place to try some PoC. First, I wanted to try to create a test / dev environment for the whole concept. Let’s do this in Azure 😉 So first you must create BOT App. Not so hard as the only thing you should do is start writing hello word, reference libraries from BOT framework, all at this moment should be on your desktop / visual studio. The hello word code should look like the one in official Microsoft pages in the BOT Framework documentation.
Now the next thing to do is to register own workspace in LUIS. What is LUIS? It is a language recognition platform. When you will ask bot for something, this question will go directly to LUIS, there the environment will try to recognize, that do you want to know, or what you asked for and will return some result as a percentile based on your configuration. So, the answer to the question if LUIS must be configured is YES. You must select Intents and Entities. And this is hard to think about because from the general point of view, this should be almost anything, so how to select this right? I tried to look to some documentation, to some other BOT technologies, but still hadn’t idea how to do this. With a colleague of mine, we then decide to create some concept based on the area of possible decision logic for the BOT. The main thing was, that the logic of LUIS will (after first received information in JSON) try to discover some word patterns (=entities) which are associated with areas (=intents) and based on this system will return percentile of what the end user wants. It is obvious, that these results will be correct only in some ratio. The situation is like to learn with children. You should put some direction to learning algorithms so the LUIS will be better and better. From time to time is good to sign in to the admin portal and make some corrections. LUIS save all the conversation, so you can select different patterns (entities) and in the final, you can push LUIS to different intent (area), which will be returned to BOT.
TESTING OF BOT
Even when you are in the beginning, you would like to test the BOT right? For this, Microsoft provides emulator, which is testing environment/console for the BOT. It will connect to localhost as well as to cloud web application and will simulate communication front end to the BOT. A Nice feature about this part is a possibility to debug the whole solution because you can see all the income and outcome JSON messages.
When you are done with basics and want to publish these to the cloud, the simplest way is to create an azure web app using app service directly from the Visual Studio. If you haven’t Azure account, you can create one for free. After this, your BOT has new home – AZURE J When BOT is in the cloud, you can also turn on some log or app analyzer to better monitoring your performance, stability, or all the potential mess, which you don’t see from your visual studio.
Now it’s good to start to think a little bit about other features which are nice to have or necessary in an enterprise environment.
- What about the area of the BOT? Would it be the universal solution? Or some specialized solution?
- What about some company processes, which are changing from time to time? How to implement these?
- Will it be necessary to place BOT on premise? And is it even possible?
- Is it possible to implement some company guidelines into the BOT?
- What about some picture screenshots, some headers in communications etc.?
- What about some connectivity to company communication client?
- What about some misspells, bad word combination?
- Is there any possibility to allow the bot also in the Multilanguage environment? Or is it necessary to talk with bot only in one default language?
- Is there any possibility to learn bot about sentiment analysis? That the BOT would be able to recognize when some persons are angry and directly connect them to a human agent for example?
- Are there some integrations necessary?
Let’s have a look at these questions one by one.
Area of the bot
is always a topic. From my perspective, you should select some quick win topic for the beginning. For example, team BOT would be a nice one. The simply selectable scope of knowledge, processes, topics, guides etc. On the other side, the BOT should be able to answer some general questions like “how are you”, “what is the weather in Prague today”, “Who is JEDI?” etc. Why? Simple reason – when you allow to your colleagues to talk to the BOT, they will simply start with some general questions, not some special one. And if the bot will always say, that He don’t understand such a topic, the colleagues will simply say that the BOT is a stupid solution and will stop to play with them. Also, it is important from the BOT side, that in the beginning of the conversations, the BOT will automatically say something like “Hello, I am Albert, I can help you with topics like Our systems architecture, general IT environment, …”. Something. But something with detailed scope to set the right expectation.
is another Important topic. Maybe existence one. Every BOT in enterprise environment must know some guides and processes and by word processes I mean decision trees with YES/NO answers from the end users, when Bot will simply ask for another and another question in the separate level of the tree. In some cases, the BOT should come into the leaf level, so the end of the tree and will tell to the end user some decision. This should look like:
- End user: I haven’t my overtime in my pay slip
- BOT: have you entered all your overtime into your timesheet?
- End user: Yes
- BOT: has your manager approved your overtime?
- End user: Yes
- BOT: then please contact “Frantisek Nohous” at firstname.lastname@example.org, or should I do this on behalf you?
- End user: Yes
- BOT: OK, email with log of this communication was sent to Frantisek, expect answer from him
The important thing is that these processes will change from time to time, so they must be editable and strictly defined in “somewhere”. This somewhere should be another web application as a frontend for the entering of the information and as a SQL Database, where all the information will be stored. Also, it is good to think about some future logic. Would it be necessary to jump from the one part of the tree to another? Would it be necessary to jump from simple chit chat communication into the tree? And what about the guides? Would it be necessary to jump from the middle of the tree to the guide or vice versa? These are important architecture facts, that must be solved ideally in the beginning. Not because of the change of the concept, but mainly because of the potential migration of the data.
So, our solution has another 2 components in Azure
- Azure DB (database as a service). This DB is connected in the BOT code to read/store all the information from/to database
- Another WebApp as a front end, connected to the database with possibility of editing of all the information in it.
possibilities are never-ending questions and in some places, an important metric in an enterprise environment for all the information systems and software as well. In the case of the BOT, it is quietly simple.
- The BOT is web application, so it can be hosted in the Azure as well as in some local IIS
- The Admin application for storing some company procedures should be also stored in Azure or in local IIS
- Help SQL Database – also should be in on-premise SQL Server
- SO, WHERE IS THE PROBLEM, IS THERE ANY?
- If we are talking about cloud framework, the references remain to cloud framework
- If we are using LUIS as language recognition system, first question or more questions are going to the cloud environment for recognition and after that data are going back to onprem – ONE REST CALL, so no need to open some firewall ports etc.
- If we are using other APIs from the Microsoft Cognitive Services, then another call to web
- PROBLEM should be 1. Publishing of the BOT, because of the need of some out-of-box channels for clients like Skype, Slack, Facebook or others. In other words – you must develop your own communication channel if you want to connect BOT to any communication client. 2.The bot won’t be searchable as it won’t be registered, but if you are preparing BOT for the enterprise, you even don’t want to.
A common feature of BOTs is providing the guidelines to end users. The example should be “first make this, then click on that, after that fill this form, click send and that’s it”. In an ideal situation with pictures. For such a scenario like this you can use something so-called HEROCARDS for front-end display of the information – here you can define what will be displayed as a picture, what as a header, what as a text. Here is just one important thing, which is the difference in display in separate clients. Look over the internet, how pictures and other elements are displayed on skype, webchat, slack etc.
The second thing is a way, how to save information like guidelines. It is like decision trees. It will be saved in SQL in the same way, pictures should be inserted in the SQL as an attachment. After that, it will be displayed as an HEROCARD in the chat and there should be an array to provide more information to each other.
Just last note to this, it is always good to put in a code “…bot is typing” to rise a little bit some personal feeling. J
Connectivity to company communication client
Bigger problem is how to manage communication with company software if there is any. I mean communication platform like Microsoft Lync or Skype for Business. Now, there are many connectors available if someone is struggling with BOT published to the Azure. If you have your BOT published, you can just turn on, or turn off potential prebuild communication connectors to Skype, Slack and others, but no enterprise level communicator. It is understandable for one reason. Everything is in the cloud and many enterprises still not even most of them are already playing with some hybrid solutions or with using only limited scope of services on the market. Microsoft has on the roadmap information, that they will release Skype for Business connector in Q2/2017 I think, ok, but firstly they will release Skype for Business Online version, not the onprem. So, what to do. I found one possibilities on some forums. Guys deployed virtual machine, which they are using as a, let’s say, application proxy. They installed Lync SDK (latest), Skype for Business client (2015), Visual Studio and place a piece of code to the Visual Studio. Whole solutions work on the principle, that you have Skype for Business Account signed in the client and using code to call and forward communications using SDK to Lync and communicate with the BOT as well. So, as I said. Proxy for forwarding the communication. Well this is way, how to make things working, but it is not something for production environment. Anyway, you can find this solution HERE.
The main problem is that there is no UCWA model in Skype for Business Online and no connector to OnPrem or for OnPrem (using for example UCWA, or UCMA). So the only chance is to move the BOT to onprem and make your own connector based on known technologies.
misspells, the bad word combination
To get over the misspells, it is always good to think about some potential correction. In this context, cognitive services is the right choice. It looks great, many new functions and services from week to week and from my point of view easy to implement.
The BOT Framework is providing a lot of tool to make thing happen. If you have some developers in your company, you can go on and develop some great solution. I don’t want to say, that BOT should be in company instead of people. There is great opportunity to just automate things, that employees will have time for non-repetitive tasks with more value for the company. Microsoft provide great solutions, because of transparency. You can use what you want to use, you can customize almost everything and the whole picture start to making sense when you are watching on releasing of the new and new features. You can combine BOTs with audio/video calls via Skype, you can make just text bots, you can integrate bots with whatever systems you want to – SharePoint because of some automated items creating (FORMS) with workflow on behind, SAP because of reading and writing of some personal information about vacancy, home office time tracking or something else, you can combine bots with some OCR technology to help with documents reading or you can combine bots with other bots