>> We're back. Thanks very much.
In our last segment,
we actually saw how to add some navigation
to the app so that we could focus on
specific colleagues that we're working with.
We also learned how to filter the events that we're showing,
how to put e-mails in and how to filter those.
Then we saw how to use
the file Insights API to
get insights into what people are working on.
[inaudible] , you said something
earlier in the section where you were talking with [inaudible].
You made a really good point that
we are geographically distributed.
I mean, we're all over the world in our team.
I think this is happening more and more these days.
I'm wondering if there's some way we could
show the locations of the users
inside of our app and also really show time zones,
because time zones are really the tricky part.
Even right now, the three of us are
on three different continents and it's quite late where you are.
>> That's right. We all know that because, in our team,
we are all globally distributed and we probably know
our teammates' sleeping patterns
more than probably a parent or family.
I guess that's an important functionality that we should
add in the app to know more about our team.
Let's jump in to get my colleagues function,
which we saw earlier in our session with [inaudible].
We basically pulled out all the colleagues information,
we saw their display names, job title,
department, and what you also notice is we are picking up
city, state, and country of our colleagues, as well.
>> Wow. That's in the graph, too?
I can get all that information?
I don't have to pop up and say,
"Hey, where are you," or anything?
>> No. It's all there and the Developer does not
even have to know where this information is coming from,
which service from M365 is providing.
All they need to know is how to work with Graph.
This information is great.
>> Awesome.
>> As you can tell, with this information,
I can go ahead and call Bing API or
any other API that will give me a time zone.
For here we have a function called get time-zone information and
all what we are doing here is passing
the location information of the users.
If you're going to peek into this function,
you can see here exactly what we are doing.
We are using the Bing REST API and passing all that information as
a query and we're also passing at the Bing Maps API key,
which is a configuration that you want to add
into your ENV fault, which is right here.
I'll open up the sample.
This is how your configuration would look
like and this is where your API key is.
>> Okay.
>> That's all what we have done and we get the time zone.
This, I think, it's pretty brilliant idea
and it should be there in every application possible.
If you can see the times zones we be our users, great.
I don't have to second guess when you're going to wake up,
when you're going to be replying to my pings. This is it.
>> You're absolutely right.
>> Let's go ahead and find out in our browser.
Awesome. That's how it looks.
You have your colleague information,
at the same time, you have their time information,
you have their time zone and where they are from.
I think this is an icebreaker in itself.
I know these people are in this location,
in this time zone, when I'm booking a meeting next.
>> That's really cool. The only thing
that could possibly be cooler
would be if we could see all of these people as points on a map.
>> Well, you guessed it right, it's because we have it.
>> There it is. Amazing. Okay, there we are.
Wow, this is great.
>> Because anywhere we're using the Bing API,
we might as well just indulge with more map functionality,
but all thanks to Graph for giving me the location information.
We've got all the pins here.
This exactly look like how our colleagues are distributed.
We've got Australia, we've got Europe, we've got America.
The good thing is you could even
see where they are based on each user.
As you saw earlier, you could select
and see information per colleague,
you could also see where they are in the map.
>> Nice. It looks like you're also pulling in
some other information about the user. That's really nice.
>> This section that you see here is
the About Me of your colleague.
It's a good way to get to know what they work on,
what their hobbies are,
maybe, the kind of projects they are passionate about.
All this information is right here as well,
again, coming from Graph.
Let's go back and see how that works in the code.
Here in the information that we're pulling out for our colleagues,
you might have noticed we don't have About Me.
Not every endpoint has all the information.
Like we discussed before,
they're all distributed in graph.
We have something called
the profile information that we're getting here.
The profile information would give you the About Me.
That is basically just about the user.
Again, some information are duplicated here, but not all.
What you saw in the direct reports API,
we have much more information that you can show from a user.
That is this About Me information.
That is being pulled out and being displayed
under each of these colleagues,
which you are seeing here.
>> That's really cool. This is starting to look really good,
like we could actually use this thing.
I think this is really cool how this whole thing
is built up right here in this single-page app.
Is that it?
The graph is good for single-page apps, right?
Is there other scenarios where it could be useful?
I think there are other SDKs, right?
Anything that could call a rest call could call the graph.
But what if I'm writing an Android app, or an iOS app,
or universal Windows app,
or even a bot,
would the graph work from most places as well?
>> Absolutely.
For that reason, let's go to a bot.
We had a hack week previously, a couple of weeks back,
and we built a bot,
which basically is very similar to this SPA application.
It's around you as a person.
But here, you can see it's more about your colleagues, as well.
But what if you want to create a personal assistant bot?
Anytime I think about a bot functionality,
is mostly to assist a user to do something.
In our case, let's see a bot working who
is going to get me the same information but around me,
around my events or my files.
Again, the similar kind of an application but as a bot.
So what I'm going to do now is jump to a Bot Composer.
We've built this Personal Assistant bot
using the Bot Framework Composer.
It connects to Graph and gets information from Graph.
I'll show you how it works in a minute,
but let me explain to you a few things that you probably are
curious on how to call Graph in a Bot Composer.
Away from the JavaScript application,
how would you do it in a different scene?
Here, we have something called a dialogue.
In Bot Composers, you can have actions,
you can get information,
you can give response back to the user, etc.
Here, we are using a few things like the auth,
that's the most important bit you need to connect to Graph.
>> Yeah. Just like [inaudible] showed earlier,
actually, authenticating to the single-page app in JavaScript,
is this the same thing in the bot?
> Yes. That's the same thing.
All you're doing is logging in, getting the token.
Token is what you need to make another API request for Graph.
This action in the Bot Composer would do exactly that.
>> Got it.
>> All you need is a connection.
Once you have a connection in Graph set up,
we've already set this up in the Bot Composer
and we're just using the connection here,
and once that is done, the user will get
the same button that you saw in the JavaScript application,
then you go ahead and sign in.
Once signed in, once this connection
is successful, you get the token.
Once you have the token,
you just need to make the same call that you
saw earlier in the files session.
You saw the trending files,
it's using the insights workload.
With the same call and with the authorization token,
we're going to make another call to Graph.
It's basically all around you knowing how to make Graph calls.
You can build any kind of application that
can go ahead and talk to
Graph and get the information from Microsoft 365.
Let's see how this works in action.
What I'm going to do now is start the bot.
I already have another tool as well for demo purposes.
It's called a Bot Emulator,
basically like a simulator for bots.
I don't have to host it anywhere.
I can just open up and see how it works.
I'm going to start the bot and I'm going to
show you the emulator where this works.
Yes, so we got the bot running.
Now let's go ahead and test it in the Emulator.
I'm opening up the tool that I just talked to
you about before. Click on that.
This is the Emulator and it's starting the conversation.
It's connecting to the bot now,
which is running in this local host.
All right. Here it is, our personal assistant bot.
It says, "Howdy, what can I do for you?"
>> Nice.
>> What I want to see is what's up?
What's trending? What's happening?
I'm just going to click here,
which basically goes off and kick off
that authentication dialog that we saw earlier,
which will go ahead and give me the "Sign In" button.
It's very similar to the SPA application that we saw earlier,
I'm going to go ahead and sign-in.
This will do all the auth and give the token back to the bot,
and with that bot,
we'll go ahead and process the Graph call that we saw
earlier for getting the trending files.
You can see here the trace of
all the network that's happening here,
the calls being made to Graph,
what's being retrieved,
all this information is in the trace of the emulator.
>> Nice.
>> That's probably the reason why we chose this
to show you that they're the same calls that you saw earlier.
For example, if I open this trace,
you can see here the Graph call for trending,
and that's exactly what you're seeing here, insights and trending.
It's the same Graph call that we made earlier.
We have all the trending files shown by the bot.
If you go back to the application,
you can see here that the trending files that
you saw in the SPA application
is the same list that's being given to you.
It's the same call, but in a different setup,
in a bot that we created using the Bot Composer.
>> That's really cool, I love it.
I could be asking this bot for my phone or something,
maybe I didn't want to run the whole app and everything.
A quick question about this.
I noticed that the "Login" button
is in both the single-page app and the bot,
and it makes sense while we're testing here
that you're logging in maybe with different users.
If we actually built a production app,
say, it was running in Microsoft Teams,
which is where people are collaborating a lot,
would it be necessary to have
that "Login" button every time they use the app?
>> Yeah. For this bot,
it would mean that if it's the same user who's
signing in after they've already signed in successfully,
it would be there for a time period, maybe a six months.
If this bot is in the Teams application,
if you upload into Teams,
then it would mean that it's the same.
It's for that period of time,
you don't have to re-sign in if you're the same user,
or signed in successfully.
For tabs in Teams,
there is SSO available at the moment just with tabs,
which is pretty awesome.
It's in Developer Preview at the moment,
but yeah, it's there.
These options are there for you to make it easier for
the users to not keep on logging in to your application.
>> All right. Well thanks,
Robbie, this has been really, really interesting.
I love how you combined
another Cloud service in with the Microsoft Graph.
Presumably, I think a lot of developers, of course,
their app is going to do more things
than just show information from the Graph,
but they can combine,
just like you combined the Bing information
with the Graph information,
they can combine their own apps in with
the Graph and just provide the information that users need to see,
rather than asking them to
navigate to different places
to pull together the information in there.
>> Yes, it is.
My favorite part is the time zone,
I'm still hung up on that.
>> Thanks, [inaudible] , and thanks, everyone for joining.
I'll turn it back over to the main program already in progress.