Administering BizTalk server using a Chat Bot

|  Posted: April 25, 2019  |  Categories: BizTalk Server Community Events Guest Bloggers Logic Apps
Tags:

Recently on Integration Monday, I presented a chat bot which can be used to administer BizTalk, hosted on premises, using a chat bot, Logic Apps and the On Premises Data Gateway. The session can be found at Administering BizTalk Server with a Chatbot. This blog post is aimed at discussing the session.

Context

For a product company serving its customer, there are few areas where the company executives need to work with their customers. These activities can be broadly classified into two categories:

  1. Customer Service
  2. Brand Loyalty and Awareness

Let us take a brief look at each of these categories.

  1. Customer Service: Executives of the company might need to converse with customers to:
    1. Account management: Help customer manage their services, subscriptions, payments etc.
    2. FAQ: Answer the common questions about the product
    3. Issue Resolution: Solve the issues customers face with the product
  2. Brand Awareness and Loyalty: Executives of the company can converse with customers to:
    1. Seek Feedback: Understand how customers like the product. What the general sentiment for the product is?
    2. New Features/Products: Inform customers about the new features or the products that the company is launching

For the conversation in the customer service category, the general mode of conversation is use of emails, phone calls or support websites. While in the Brand Awareness category it is generally emails and calls.

Now consider what if the conversations are delivered to the customers at their fingertips? This is possible by creating virtual assistants tailored for the functions specific to the product. These virtual assistants, when imbibed with the power of Natural Language Processing and Cognitive services, help customers converse with the company and get their intended work done.

This not only makes conversation available to customers at their fingertips, but also saves a lot of money for the company by automating most of the before mentioned tasks.
This concept of providing “Conversation” as a service to the customers through virtual assistants is generally termed as “Conversation as a Service”.

Chat bots are the starting point of Conversation as a Service as they pave a way to build full-fledged virtual assistants.

What Are Chat Bots?

Now that we have seen what Conversation as a Service is and how bots fit into this, let us analyse how the chat bots are different from a regular web application. Consider a scenario where you want to buy a laptop. In such scenario in normal web application, you would generally follow below steps:

  1. Navigate to the Home page of the website
  2. Enter the search details for the laptop. This search then leads to a new web page which displays the result
  3. After selecting a particular laptop, to place the order the website redirects to a new page where details like name, address and payment details are collected and the order is finally placed

Now let us try to convert these steps to how a chat bot would process the laptop request. Following image shows the comparison between the web application and the chat bot.

A chat bot does not have a traditional UI where the user navigates from one page to another, bots have dialogs that correspond to a particular web page in a web application. So, to order a laptop the chat bot would use following dialogs:

  1. A root dialog which greets the user and asks them what they want to do
  2. Once the user confirms they want to buy a laptop, the bot initiates the Product Search Dialog and collects the search parameters from the user. Once that is done, the bot returns the result to the user in the form of carousel cards
  3. Once the user confirms the laptop, the bot initiates an Order dialog which would then collect name, address and payment details and then place an order for the laptop

In a nutshell, chat bots are just like normal web applications but instead of having a breadcrumb-based web page approach, bots use dialogs to collect and display information. Each dialog only supports a single responsibility akin to the single responsibility principle of software design.

Tools and Frameworks Used

Now that we know what Conversation as Service is and how and what chat bots are, let us take a look at the tools and frameworks we use to build the chat bot.

  1. Visual Studio 2017/ Visual Studio Code – Any one of these IDE’s can be used to build the bot code. I prefer to use Visual Studio 2017 as it provides a bot skeleton project which takes care of basic plumbing of the bot code, we just need to add our logic in it. Visual Studio Code does not provide that flexibility, we have to create an empty web app and add the code ourselves.
  2. MS Bot Framework SDK 4.x – This is the official Microsoft released SDK to develop bots. This SDK works with ASP.NET Core 2.x and makes the framework a cross platform development framework. We can develop the code on Windows, Linux or Mac
  3. Asp.Net Core 2.x – The cross platform open source .Net framework by Microsoft
  4. Adaptive Cards – This framework is used to author and render the cards using a standard Json format. Brings uniformity in the way information is exchanged between the channel and the bot
  5. Bot Framework Emulator – Used to emulate the actual conversation between the user and the bot. Helps to debug the bots hosted locally and also on Azure The following image shows the basic building blocks in a typical bot. All of these blocks are from Microsoft Azure perspective.

Typical Bot Architecture

Let us take a look at each of the blocks in brief.

  1. Bot Service – This a central piece which connects the different communication channels to the actual bot code. It allows us to manage the connection to the communication channels. It allows to implement authentication to the back-end services used by the bot code. E.g. If we want the user to be authenticated to use the MS Graph API, we add the OAuth connection to the Graph API in the bot service.
  2. Identity Management – The Bot Framework provides out of the box connection to various OAuth providers like Uber, Gmail, LinkedIn, Fitbit, MS Graph API etc. It also allows to map our custom OAuth system to the bot code.
  3. Channels – Various channels are available for us to integrate the bot with, they are FaceBook, Email, Slack, Kik, Skype, Skype For Business etc. Each registration of the channels needs to be done with the Bot Service.
  4. Bot Code – The bot code can be hosted as a Web App or a function App when we use the SDK V3 and as Web App for now for SDK V4.
  5. State and Conversation Management – The bot framework allows us to manage the state and the conversation history using several out of the box options. We can use CosmosDb, Blob Storage or Azure SQL Database. The Azure Search Service can be used with the conversation History store to fetch history from the store.
  6. NLP and Sentiment Analysis – These features are used to Introduce more complex and rich features into bot which enables it to converse with the user in a more natural form and detect the sentiment of the user as the conversation continues on. This provides a lot of information to companies to understand how their chat bot is faring with the task of solving problems of their customers.
  7. Integrators – The bot can communicate with the other SaaS products and Machine Learning Models, QnA maker services and Cognitive Services using Integration offerings like Logic Apps and Azure Functions.
  8. Repositories – The Web/ Function App in which the bot code is deployed can be hooked to different repositories and configured to use Continuous Deployment.

The BizMan

Now that we have seen what a typical bot looks like, let us move on to the BizTalk Admin Bot. I have named this Bot “The BizMan” as it administers the BizTalk server. The name and the superhero persona were conceived by Sandro Pereira . The post is available on his blog at BizMan, The BizTalk Server SuperHero Sticker

The architecture for BizMan is almost similar to the bot architecture discussed above. The following image shows the architecture for BizMan.

BizMan Requires that the user is a valid user in the Azure Active Directory and can be authenticated successfully. BizMan uses Blob Storage to store the logs and suspended instances reports. It uses Logic Apps to communicate with the BizTalk Management service (which comes with the BizTalk 2016 Feature Packs). This communication takes place using the On Premises Data Gateway.

The Management service that comes with Feature Pack 1 for BizTalk 2016, allows us to administer BizTalk Server using the Web API. This service also comes with a pre-authored Swagger definition which gives us the details about the various operations available in the service. This enables us to create a custom Logic Apps connector to communicate with this Web API. So, we just upload the Json file containing the Swagger information of the API and set up Windows authentication using an account which is part of “BizTalk Administrators Group”. This allows us to easily consume various operations in the Web API in a Logic App. A sample snapshot of the Logic App is shown below.

As will be clear, it is very easy to create the Logic App and add new operations, if we use a Custom Logic Apps connector.

The typical flow for the bot is shown below.

The BizMan is able to perform following tasks:

  1. Greet the User
  2. Authenticate the user against the AAD
  3. Get Hosts
  4. Get the Applications deployed in the BizTalk environment
  5. Get the List of Orchestrations, Send Ports by application
  6. Stop/ Start Send ports
  7. Enable / Disable Receive Location
  8. Get Suspended Instances
  9. Get Feed Back from the user

The options are presented to user as a big adaptive card as shown below.

Let us take a look at some of the operations available in the bot.

  1. Greet the User:

  2. Authenticate the User:

  3. Enable Receive Location:

Let us explore this operation in detail. In this operation, the User initiates the command by clicking on the Enable Receive Location option available from the operation card as shown below.

This initiates a call with the command “enablerl” to the bot web app. The first step in enabling any receive location is to get the list of all the receive locations that are disabled on the environment. The bot code first checks if there is a list of receive locations in the cache (gets refreshed every 1 min).
If the cache does not have the list, the bot code in turn initiates a call to the Logic App which fetches the list of the receive locations from the on premises BizTalk environment using the BizTalk management service. Following is a request response sample that Logic App receives and returns to the bot respectively.

Once the list of the receive locations is available, the bot filters the list based upon the “Enable” flag received in response. So, for the “Enable Receive Location” operation, only the disabled receive locations are populated and the user is presented with a drop-down list to select a location from. A sample is shown below.Once the user clicks on the Submit button, the bot code initiates another call to the Logic App which in turn calls the On Premises BizTalk management service and enables the receive location. The Logic App Request response is shown below.

Once the receive location is enabled, the user gets a response that the “Operation Completed Successfully.”

In case there are no disabled receive locations in the BizTalk environment, then the bot code will notify the user that there are no disabled receive locations in the BizTalk environment.

Note: Similar logic is applied in following operations available in the bot:

  1. Disable Receive Location
  2. Start Send Port
  3. Stop End Port

4. Get Hosts:

The operation is initiated when the user selects the Get Hosts operation from the list of available operation.

This initiates a command “gethosts” to the bot code. The code checks its cache to check if there is a list of hosts available with it. If it finds the list, the hosts are displayed to the user. In case the list is not available, the bot will initiate a call to the Logic App which calls the On Premises BizTalk management service and gets the list of the hosts. The response displayed to the user as an adaptive card shown below.

  1. Note: Similar approach is taken while implementing following operations:
  2. Get Send Ports by App
  3. Get Orchestrations by App
  4. Get All Applications

5. Get Suspended Instances Report

This operation, as the name suggest, brings the list of the Suspended Instances from the On Premises BizTalk environment. In this case, no caching is implanted as the number of suspended instances can change on a per second basis in a high load environment. In this operation, a small report is displayed to the user which contains the suspended instances grouped together as shown below.

This card gives the user an option to view a detailed report and provides a button to open the report. Once the user clicks on the button, it directs the user to a HTML web page which contains details about the suspended instances. In this case, the detailed report is stored as block blob in the azure storage account. This blob is available only until the point the user is actually logged in the session in the bot. The blob is deleted upon the end of the session.

In similar fashion, additional features can be added to the bot by adding new switch cases to the logic app and accounting for them in the bot code.

Further Scope

The BizMan can be made more functional by expanding on the Logic App and the bot code to assimilate more functions.
Natural Language Processing and Sentiment Analysis can be implemented in the bot to enable it to communicate more freely with the users.
Functions to control and monitor the Logic Apps can also be implemented in the same chat bot.

Reading Sources

In order to get started with building chat bots, the following MSDN documentation are the go-to links.

  1. Azure Bot Service Documentation
  2. Adaptive Cards

Back to Top