>> You're not going to miss this episode of the AI Show,
where Gary shows us how to make
things that sometimes don't work with the above framework,
easily work really quickly. Make sure you tune in.
>> [MUSIC]
>> Hello and welcome to this episode of the AI show.
Were going to learn a little bit more about bots,
maybe some fundamentals and some surprises.
Gary, why don't you introduce yourself?
>> Yes. I'm Gary Pretty. I'm a Senior Engineer
on the Bot Framework SDK team.
>> So let's start with bots in channels,
I've heard that bot a lot. Why don't you describe what that is?
>> Yes. So you build a bot,
your bot is essentially,
it's a web application,
but you want to surface that in multiple places.
So let's say, you wanted to put a bot into Facebook,
Facebook Messenger, or Web Chat,
or at Microsoft Teams,
for example. They are channels.
So you can think of channels almost
like where you surface your bot.
Where can I talk to my bot?
Whether that's through voice or through text, that's a channel,
and a channel is specific to what's called the Azure Bot Service.
What we can see here is,
in Azure, I've created a bot.
It's simple as, take a look at the channels list.
Right now, I've connected my bot to Microsoft Teams,
and to web chat.
But then down here, I've got a list of additional channels,
so I could if I wanted to put it in Slack, or in Skype,
Facebook, I could connected or to Office 365 e-mail.
It's a pretty extensive list.
>> It's the same back-end that
is able to communicate with all of these things?
>> Yeah. That's right. So there's
something called the bot framework adapter,
which sits within the SDK,
and it will receive messages from the Azure Bot Service,
and it's the responsibility of
the Azure Bot Service to take the incoming requests from say,
Facebook or Microsoft Teams,
and then to translate that into
this common format that we understand within our box.
>> I see.
>> Yeah.
>> So as I'm looking at this list,
what if there's something there that I want,
but that's not there.
Is there a way to make it still work?
>> Yeah. So with the Version 4 of the SDK,
we have something called Custom Adapters.
So I mentioned before the bot framework adopt during the SDK,
well, we can actually go and implement the adapter interface,
and write our own adapter if we want to,
and the responsibility of
that custom adapter is really pretty simple.
It takes a request from a platform,
whichever platform you want to support.
It will transform that into bot activities.
The bot will handle them in the same way as it
would do the same code will handle that,
if you were running in Teams,
and then it will send that back,
and the adapter will then transform it back into
a response that's appropriate for that channel.
>> So it's basically like an intermediary between what
the bot framework understands and then
whatever else writing other thing,
it could be like an IoT device,
where they're terminal or something.
>> Yeah. Exactly.
>> That's cool. Well, can you show us how it work?
>> Yeah. Sure. So I've got
a very basic bot here running in the emulator,
which I've had a brief conversation with.
So it's a flight booking bot.
It said where do you want to travel to?
London. I'm coming from Seattle.
So what I'm showing here is,
we have an endpoint /API/messages,
and that's where the emulate will actually send the messages to.
That's going to be handled by the built-in bot framework adapter.
The bots can process that message,
and then send the response back via that bot framework adapter.
So if we switch over to Visual Studio,
what we can see here,
is the AdaptiveWithErrorHandler, is
our instance of the standard buffering work adapter.
We also have a controller,
our bot controller, and this is the api/messages endpoint.
The responsibility of this controller is simply to say,
"I'm going to hand off to that bot framework adapter,
and I'm going to say, "Here's the request that's coming.
Now, send that to my bot.""
Then when the request comes back,
then it's going to post that back
to whichever channel that I'm working with.
>> Totally makes sense. So the couple of questions.
>> Yeah.
>> So the adapters job is to transform
the messages back and forth
so the bot framework can understand it.
Now, like for example,
if I want this to work with other channels,
do I have to have multiple adapters, or how does that work?
>> Yes. So you would have an adapter.
Let's say there's a channel that you would like to
use and it's not available on Azure Bot Service yet,
or for maybe security or compliance reasons,
there's a reason you can't use Azure Bot Service.
We have customer adapters built into the SDK,
and we also have adapters which have been contributed
to our blockbuilder community project on GitHub.
So we've got adapters for Twilio, WebEx, WeChat.
So there are some fairly common requirements
that people were asking us,
can I have my bot to WeChat.
So we've gone ahead and built
a WeChat adapter and made that available.
You would have, typically,
an adapter per platform that you want
support that's not within the Azure Bot Service.
To implement that is very, very straightforward.
So first thing you do,
is you go and find the NuGet package from NuGet,
for the adapter you want to use.
So the top three that you can see here,
are Alexa, Google, and Twitter,
which are our community adapters,
maintained by the community,
but also supported by the SDK team as
well in terms of we contribute to them all the time,
and then we've got the built-in adapters, Twilio and WebEx.
We've also got adapters for Slack and Facebook,
which actually have a slightly larger footprint,
and for those two particular platforms.
Once you've installed the particular package.
So I've installed the Alexa adapter, in this case.
So I want to have my bot be able to power an Alexa skill.
But the great thing is,
because I can just add
an additional controller, like I have done here.
I've added an Alexa controller.
It adds an additional endpoint.
So I can still have the conversation from the emulator,
or through teams, or Facebook,
I don't lose anything.
But I actually add this additional endpoint for,
in this case, Alexa.
I've got alexa adapted with error handler class,
which is just the electrode adapter,
and then we're adding some standard error handling in as well.
So really quick, you can add
this to an existing bot in just a few minutes,
and then what will happen,
I've got this bot running at the moment.
So if I switch over to this,
this is the Alexa Developer Console.
All I had to do here is create an Alexa Skill.
I've registered in the Alexa Skill,
and I've pointed that Alexa Skill such that your fulfillment
URL is the new /API/Alexa endpoint.
So now, any request that comes from
Alexa is going to hit that Alexa controller,
which is going to hand it to the Alexa adapter,
and then that will actually transform the JSON.
In this case, it's being received from Alexa.
Send it to my bot in a format that they understand,
that common format that we were already familiar with,
and then when it comes back,
it will transform it into an electrical response,
and send that back to the service.
What that allows us to do,
is this, so I can say open flight booker.
So just as you would say,
I can open flight booker.
Right now, quick tip for people,
is I've got, I'm using Endrock,
in this case, to actually tunneled through to my local bot.
So it's not like the debugging experience is awesome.
Because actually, this Alexa simulator
is actually calling through to my local bot,
I can stay right point in and I can understand what's happening.
>> That's cool.
>> What you can see has happened here,
is we've got the JSON input,
so I can see the full requests that Alexa sent to my bot,
and again, I could just take a break point on
the controller and actually see that coming in.
You can see, the response that is being output by the bot.
So I can then carry on having
a multi-tenant conversation with this.
So I can say book a flight.
That's going to send a follow-up request.
Because the bot framework will handle things
like state management and it
knows where you are in the conversation,
you don't lose any of that.
You retain all of that goodness within the SDK.
You can see here, that I'm actually able to have
a multi-tenant conversation with Alexa.
If I wanted to, I could add in Google as well.
So almost like the Xamarin of home assistants, in that case.
>> That's cool.
>> Or I could just as easily be using all
of the adapters within the SDK,
as well, that we've made available.
So I guess just to color in terms of where you get started,
we've got some fantastic jogs in
Microsoft Docs for things like WebEx, Twilio, etc.
So these will actually just walk you through
how you connect the adapter up.
It's very no more complicated than what you just saw.
Actually, the most time-consuming bit,
is usually configuring the platform,
rather than configuring your bot,
and then our Bot Builder community is an active community,
we've got repose for all of our different SDKs.
If I just jump into the.Net community,
we have lots of different extensions for bot framework.
But here are the three adapters that you can see,
and we've got very good documentation
here as well in terms of how you can get started.
>> So a couple of questions. So I
understand the notion of adapter,
I did a bot a long time ago,
and so maybe you can help to refresh me.
What I did, is when I created a bot,
I just selected the channels
that it would work in and it would just work.
>> Yes.
>> When it comes to these special adapters,
it seems like I have to do some code stuff,
which makes sense, because you've got to do transformations.
But how does the bot know that it can,
for example, because let's just say,
Teams is obviously one of the ones that's in there.
I'm not going to do any coding for Teams,
it will just work, and then for the adapter I have to add code.
How does it know to do both at the same time?
>> Right. So if we jump back to Visual Studio,
the fact that we've got these two controls,
the controller is being setup for that particular platform.
So if it comes in on api/messages,
it's going to hand it to the built-in bot framework adapter,
and if it comes in on the lecture endpoint,
is going to hand it to the Alexa adapter.
By the time that incoming request gets to my bot,
where I'm actually processing that message,
the incoming message looks exactly the same.
So you can build this single application,
and send and receive messages,
the adaptive is going to handle all that complexity for you,
of transforming those requests in and out.
>> I see.
>> We can then take advantage of additional platform features.
So the homocysteine adapters for Alexa and Google, for example,
allow you to do things like take advantage of the screens on,
say the Echo Show or the Google Nest Hub.
So you can show rich cards or videos,
and all you would do in that case,
that's exactly the same as when you're tailoring
your conversation for other channels.
You can say within your bot,
if this message has come from Alexa,
play this video via Alexa,
or if it's come from Google,
send a push notification to the Android device,
or if its come from Teams,
I want to send a notification for the user.
>> So let me see if I understand correctly.
Basically, because you give it a route for
that specific adapter, it comes in,
and on the adapter, it does a translation,
but then it passes it off to
your standard bot logic that you build for everything else.
>> Exactly.
>> Okay.
>> Yeah.
>> Which makes sense. It basically redirects and
then mix the message exactly what we want.
>> Yeah.
>> That's the thing. That makes more sense.
My confusion was like,
how does this all happen?
But now that you're doing a routing, that makes a lot more sense.
>> Yeah. Because it routes it.
In theory, what that means is,
you could build a conversation that is not
in any way tailored to any specific channel or platform,
which just sends and receives messages,
and you can have an identical conversation
on all of them, like you've just seen.
But then you could tailor on top of that, and say, "Well,
if I am running in this particular context
of a Home Assistant device,
that I'm going to do something extra."
>> Got it.
>> Yeah.
>> Then you would know, because in
the conversation it would be like where it came from.
>> Yes.
>> It could be some switch statement or some code thing.
>> Exactly.
>> That makes sense. Well, this was awesome. Thanks so much.
>> Thank you.
>> Thank you so much for watching. We've been
learning all about adapters,
how you can get other things,
channels that maybe are not available to bot framework,
to actually work just like as if they were.
Thanks so much for watching. We'll see you next time. Take care.
>> [MUSIC]