6

Chatbot with RPA

One of the unique capabilities of IBM Robotic Process Automation (IBM RPA) is the ability to build chatbots and interactive voice agents without extensive knowledge of Natural Language Processing (NLP) or dependency on other language services. NLP is a field of computer science concerned with identifying entities, such as names and addresses from written prose, and what would appear in a chat interaction. Using NLP features can simplify automating interactions with humans, and IBM RPA provides commands that take advantage of NLP.

This chapter will outline the steps necessary to build a chatbot with IBM RPA but will also discuss when a more elaborated solution would be needed.

We’ll cover the following topics in this chapter:

• Business problems
• Developing a chatbot
• Developing the knowledge base
• Packaging and deployment
• Leveraging the knowledge base in the WAL language
• Configuring the bot service
• Programming the chatbot
• Advanced topic—chat history

Technical requirements

As in the previous chapter, we’ll leverage the software-as-a-service (SaaS) edition of IBM RPA.

Business problems

There are many opportunities to automate self-help business scenarios, helping our internal employees obtain answers to frequently asked questions (FAQ). Customers can gain general information about businesses, such as when our business closes, whether are we open tomorrow, or whether we perform particular services. Everyone is familiar with texting. A chatbot is an interactive session between automation and humans. Complexities arise when trying to automate interaction with humans and human language, however, without the assistance of the NLP capabilities of the RPA software. Humans express themselves in many different ways; for example, a human may ask, “Are you open tomorrow?” and another may ask, “What times are you open tomorrow? For many interactions, we cannot even anticipate the exact wording that might be used.

NLP software vastly simplifies the task of automating a realistic chat interaction between our business logic and our human users. Identifying key nouns (names, addresses, phone numbers) is a common need for chatbot development. Let’s take a look at what comprises a chatbot.

The common components of a chatbot are:

• Business logic: It implements the desired dialogs with our customers or employee
• NLP: It’s used to build the business logic of automation
• Interaction style: Textual or voice
• Communication channels: SMS, Telegram, and more
• Bot integration service: A bot integration service provides a connection between the RPA bot and the communication channel or method, such as Slack

Developing a chatbot

IBM RPA provides a category of commands to develop chatbots for conversations with humans. Let’s examine some language processing capabilities. Central to any chatbot design is the need to process natural language responses; after all, the assistant will need to have a conversation with a human.

While developing this example chatbot, we will leverage two related technologies for interacting with human language: NLP and IBM RPA knowledge bases. Let’s start with how NLP capability can help our chatbot.

IBM RPA provides a category of commands to build up custom dialogs for conversations with humans. Let’s examine some language processing capabilities.

NLP

NLP is a form of trained machine-learned language models for identifying entities of different types, such as:

• Boolean
• Date and Time
• Email
• Name
• Address
• Currency

Let’s look at a simple NLP example and examine the utility of NLP processing:

defVar --name StreetAddress --type Address
defVar --name name --type List --innertype String
defVar --name personName --type String
defVar --name emailString --type String
defVar --name nameString --type String --value "Hello, yes
my name is John Smith and my email address is
[email protected]"
defVar --name addressString --type String --value "I live
at 123 Main Street in Poughkeepsie, NY."
extractNamedEntities --entities "Person" --culture "en-US"
--text "${nameString}" personName=first
logMessage --message "Name = ${name}" --type "Info"
extractAddress --culture "en-US" --addressText
"${addressString}" StreetAddress=first
logMessage --message "Address =
${StreetAddress.FullAddress}" --type "Info"
extractEmail --culture "en-US" --text "${nameString}"
emailString=first
logMessage --message "email = ${emailString}" --type "Info"

Running the preceding automation, we see the following log messages:

3/12/2022 4:57:39 AM - [Info] Name = John Smith
3/12/2022 4:57:39 AM - [Info] Address = 123 Main St,
Poughkeepsie, NY 12601, USA
3/12/2022 4:57:39 AM - [Info] Address = [email protected]

The extractAddress and extractEmail extract commands in the example are predefined RPA commands that return the first instance of the requested entity (for example, name, address, and so on) in the string to examine. The commands can also return a list of those entities if the response strings contain more than one name, address, and so on.

NLP’s capability greatly simplifies extracting the key information from fully formed responses from humans. Although these entities are visually easy for humans to extract, writing algorithms that can do so is a different story. Now, let’s take a look at what a knowledge base is and how it helps us with implementing our chatbot.

Before we dive deeper into the chatbot details, we’ll note that IBM RPA has extensive capabilities that can be leveraged together with chatbots. Database queries, spreadsheet lookups, email processing, and other features can be triggered to facilitate a more tailored discussion, to log interaction history, and to focus on the individual using the chatbot to interact with our organization.

IBM RPA Knowledge Bases

A knowledge base is defined by the American Heritage Dictionary as a collection of data organized into a form that facilitates analysis by automated deductive processes, such as an expert system. IBM RPA provides several styles of interaction with human text—for example, Text Classifier, Bag-of-Words, Functional Bag-of-Words, and Knowledge Base.

The IBM RPA Knowledge Base model has a simple Excel spreadsheet format, and it provides a database of questions and answers. You can provide many question formats that map to the same answer, to help cover some additional variance in how humans answer the question. It contains three sheets:

• KB: This sheet provides a set of questions and answers, along with additional details about the question to help IBM RPA match the specific question asked by the user to a given answer. Context helps the tool relate and match the human’s question to questions listed in the knowledge base. Tags help group related questions together, such as salutations, and more.

This sheet has the following columns:

• Question: A specific question for which an answer will be provided.

Note:

The same answer can be given for many questions, and this is a key aspect of making well-constructed knowledge bases—giving many different ways to ask the same question.

• Answer: This is an answer to the specific question.
• Context: The category or context of the question—for example, open hours, appointments, and so on. These can be leveraged by the IBM RPA bot to further enrich details about the specific context of the question asked.
• Tags: Yet another programming tool to simplify the processing of tailored chatbot interactions. Tags help organize related questions and answer pairs.

You can see a visual representation of this sheet in the following screenshot:

Figure 6.1 – Knowledge Base: KB sheet

• WORD: Set of proper nouns that the dialog should not substitute for synonyms. Suppose your company is named Think; you would not want to substitute any other words for this specific word.

This sheet has the following column headers:

• Word: Words that are to be treated exactly as is—for example, proper nouns.

Here’s what the sheet looks like:

Figure 6.2 – Knowledge Base: WORD sheet

• SYNONYMS: List of alternative words that a human might use in a conversation about this topic and supplements the IBM RPA synonym library.

This sheet has the following columns:

• Word: This is the primary word used in a knowledge base.
• Synonyms: These are alternate words that have equivalent meanings, separated by a semicolon (;).

The sheet looks like this:

Figure 6.3 – Knowledge Base: SYNONYMS sheet

Now, let us move ahead with an example.

Knowledge Base spreadsheet example

The spreadsheet format makes it very easy to create your initial set of questions and answers. Unfortunately, the product itself won’t create your initial knowledge base spreadsheet for you; but it is going to be much easier to work with the initial population of questions, answers, words, and synonyms regardless. Here’s what we’ll do:

1. We’ll create a spreadsheet for FAQ about a veterinarian clinic. For now, we’ll add simple question variations for when the office is open:

Figure 6.4 – Knowledge Base: questions and answers

2. Now that we have our initial knowledge base spreadsheet built, let’s use it to create an IBM RPA-managed knowledge base. We’ll leverage the IBM RPA Studio tool by going to the following setting:

Figure 6.5 – Selecting Machine Learning Model Builder

3. To add a knowledge base to the RPA control center, fill out the following pop-up box:

Figure 6.6 – Knowledge Center upload dialog

4. Once the knowledge base is uploaded, you will discover the knowledge base in the Studio knowledge base toolbar:

Figure 6.7 – Knowledge Base toolbar

IBM RPA Studio provides a sophisticated knowledge base trainer that allows the knowledge base developer to test and ensure that the answers to specific questions are correct and that the model will respond to questions that are phrased in a way not specifically added to the knowledge base. The tool can add responses, add questions, and remap answers. The trainer dialog contains a lot of information that will be difficult to see in one image, so we’ll zoom in to the various features:

Figure 6.8 – Knowledge Base trainer: test chat dialog

In the test chat dialog depicted in the preceding screenshot, the knowledge base can be tested by typing in the dialog and the resulting best answer will be displayed. Let’s type in a question: Are you open today? You can then explore the confidence level the machine learning (ML) model has with the resulting answer it gave and other possible answers that are displayed in the answer dialog, shown in the following screenshot:

Figure 6.9 – Knowledge Base trainer: answer dialog

In the preceding screenshot, we’ve loaded the Vet Clinic knowledge base into the trainer by double-clicking the toolbar. We’ve also typed a question into the message bar of the middle dialog: Are you open today? The trainer has responded with an answer that best matches the question asked, and the answer dialog shows the confidence score of the answer returned. Since that specific question is in the knowledge base, the confidence is absolute at a rating of 1,000 (1,000 is the most confident and 0 indicates no confidence).

Let’s ask a slightly different question: What hours are you opened on Tuesday? This is not specified in our knowledge base:

Figure 6.10 – Knowledge base answer

We can see the tool is indicating with the character that the confidence score judged for this answer is below the minimum score set in the tool, as confirmed here:

Figure 6.11 – Knowledge Base confidence tool

Best practice

Clearly, the higher the confidence score, the better confidence you have in the answer provided to an individual using the chatbot. The higher your confidence, the better your set of questions can be interpreted by IBM RPA and result in accurate responses. As you are working toward getting a higher confidence score, try working with teammates to get a different perspective on phrasing questions—it will help add variance from a fresh pair of eyes.

Let’s see what happens when we ask a question that has nothing to do with hours: Can I make an appointment online?:

Figure 6.12 – Knowledge Base unknown question

The Knowledge Base training tool allows for a sophisticated knowledge base to be interactively created and validated. You’ll have confidence that you will know how your dialog will respond to specific questions, even ones that are not specifically programmed.

Best practice

Log questions that return a confidence level of 0 or do not meet the minimum confidence score and are not successfully processed. Review the logs periodically. If the question seems valid, the response can be quickly added to the knowledge base, gradually improving your user’s experience.

Packaging and deployment

Okay—we’ve fine-tuned our knowledge base; let’s mark it as a production version. IBM RPA has taken over the serialized form of the knowledge base and is managing it in the control center. Let’s make the knowledge available for Write Ahead Log (WAL) automation:

1. In the Knowledge Base Training dialog in IBM RPA Studio, navigate to the Changes tab.
2. Check the Production Version checkbox.
3. Click Publish:

Figure 6.13 – Knowledge Base trainer: Production version

Once you’ve published your knowledge base, you can manage it via the control center and leverage it in WAL scripts.

Leveraging the knowledge base in the WAL language

Before we embark on encoding chatbot automation, let’s look at using the knowledge base with non-chatbot commands so that we can see it in action without having to do the configuration. We will leverage the answerQuestion command, and we’d expect the same behavior as we observed using the knowledge base training tool:

defVar --name chatHistory --type String
defVar --name answer --type String
defVar --name success --type Boolean
answerQuestion --kb vetClinic --minimumscore 500 --
botHistoryMessageId "${chatHistory}" --culture "en-US" --
text "What hours are you open?" answer=answer
success=success
logMessage --message "The answer is ${answer}.  Success:
${success}" --type "Info"

After executing the example command, we’ll see that the script log indicates the following:

3/15/2022 5:43:50 AM - [Info] The answer is The Vet Clinic
is open Monday-Friday 8AM-8PM and every other Saturday 8AM-
Noon.  Success: True

Now that we have the basic chatbot approach, leveraging a knowledge base, we are ready to examine chatbot automation.

Configuring the bot service

IBM RPA leverages Azure Bot Service to provide a wide array of chat integrations, such as Slack and Microsoft Teams, to interact with users using their natural chat applications. IBM RPA SaaS provides an RPA-hosted chat application to provide an out-of-the-box chat experience, as depicted here:

Figure 6.14 – Azure Bot Service integration

Next, let’s understand the components of the preceding diagram.

Azure Bot Service

For IBM RPA SaaS, the IBM System Reliability Engineering (SRE) team will configure your Azure Bot Service instance for you by opening a service ticket—for this example, a Direct Line connector is used to connect the RPA-hosted chat application. In our example, the SRE team will provision a bot named vetClinicBot. Note that vetClinicBot is the Azure Bot Service configuration name, and through the following steps, we’ll link that service to the vetClinic automation hosted by IBM RPA, as depicted in Figure 6.14.

Our bot automation will be hosted on a computer that is in our enterprise (as with all automation in IBM RPA). The IBM RPA control center will allow a configuration (chat mapping) to make that connection easy to program. The Azure Bot Service instance will be configured to select the desired integration—for example, Slack, Telegram, and Microsoft Teams. Here’s what we’ll do:

1. For this example, we’ll leverage the RPA-hosted chat application that connects to Azure Bot Service via the Direct Line integration.
2. For IBM RPA on-premises deployments, you can provide your own Azure Bot Service application IDs, passwords, and secrets. You’ll need to collect the application ID and generate an application password as well as a secret for the Direct Line integration.

Note

You will need to have the PlatformAdministrator role to perform this update.

Figure 6.15 – Create bot dialog

3. Now that the bot has been added to the RPA configuration, we need to map our bot script and configuration for our system. This will map our bot automation script and configured computer host to the bot channel. The following screenshot illustrates how to do this:

Figure 6.16 – Creating a chatbot mapping

4. After clicking the Create chat mapping button, we’re presented with a three-step mapping configuration dialog:

Figure 6.17 – Creating a chatbot: bot details

5. Then, map the script and compute resources to the chatbot. This step binds our RPA automation to the configuration made by the IBM SRE team, which connects Azure to RPA:

Figure 6.18 – Creating a chatbot: script and compute

6. You can even provide CSS detail to customize the chatbot avatar in the next dialog box. Avatars may be used for certain human interaction dialogs that will appear in those applications—for example, Slack icons. Giving your chatbot a custom avatar can make the chatbot more fun for users and clearly identify it in the user’s mind. We’ll use the default avatar here:

Figure 6.19 – Creating a chatbot: styling

So far, we’ve finished all of the integration configurations to connect our automation script to the chat application, leveraging the Azure Bot Service integrations. RPA is connected to Azure, and the user’s chat application is connected to Azure. In this example, we’ve used the integration style called Direct Line integration.

Programming the chatbot

Now that our chatbot channel is connected to our Azure Bot Service instance and we have mapped the script and compute resource to the chat session, we are ready to program our chatbot. We’ll leverage the knowledge base we’ve built previously and see our chatbot in action, but this time leverage this in the bot-specific commands to this point we’ve been deferring.

Let’s get to it.

The WAL language is capable of very intricate dialog control, but we’ll just keep it simple and explain the concepts—the richness and complexity of your interaction are up to you:

defVar --name questionText --type String
defVar --name robotUtterance --type String
defVar --name answerTimeout --type Boolean
defVar --name answerSuccess --type Boolean
defVar --name bestAnswer --type String
defVar --name contextTag --type String
defVar --name chatContext --type String
defVar --name bestAnswerScore --type Numeric
defVar --name success --type Boolean
defVar --name language --type Language
createLanguage --culture "en-US" language=value
botConnect --type "Chat" --language ${language} --
autoanswer
botAnswerQuestion --kb vetClinic --minimumscore 500 --
timeoutsub miscommunication --text "Hi! How can I help
you?" --timeout "00:00:30" robotUtterance=utterance
bestAnswer=answer contextTag=tags bestAnswerScore=score
success=success
botSay --language ${language} --text "${bestAnswer}"
botDisconnect
beginSub --name miscommunication
botSay --text "Thank you for contacting us!"
endSub
defVar --name answer --type String
defVar --name success --type Boolean

Let’s understand the preceding code:

1. First, we can see that we need to connect the bot runtime to the bot channel configured and indicate that it is a chat interaction, rather than Interactive Voice Response (IVR). IBM RPA seamlessly integrates text or voice such that the bot commands work with either style of channel.
2. Second, we use the bot-specialized answerQuestion command called botAnswerQuestion.
3. This convenience saves us from using three commands:
   • botAsk
   • botSay
   • answerQuestion

This saves us time and coding effort, although in some cases it is nice to handle the specific processing individually so that we can insert IBM RPA functionality to facilitate a more tailored response for this individual.

4. Now, finally, since we are still developing our script, let’s debug the script in Studio—it will pop up a text chat dialog to support this debugging environment:

Figure 6.20 – Chatbot Debug dialog

In the following screenshot, we can see a zoomed view of the chatbot dialog window from the preceding debug session, where we can interact with our logic in debug mode:

Figure 6.21 – Debug chatbot in action

Now that we have debugged our chatbot scripts and trained the knowledge base, we are ready to expose it to our chatbot users.

IBM RPA-hosted chat

The IBM RPA SaaS provides an out-of-the-box experience for chats, which we’ve already configured.

Simply point your browser at https://br2-bot.wdgautomation.com/integration/vetClinicBot and you’ll see the chatbot in action live.

Best practice

Each chat session requires a unique runtime to host the chat sessions, and you’ll need to make sure you have enough compute resources to host as many concurrent chat sessions as you plan to have. You may also be limited to the number of concurrent sessions in your license agreement.

While the examples in this text are limited to text, you can leverage images, upload files, and integrate card carousels that allow for a click-button selection of topics or chat selection, all with built-in WAL automation commands. With more sophistication, you’ll have a powerful ally you can count on to aid your customers or employees.

Advanced topic—chat history

IBM RPA makes it easy to add chat history to a local database. The WAL language provides commands to connect to a local database and will automatically create the following tables, which are configured for viewing the chat history:

Table 6.1 – Chatbot history tables

There are two strategies for storing the chat history, as follows:

• In a local database
• By leveraging the server database

Note

The term local here really means hosted on-premises, whereas, the server database is hosted by the IBM RPA SaaS components.

IBM RPA chatbot history local database

We’ll look at the pattern for connecting to an SQL Server database in this example; of course, your database connection string will likely be different based on the type and security constraints your company may require:

1. Create a connection to the database that will hold our chat history:

   defVar --name connection --type DbConnection

   // Connect to the database via the connection string

   and store the connection data in the connection

   variable.

   sqlServerConnect --connectionstring " localhost

   SQLEXPRESS;Database=botHistory;Trusted_Connection=

   True;connection=connection

   // Check if the connection was successful

   assert --message "Could not connect to the Database!"

   --left
2. Once we’ve connected to the bot history database, we need to create a StorageAdapter object from the database:

   createStorageAdapter –storageStrategy "Local" --

   dbConnection(DbConnection)

   (StorageAdapter)=storageAdapter
3. And finally, we’ll pass the storage adaptor to the chat connection itself:

   botConnect --type "Chat" --language ${language} --

   storageAdapter ${storageAdapter} –autoanswer

Voilà! You’re now configured to store your chatbot history.

The WAL language offers commands to process the database so that your team can review the chat sessions to ensure your chatbot is behaving the way you intended and your users have a great experience. Since the data is captured in the database, you can also leverage any programming language you’d like to process the history.

IBM RPA chatbot history server database

Leveraging the server-side database is even easier. You don’t need to create a database—just change the adaptor to indicate you’d like to store history in the RPA server database:

createStorageAdapter –storageStrategy "Server"
(StorageAdapter)=storageAdapter

The botConnect command remains the same as step 1 from the previous section.

Summary

In this chapter, we took a cursory look at the built-in language features used to interact with human natural languages and built up a knowledge base to automate a FAQ dialog with our customers and employees, and we’ve seen how Azure Bot Service can wire-provide the chat integration for a variety of popular applications as chat channels, such as Twilio and Slack. A simple web-based channel is provided for you, hosted in the browser so that you can ramp up quickly. Entry-level self-help and FAQ applications really hit the sweet spot for RPA-delivered chatbots, and while IBM RPA offers features for programming very sophisticated interactions, other offerings such as Watson Assistant may offer better tools for large complex knowledge bases and great scalability for large numbers of users.

The RPA world is filled with ad hoc automation opportunities, and quick wins and specific automation are valuable at the department scale. We’ll be moving on to technologies that can be leveraged to provide end-to-end process automation: workflows.