[MUSIC PLAYING]
SPEAKER: You're working hard to provide your customers
with the best customer experience possible,
whether that's through machine learning applications,
chat bots, or mobile messaging.
At Google Cloud, we want to make it as easy as possible
for you to adopt virtual agents and bots, which
need to be integrated with Enterprise system
and processes.
That's why Apigee, which is Google Cloud's API management
platform, has native capabilities
to make it easier and faster to get
started with conversational AI.
The specific challenge we're tackling
is connecting conversational AI products, such as DialogFlow,
with your backend systems, especially legacy systems.
Our goal is to make the deployment of bots
and virtual agents faster, giving your team's time
back to focus on innovation.
And give your customers a stellar customer experience
with speedy replies and orchestrated responses.
Let's talk about how Apigee can do this.
Apigee is an intuitive platform for bot designers
and architects to incorporate key business function
and insights into the workflow.
It acts as an API fulfillment engine,
essentially enabling DialogFlow to talk
to your backend systems.
It does this in three ways.
Your IT teams can get your conversational AI deployment up
and running quickly, while still focusing on other modernization
efforts.
Your conversation architects don't need
to spend time integrating APIs.
They can focus on building great voice experiences
for your customers.
And all your teams can build APIs once, and reuse
across different use cases.
Apigee has native policies available within the UI that
will make the API fulfillment process even more turnkey.
These policies can pars DialogFlow requests,
set DialogFlow responses, and validate parameters
captured by DialogFlow.
I built a simple flow in DialogFlow CX that
allows someone to rent a car.
The user is asked when and where they want to pick up the car.
They pick a specific car, confirm some details,
and the rental reservation is booked.
Let's run in the simulator and see how it works.
Hello.
I'd like to rent a car.
San Jose, California.
No.
June 13th, 3:00 PM.
June 15th, 9:00 AM.
Yes, that sounds good.
Let's go with the Charger.
Yes.
Visa.
412341234.
John Smith.
2930 Pearl Street, Boulder, Colorado 80301.
80301.
It was easy for me to rent a car with this agent.
The conversation was natural and the agent was responsive.
You may have noticed the list of parameters in the simulator.
DialogFlow allows you to store pieces
of information and parameters.
Some of these come from what the user says,
and others are retrieved from backend services.
A big part of creating a good conversational application
is integrating with backend systems.
DialogFlow lets you specify a webhook
to connect with backend systems.
For example, I used a webhook in the list vehicle
step of my flow.
When the conversation reaches this step,
DialogFlow will make a call to the backend system that
has car inventory information.
In this demo, I used Apigee to build a set of APIs
for my agent.
Apigee lets you quickly build and manage APIs.
Apigee has two new policies just for working with DialogFlow.
If we look at the step where the agent lists
which cars are available, we can see
that it uses the Get Vehicles webhook in the Search Cars tag.
Let's look at the definition for that webhook.
For the webhook URL, I provided the URL for the API
on managing in Apigee.
I also supplied a client key from Apigee
that will be passed as an HTTP header.
This client key identifies the application
and lets Apigee control access to the APIs it manages.
Next, let's look at how this API works in Apigee.
In Apigee, I created an API proxy
to handle requests from DialogFlow.
I've configured a set of Apigee policies over here,
and I have a series of flows that handle specific requests.
The proxy endpoint pre flow is called for our request.
I also have four conditional flows
that will be called depending on which
tag is specified in the webhook fulfillment setting.
In the pre flow, there are three policies.
The first checks the API key that is passed in the header.
If the key is missing or invalid,
an unauthorized response is sent.
Otherwise, the flow continues.
Next, I remove the client key header,
since it's no longer needed.
The third policy is an instance of parsed DialogFlow request,
one of the new policies for working
with DialogFlow in Apigee.
Messages sent from DialogFlow have a JSON payload
that contains the intent, session ID parameters, and more
that are sent with the webhook request.
Parsed DialogFlow request takes his information
and turns it into variables that can be
referenced in this Apigee flow.
Let's turn on the trace and see how it works.
If we look at the trace, we can see all the details
of what happened in Apigee when the webhook was called.
The request enters here.
A number of policies are called.
We'll notice here in the parse DialogFlow request
that a whole bunch of variables got created.
And those were based on parameters
that were present in our session in DialogFlow.
All of these will be available at the Apigee flow
and can be used in different policies.
We set a condition to follow a conditional flow
based on the value of the fulfillment tag.
In this case, the fulfillment tag was equal to Search Cars,
and this was a post request.
So that particular flow was followed
and these steps were executed.
Let's look at the flow that manages
the booking of a reservation.
This flow calls out to a Cloud function.
The Cloud function requires authentication.
The first two policies in here make a call
to the Google Cloud Identity Management system.
They send some credentials that I stored in Apigee's key value
map.
Those credentials are exchanged for a token
that I can pass in a header to the call to my Cloud function.
The next policy is the call to the Cloud function
that will make a reservation.
I send the token in several parameters
that were sent from DialogFlow.
The car description, the start date, the end date,
and the location.
Apigee then makes a call to the reservation service
and reserves a car.
The response is stored in a variable
called Reserve Results.
The next policy is an extract variable policy.
And it's used to retrieve the reservation
ID and the reservation total from the response from the call
to the reservation system.
Next I use a set DialogFlow response policy
to send the reservation ID and total back
to DialogFlow's parameters.
DialogFlow uses that information to confirm the reservation
with the customer.
Using Apigee to manage the APIs needed by DialogFlow
allows a conversation designer who's
building things in DialogFlow to focus
on providing an excellent user experience,
rather than worrying about how to integrate with Enterprise
systems.
It allows an API developer to quickly build
a set of experienced APIs to support this application.
They can hide away the complexities
in the backend services.
This won't be the last API we need
to build for this project or something else that requires
access to backend services.
But establishing a standard pattern for this
will save us a lot of time in the long run.
Apigee, and the two new policies specifically for DialogFlow
make this easy to do.
Now it's your turn to try it out and get
started by following the links in the description below.
[MUSIC PLAYING]