>> Cool. We have just seen
how we can use the Microsoft Graph and Microsoft 365
to build a simple app that helps us to
stay in touch with everything that's going on around us.
We have shown a list of our colleagues,
their pictures, their job titles.
We also have shown our events in calendar.
But there are also so many more insights
that are available in Microsoft
365 and that we can also show through the Microsoft Graph.
First things first Bob, we show a lot of stuff on the screen.
Is there maybe a way for us to filter it?
Because imagine that it's a lot of meetings,
but I want to reach out to,
let's say Adele. Shall I do it
directly or maybe I have
an upcoming meeting with her anyway that I could use then.
Is there an easy way for us to be able
to only show info about a person?
>> Yeah, that's a great idea.
So I think we need to add a little simple navigation
to the app to make that happen.
Let's go in and add a little bit of code.
Here we're adding just a couple of little navigation methods
to get select a user when they click and somebody clicks it,
and then to get back that user ID when we render.
The result then is almost the same,
except for when we click on something,
it actually goes in and filters the calendar,
as well as, as we add more things to the screen,
we can filter those as well.
Notice that it's putting the user ID up here,
which is just a little single-page app.
We're trying to keep it simple here.
We're not using any fancy frameworks or anything like that.
I guess what's interesting really, especially here,
is filtering the events so that
we're only going to see things where Adele,
in this case is in the meeting with Megan,
who is the user I'm logged in as.
If we come in here and look at the events code,
you'll see that this is
the calendar view that you talked about earlier with Rob.
Here, we're just saying if a user is selected,
then we're going to go ahead and filter down those meetings.
If the graph could filter on a meeting attendees,
it can filter on a lot,
but not a hundred percent.
If it could filter on meeting attendees it would be better to do
that on the server side or up in the Cloud.
But in this case it can't.
I'm just going to do the filter here in
JavaScript and I think for the case of meetings,
that's probably fine because there's not a huge number of them.
>> Yeah. Also, I guess another thing is
that if we show all meetings initially,
we have them already.
Imagine that at some point we would add cash to our app.
Then we have the data,
everything that we need to show already locally,
and then we can just filter a collection, right?
>> Yeah, that's a good point. I think we can
probably optimize this app by caching some of the data.
Again, we don't want to confuse
the audience with it right now because
it's not graph specifically.
But it's still something that we could add at some point.
That's a really good point.
>> Now I can more easily see
events that I have around a person and
we can still see our colleagues.
One thing that would be also nice to have in the same place,
I would find really cool to have
my unread e-mails in here so I can more easily see,
what is on my plate and is there something that I need to act on
again around these folks or just in coming days.
Is there a way for us to also show my unread e-mails in here?
>> Yeah, absolutely. That's just another piece of the graph.
I'm going to go back to Graph Explorer here because I really
think that this is where
I always start is to see what calls can I do
and map my path between the notes, like you were saying.
It looks like my mail is right here.
That's it, it's really easy to get the mail.
I think that the tricky thing is first of all,
I'm going to want to filter this.
I probably only want to see unread mail.
Because if I've already read it,
why do I need this app to see it again.
It turns out that Microsoft Graph uses a standard called OData.
It's a way of handling tables of data or collections of data,
create, read, update, and delete.
It's really great that they stuck with a standard
instead of inventing that different for everything.
The OData spec says that the way to filter
is to put dollar filter on the end.
Here, if I was to look into the data,
I would see is red.
Right here is true.
I only want to see where is red is false.
Now I can run this and you'll see that it's actually going to
filter out and only show me the ones where is red is false.
>> Nice.
>> Now let's go back over to the app
and I'm going to flip it again.
We're using these branches because we really don't want to.
>> Type?
>> Nobody likes to watch me type.
There's the e-mails, it's coming in.
The next thing I think that we probably want to do,
though is what do you want to have happen if
I click on Adele for instance?
>> Yeah, exactly. I could just show e-mails from her.
>> From Adele.
>> Like if I have,
for example, a meeting upcoming,
I can also see,
maybe she reached out to me about something.
Maybe there's something that we need to still think about.
It'll be good to have the same filter in place for e-mails.
>> Yeah, I agree. You can see it's working here in the code,
but before I show the code,
let me just show the rest of the filter.
If we go down here in the data,
you'll see that I've got a from and I've got a sender.
Here's sender, e-mail address, address.
You can actually navigate down into that structure in your filter.
Let me add to the filter here.
I'm going to put and, first of all,
>> Right.
>> and sender slash e-mail address slash address equals Adele.
Now I will get back only the e-mails from Adele.
That's how this code is working and I really like the way
the code is laid out because what it's doing is it's saying,
"Okay, me slash messages."
Next thing it's doing, it's a little bit fancier.
It's doing select.
This would turn into dollar select in OData.
But this is just a nicer format for JavaScript.
It's only going to get the data that we need to show.
Then we're only going to get the top five.
You can page through data in
almost every graph call by doing dot top or
dollar top in the rest call
and dollar skip to skip down to the next page.
We only want really the first five.
Because if it's anything like my inbox,
it's going to feel like the entire script.
>> Yeah, exactly
>> Then it's going to say,
well, is red is false.
Then if I'm filtering because I've selected some user ID,
then what I'm going to do is add
this end clause here to the filter.
Again, then we get this nice result that now it
filters based on whoever I didn't get any e-mails from Christine.
I get this one from Isaiah.
I get these ones from Adele, etc.
One thing that's nice about this filtering,
Some of these people don't send me a lot of e-mail.
One thing that's nice about this filtering is with the dot top,
if we did the filtering in our JavaScript,
we would only see
the top five minus ones that were from other senders.
We might not see any e-mails at all
unless one of these mails happened to fall in the top five.
By having graph do the filtering,
we're actually taking the top five after the filter was applied.
>> Yeah, and there was also a cool thing in your code where you
split the call to graph basically in two around filter.
The one that I see there is that if we have selected user ID,
we need to get their e-mails to match sender.
We only load user's e-mail if there is one,
so we don't do it always.
We basically optimize this.
>> Yeah, that's a good point.
Just as you can chain
the functions like dot top could call dot filter dot get,
you can also just store in a variable
your query and then keep
building it up and building it up in your code.
Then as long at the end you put the get or
the post or whatever the HTTP verb is.
>> You can structure your code however you want.
I really like that too.
>> All right. Now we have my calendar,
my events, my e-mails.
Now, I don't know about you,
but one thing that I struggle with all the time is my files,
getting back to my files or trying to find, in our team,
what are the files that we're working
currently on so that we can really easily get back to them.
Is there something in Graph that could
allow us to simplify that, perhaps?
>> There is. Let me show the code first,
actually there is, and it's called insights.
This is one of the cool things about the Graph,
you've got this layer in the middle of
the architecture where all the calls are coming through.
This has a number of architectural advantages.
A good one is just that our program here
doesn't have to talk to five different services,
authenticate five times, do five DNS lookups.
Everything is all going through this one common endpoint,
so that actually makes our performance and our code much faster.
But another advantage is that once that layer is in the middle,
it can actually start to look
across the different work that people are doing.
Have you ever noticed it
probably before you went to Microsoft 365,
if you're not an M365 user,
you would notice you work on
a file and then you go to send it to somebody,
and then you have to go find the file
again to attach it to the message?
It's so annoying, right?
>> Every time. Then you need to know
the hierarchy of folders, where did you put it?
If it's the final final of the final V2.
>> Exactly. I think that's
part of the problem of application switching.
We were always trying to avoid people switching apps.
It's not just the switching,
it's the fact that you have to navigate
the information again every time.
That's a real pain in the neck.
The Graph is sitting there watching all these requests,
and if you've noticed lately,
you go to send a message and the file that you just finished
editing is the first one that it suggests when you attach it.
I love that. It saves me so much time.
The way that works is it's using this insights part of
the Graph where every time you make a call,
it's actually sending signals into the Graph that
learn about what is important to you and what you're working on,
so that even if you're in one program like Microsoft Word,
and then later you go to another program
like Microsoft Teams to access a file,
the Graph is a common place
in-between that is going to remember, yeah,
but he just edited that file in Word three seconds ago,
probably that's the file he's going to want to share.
We're using that here, insights trending.
We're going to get the trending files,
which is, there's other ones,
there's a recently modified and other trending aspects.
But this one or other insight aspects.
But trending is a little bit fuzzier,
it's what's relevant to me.
It's going to take all my usage into account.
If I just edited a file once recently,
but edited another file 100 times,
it's probably going to rank that 100 times
more because it knows the overall traffic.
It's going to actually come in here and grab
the trending files and filter them down to
only the drive items because there are other things I might find,
like I might find a trending SharePoint site
or some other piece of information.
I only want the files.
Then actually the thing is that Insights
doesn't actually provide complete information about the file.
What I really want to do is
get all of the information about that file,
and that's going to require another call.
The nice thing is that
the Insights API provides me with that exact call.
All I have to do is look at resourceReference.id and I actually
get the path all the way to the file, wherever it is.
I can just do a get request with that.
What you'll notice is because I started with one call trending,
now I'm getting five responses back.
I really didn't want to go and one at a time, ask,
give me the data about the first file,
give me the data about the second file,
give me the data about the third file.
It'll be much better to do one call to Graph and get it all back.
This shows off another cool feature in Graph.
It's also part of the SDK.
We're going to actually batch these and
put this all into one HTTP request.
What this is doing here is building up an array of
batch requests and then sending the whole thing off in a post.
Here's an example of a post instead of a get.
Then what comes back,
there's going to be a matching response.
Instead of getting back one HTTP response,
I'm going to get one HTTP response,
but instead of getting one of my operations back,
I'm going to get an array.
Again, that I can just go and
correlate my requests to the responses.
The result is [inaudible]
>> Exactly. That's it in action.
>> There we go. Now I can see all of my files.
One of the nice things by the way,
about storing the files in the Microsoft 365,
if I click on this file, it opens.
Now, that may not seem like a big deal,
but it's actually a pretty big deal.
>> It is.
>> Because I've got Microsoft Excel,
Word, PowerPoint, and all of those programs that people
use frequently are built right into the system.
I don't have to go and implement that or try to make
a bridge between my app and these online tools.
The user already is using them.
They're already there, just use them.
One other thing I wanted to quickly point out is what
happens if I filter the trending.
If I actually click on, say,
"Adele," I'm actually going to see
the files that are trending for Adele.
This really gives me an insight into what she's
working on because I might have certain meetings with her.
It might be some tiny little part of her job.
Here, I'm going to see all of the files that she's working on.
I can see here that she's working on a buyer brochure
or at least interested in
this buyer brochure or this product road map.
Now, it might seem a little bit scary to do that,
but the Graph is enforcing security.
If her most trending file
was a confidential document or something I don't have access,
it will automatically be removed from the list.
Again, there's no change in the code.
All it's doing is instead of starting with
/me/insightstrending, it's taking /userid/insights/trending.
Now, I can get back the trending documents for
all these different users and see what they're working on.
>> All right. We have seen going all the way from a person filter
filtering events so that we can more easily see
what events we have with others in our team.
We have seen how we can show my unread e-mails.
We have seen trending files.
I guess, it is a lot already.
For now, we'll wrap it up.
But in the next segment we will finalize the app,
add a few more things,
and also show you some other application scenarios
to use the Microsoft Graph. See you.