1. Home
  2. Training Library
  3. Google Cloud Platform
  4. Courses
  5. Building Chatbots with Google Dialogflow: Part 2

Connecting Up Answers & Data

Developed with
Calculated Systems


Building Chatbots with Google Dialogflow

The course is part of these learning paths

Start course

This course is the second part of our series on building chatbots using Google Dialogflow. In this course, we'll be taking a hands-on approach to implementing a Dialogflow chatbot, specifically focusing on the graphical user interface. You'll follow along as we cover the example of building an online banking customer service chatbot using Dialogflow.

We'll also discuss the use of databases and other knowledge sources in order to provide meaningful responses that give you the option to serve real-world information to your user. 

Learning Objectives

  • Learn what intents are and how to train your chatbot to look for them
  • Set up entities in Dialogflow
  • Understand how chatbots interact with users and how to test your chatbot
  • Learn how to connect your chatbot to a data source
  • Understand the user interfaces available with Dialogflow
  • Learn how to use the Knowledge service to build chatbots quickly and with less configuration

Intended Audience

  • Anyone looking to build chatbots using Google Dialogflow


Before taking this course, make sure you've done Part One first. To get the most out of this course, you should also have a basic understanding of: 

  • Computer science techniques
  • REST APIs and SQL
  • Google Cloud Platform

So far, in all of these examples, we have simply used the onboard Dialogflow response in order to fulfill the questions. However, in real life Dialogflow is not going to have any meaningful data. In our bank and concierge example, Dialogflow is not just going to have a pre-program value of how much money is in your account. No, it's going to have to go look that up in an external system and odds are the bank has some form of SQL or no SQL system storing the account master record and we're going to need to somehow get that data out of that system and into Dialogflow. And the way we do that is called fulfillment.

So now there's a lot of ways to get data in or out of a source of records, but for Dialogflow you really have only two main options of interacting with the conversation agent. The most common way of these is to use a series of requests built around the rest API.

So Dialogflow will start to do all of its magic and do all of its fantastic work managing the conversation before neatly packaging all of that up and call an external system. At its core, the agent will determine what the intent being invoked is based on your training phrases. And then of course it will slot fill in your parameters and action groups. And I'll take all of these known good options and configurations and create what's called a web hook. This web hook is set at the agent level and can be changed between agents, but not for the same agent.

Each agent gets one web hook and it passes these parameters back through the third-party rest API. And it's received by a third-party rest API server. The server that needs to take the JSON document and parse the intent entities before calculating a response and formatting a fulfillment message. And apart from rest API, another way that Dialogflow could be fulfilled is through Google Cloud functions. And this could either work in one of two ways either the function could receive a rest request of course, or you could use the inline editor.

Now, in my opinion the inline editor is a fantastic way to start building your fulfillment service from the ground up. But unfortunately, it does have some limitations. Yes, you're able to do parsing of JSON's inline. Yes. You're able to make fantastic database calls and format and return a message. However, the inline editor is a Google Cloud function that by definition is embedded within Dialogflow. This limits you in that you can't separate your fulfillment service and your Dialogflow surface. So in my opinion as you go towards production, this is limiting. So just know that your two options are either to use a rest API external web hook, or using the inline editor for fulfilling a Dialogflow fulfillment call.

Now, to start doing fulfillment, you need just click on the fulfillment tab, the lightening bolt on left-hand. Now there's a few different things but first you need to enable it. Fulfillment bolt is turned off. Dialogflow will not make any outgoing calls. So you need to configure Dialogflow to have enabled fulfillment and point it at a URL that is your rest server. And when setting all of this up, a key point is that Dialogflow only works over HTTPS. This can be a real pain in the neck frankly, if you're spinning up your own service from scratch and you haven't gotten HTTPS certificates ahead of time. So if you having to do this, maybe you'll want to set to the inline Google function editor for now. But if you are able to set up an HTTPS service you can set a really good web hook here.

Now note there's some other stuff here as well, in addition to HTTPS, you can set basic auth and some custom headers for maybe some more security. But if you're doing this in production, particularly if there's things such as PII or PCI and sensitive data be aware that this is not a full end-to-end security option. You need to be aware of how else dialog flow can handle data because just 'cause you're connecting over HTTPS doesn't imply security you need a full layered security model. So once the webhook is set up you're not actually entirely ready to go.

Each intent is actually programmed to use a web hook for fulfillment or not individually. So you need to go and configure each one. So it knows if it should use the built-in response segment or should make an outgoing call. This is important when designing each flow because each intent can have this configured individually.

Another important point here is that you can also enable web hooks for slot filling. So, whereas we previously had the action groups the webhook can also help here. Now this is really cool because beyond using predefined phrases to ask the user about their question you can give really tailored responses. Imagine Edith when she's asking for her card number and she says something like, "What's my payment card balance?" we could ask her simply did you mean card one, two, three, four, a? And all she has to do now is say, yes. This has provided her with some context and a tailored experience. And overall, this is gonna lead to a much better user experience for her.

And on a final note here before we move on to some more complex issues, you might occasionally see references to small talk and you can actually set the web hook to fulfill small talk. All small talk is how Dialogflow handles pleasantries. It's a nice to have. And what I mean by this is, it simply answers questions like, hey, how are you doing today? Or, Hey, what is your name? Or where were you born? It's all the silly and fun things people like to ask chatbots. There's actually a whole section of it on the left and it's not necessarily needed but if you want to really start to program personality into your bot and have the backend handle it you might wanna check out enabling that.

On the flip side, outside of using the web for fulfillment the inline editor is also a really strong option. So the inline editor is independently enabled or disabled. And if you have the inline editor enabled, you can't also have web hooks enabled. You can't have it both ways you need to unfortunately pick just one. The inline editor is a way to set up a Node.js response system for your agent. It's important to note that on the backend, this uses Google Cloud functions. So billing has to be enabled which is controlled at the project level. If you haven't already done this, you might be forced or prompted to address it now, but assuming that this isn't for an issue for you just move through it and you can actually start setting up the function.

So if you're not too familiar with the elements of a Node.js function, I'll give you a brief overview of how it relates to the Dialogflow agent but we're not gonna dive too far into it. Basically, you have two things. You have your index such as and your package.json. The index file contains all of the logic and functional code. And if you have an underlying source of truth, such as Firebase or Postgres, this is the segment that will control parsing the query, routing and writing the responsive between the database and Dialogflow.

Alternatively, the package.json is some playlist of the metadata and dependencies for your function. This all comes together to make a work in Google Cloud function. We're not gonna go too far into it but just know that these two files work together and to order to handle all of the backend fulfillment routing and flow management that you need to handle Dialogflow responses. So once you've enabled external fulfillment either through the web poker inline editor, try using the simulator again.

So in this example, the simulator is really, really useful because what you're able to do is see what gets passed to and from the backend service. In our case, a simple query like we just showed, will send a JSON file like this. Take note that the parameters are actually the entities we've been programming. And if you recognize this intent, it's to transfer money intent in which the credit card numbers have two different parameter names, both sending and receiving card. We've also taken full advantage of the built-in dollar amount, which you could see here. And as it's represented as a system parameter.

So as all of this comes in you're actually able to see both what goes to and from the API in order to debug your fulfillment status. And by far, if you're anything like me the first area you're going to get is something along the lines of a timeout. And this is where the simulator is great, because at the bottom you can actually make a copy of the request that Dialogflow has made to the backend and test it yourself. So you can use a local rest client in order to simulate the Dialogflow agent.

So as a cool note, I do wanna show off a little about what a built out web hook handle or might look like in practice. This is a screenshot from Apache NiFi, an open source program that we mentioned in one of the outlines earlier and it's a great way to handle rest requests. It's one of the many ways actually to handle incoming requests and both routing and giving responses. I like using NiFi as an example because it's a graphical way to show what's happening. The larger boxes you're seeing are collections of actions while it's the smaller ones are more of like a single function action you might see.

In order to handle the simple bank and concierge bot we've been discussing, we need three main groups of actions and a few helpers. Firstly, we need to be able to handle an incoming web hook. This is a collection of actions when you're designing your backend service that needs to be able to receive and authenticate and parse the in coming rest request specifically a post. It then needs to be able to pass a payload to something that will route it to the correct set of database crews. So we need to look at the JSON that's coming in and then determine what the intent is before sending it to a specific action group that handles that intent.

So in the case of the previously mentioned concierge bot there's really two directions. It could either be a check credit card balance request or a transfer money request. So in both of these cases, it'll take the incoming JSON do some form of lookup against the source of truth most likely Firebase or Postgres before sending it on to respond to the post. It's important to note that all this has to happen relatively quickly.

So it doesn't time out because Dialogflow needs to both make the outgoing request and receive the response in the same message. This is not asynchronous at all. This is actually very synchronous and tightly tied to the Dialogflow agent. It's also important to note that you'll want to handle the formatting of the fulfillment message with your backend handler.

As we mentioned before, it's not plain English coming back. It's actually a slightly formatted JSON, that indicates what the default actions should be. It also could include instructions for specialized responses depending on the platform such as if you're responding to Slack or Facebook messenger.

And now finally, to show off how this backend would have a response go back. This is an example of a response from a full request. We can see how it bounces through the raw API response and onscreen, you could see a formatted response coming to the surface. You could see the fulfillment request being specified in plain English with some of the other parameters that include routing information for Dialogflow up top.

About the Author
Learning Paths

Calculated Systems was founded by experts in Hadoop, Google Cloud and AWS. Calculated Systems enables code-free capture, mapping and transformation of data in the cloud based on Apache NiFi, an open source project originally developed within the NSA. Calculated Systems accelerates time to market for new innovations while maintaining data integrity.  With cloud automation tools, deep industry expertise, and experience productionalizing workloads development cycles are cut down to a fraction of their normal time. The ability to quickly develop large scale data ingestion and processing  decreases the risk companies face in long development cycles. Calculated Systems is one of the industry leaders in Big Data transformation and education of these complex technologies.