max
max

Reputation: 101

How can I host the .Net Bot application On- premises

We have a client requirement in that Bot application should be hosted in On- premises and all the web chat communication directly go the web server. I am planning to develop a Bot .Net application and configure with web chat Channel. I would like to know if it is possible to configure the Bot application On- premises

  1. How can I setup the web chat On- premises?
  2. How can I skip the Bot Registration and avoid message routing?
  3. Do I have to build a service to handle all the request and response in the web server?
  4. If I am using webchat how the client data is secure and how the bot service is routing the request to Webapp?

If I am using webchat how the client data is secure and how the bot service is routing the request to Webapp.

Upvotes: 3

Views: 2222

Answers (1)

Ankit Sinha
Ankit Sinha

Reputation: 421

Ok. So lets break down the problem.
What you want to do is isolate your bot from any and all communication that it has with Microsoft Bot Connector/Framework.

First understand what are components are involved within Microsoft Bot Framework Ecosystem.

Understanding Bot Framework Ecosystem

Typically a vanilla bot would interact with 3 Microsoft services -

  • Microsoft Bot Connector: This guy here is the heart of Bot Framework. It has critical job(apart from other unimportant things(security!)) of Message Routing, Session tracking and channel adaptation.
  • Microsoft Bot State Service: This service is used to store Conversation (and custom) state.
  • Microsoft Account (MSA) server: The Bot Connector service uses OAuth 2.0 client credentials for bot authentication. MSA server issues these JWT access token.

Now to create an on-premise bot you would need to replace/mock all the above components. Luckily Bot Builder SDK is open source and well designed. The implementations of interacting with above services is interface driven and easy to change.

Understanding and Modifying Bot Builder SDK to create an On-Premise Bot

Since our aim is to not use any Microsoft Service, we would not be needing MSA server to generate token. So no bot registration required.

The most easiest of the services to replace is Bot State Service. All you need to do is implement IBotDataStore or IBotState interface. So instead of storing state in Bot State Service, for instance you could store it into your own Redis DB. I wrote a blog post on how to do this.

What left is now to replace Bot Connector. This is tricky and not straight forward. Plus it is not open source so you are on your own here. As mentioned above, first important piece is Channel Adaptation. Since you mentioned you only need Web Chat channel, there is not much to adapt(duh?!). The second important thing it does is Session tracking, which relies on different IDs that are generated specially Conversation ID and Activity ID. You must understand what they represent. Conversation IDs are generally created and modified by Channel.

Here you must make a choice on how to create the conversation ID. Web chat by default has transient conversation IDs. You may choose to make it more perpetual (one way is to require user to sign in and use userid).

Message Routing works differently in Web Chat Channel since there is no one specific endpoint that Bot Connector has to call(like Facebook Graph API). So Web Chat channel make use of Direct Line APIs to send message and polls(or use socket) a specific endpoint to receive message. Web Chat channel is open source, go ahead and checkout how they do it.

So to fully replace the Bot Connector API you need to create your own connector service which

  • Accepts requests from Web Chat channel.
  • Adapt it and forwards the request to bot
  • Accept response from bot (we will get to how to do this)
  • Maintain the response in some persistent store. Needed because the user may have closed the web page, so you may need to deliver it when he comes back.
  • Return the response to web chat channel on the next poll(or use socket).

Granted this is not trivial, but you can take some design decisions that can make life a little easier. Such as doing away with adapter and keep a single schema for communication from web chat control to the bot and back (but then you will need to change Web Chat Channel code). For starters you may even look at BotFramework Emulator code which simulates the Direct Line API.

Now how to get your bot to send replies to your own connector service? To do this you need to implement IBotToUser interface. This is fairly easy to do. Have a look at my repo where I return the response to Skype For Business client instead of Bot Connector.


This is it I believe. If you can get the above done, you can have a completely isolated bot with no connection made to cloud. For security you may have your own OAuth provider(I recommend IdentityServer) or make user signin before using bot. I cannot answer security detail unless I get more overview of your application ecosystem and usecase.

The conversation data(and state) can be made to be stored in your on-premise database fairly easy. In my opinion, if you can go ahead using Bot Connector and only replace Bot state service it would be best(you can also keep on receiving new features from Bot Framework without having to change any code).


All the above information is from my own experience on working with Bot Framework. If anyone has a better suggestion please feel free to share them and I will make the edits.

Upvotes: 10

Related Questions