Tip:
Highlight text to annotate it
X
VIC FRYZEL: Welcome to Google I/O, and thank you for coming
to this talk.
Today, what I'm going to be doing is introducing a new way
to administer your business on Google, specifically with
Google Apps.
So just a quick poll.
How many people in the room are familiar with Google Apps
and the Admin APIs?
Everyone.
OK, you're in the right room.
So the Admin APIs are a set of APIs that allow you to manage
your Google Apps for Business domain or other additions, and
do things like create users and manage your domain's
resources while also making it easier to perform some
automated tasks.
So this is a collection of more than 15 APIs.
It includes things today like the Provisioning API, or the
Group Settings API, or the Reports API, et cetera.
So the problem with this is that thousands of applications
use these APIs every single day.
There's a large number of these APIs, but the developer
experience of the APIs can be a little bit
difficult to navigate.
So if you break this down, actually, this translates into
more than 125 million requests per day.
That's more than a lot of small companies get for their
entire app.
So here, these requests coming in are doing things to manage
Google Apps for Business domains.
What we're going to talk about today is
making things even easier.
And if there's one thing that you leave the room with today,
it should be with an understanding that you should
go home, sleep, after Google I/O, and then come into work
the next day and adopt what we're about to launch, because
we're going to make your lives significantly easier.
So this is directly for IT admins.
Or if you're an ISV who's developing software for users
of Google Apps for Business, if you're a reseller of Google
Apps for Business, all of this stuff is
going to apply to you.
So we've, over the years, taken a lot of requests from
developers.
So the Google Apps Admin APIs are actually one of our oldest
sets of APIs.
I've worked at Google for almost four years, and I've
worked on them since my first day at Google, and then even
before that, they existed.
So we've gotten a lot of requests from developers over
the years, and today, we're going to
address some of those.
One of the top requests was the ability to search and sort
your result sets just much more easily from things in
your domain.
Another one is batch requests.
I need to, for instance, create a bunch of users at
once or get a whole bunch of information about a collection
of users at the same time.
Enterprise attributes.
And then more customizable reporting.
And then finally, I think the biggest request has been for
functional parity with the admin panel for Google Apps
for Business.
So here, we have my friend Namrata.
This is all of her information in my test domain.
And you can see there's a whole bunch of information
here that is pretty common.
This represents Namrata in a traditional business
environment.
So I have things here like her phone number, her email
addresses, which groups she belongs to, and also her
username and profile photo.
So today, there's a problem and the problem is that to get
her profile photo, I have to make a call out to the
Profiles API.
And then to get her username and other user information, I
have to make a call out to the Provisioning API.
Yet another API call, at least, to get things like her
nickname or her aliases, and then yet a fourth request to
get the groups to which she belongs.
So this is a little bit too much.
And just a quick show of hands, how many people in the
room have run into things like this?
Almost everybody raises their hands.
OK, so I have good news for you.
Today, we're launching the Admin SDK.
And the Admin SDK is a brand new developer experience
around managing things in your Google Apps
for Business domain.
What we're going to do is talk about how we're going to
simplify the developer experience, and I'm going to
introduce a few new APIs to you.
And I think what you're going to love about this is how easy
it is to integrate, and also how easy it is to do more
advanced things in your domain.
So we're launching two APIs today.
The first one is the Directory API, and the next one is the
Reports API.
I'm going to go through each one.
The goal of the two APIs is to be as simple as possible,
giving you all of the data you need and all of the actions
you need while getting out of your way.
Consistent, so what we want to do here is make sure that all
of our API surface areas look identical so that you don't
have to do special tweaks or integrations between multiple
APIs in order to get things working.
And then lastly, comprehensive.
We want to expose as much of the functionality in the
Google Apps Admin Panel as possible.
So when you come away today, know that these are our goals,
overall, for the platform.
So the Directory API allows you to manage
objects in your domain.
So this includes the traditional objects like
users, groups, and org units.
However today, the Directory API will also allow you to
manage devices in your domain.
So to give you some sense of what's going on here, here I
have a bunch of common endpoints that you would use
today for things like the Provisioning API or the
Profiles API.
And what we're going to do is boil all of these things down
into a single API called the Directory API.
And here you can see all of those endpoints, they
roll up into one.
So this is going towards the simplicity goal that we have
for the Admin SDK.
The next one is the Reports API.
So the Reports API is going to allow you to create just
richer reports on things going on within your domain.
Here, you can see this graph was able to be generated with
all of the data coming back, and this is just usage
activity of each service within your domain.
Another way to generate a report is just all of the
different activities going on within your domain so that you
can, much more easily, do things
like audits, for instance.
So let's take a demo.
So Ankur in the audience wrote this demo app.
It's called Device Explorer, and this is
doing something new.
So a few important points about this application are
that it's hosted on App Engine, so it's a third-party
application, and it's using everything that I just talked
about to allow you to manage devices within a Google Apps
for Business domain.
Ankur did a few special things.
One, he allowed his admin to log in with Google+ Sign In,
which is a new mechanism for signing users into your
applications, and you can use that with Google Apps for
Business domains.
So that's definitely something that you should consider
changing your application to use.
It's just a lot easier to implement.
And also, it allows you to get all of the same access that
you have with your application today.
The next thing is he used the Directory API to create a
Device Explorer here.
And this Device Explorer allows you to manage devices
within your domain.
So here, for example, if I click on this device, this is
all of the information about the owner of this device.
And if I go back, if I click on the device itself, you can
see all of the information about the device.
So this is important because on occasion, what will happen
is one of your users may register a non-approved device
on your domain or somebody would lose their device--
maybe leave it on a train or something to that effect.
And what you as the admin have to do is be able to disable
this device quickly and easily.
Now, it really gets a lot easier to do mass changes with
tools like this.
So obviously, in your own business or in your own
software, you may need to do some advanced things like
provision 1,000 devices, and that's not something you want
somebody clicking around and doing manually.
So that's where the Directory API really shines.
It allows your application to do more advanced concepts.
So here, just to take a simple example, what I can do is
select this device from Ken, and I can do various things.
Its current status is Approved, but I can also block
it or delete it.
So if I block it and take this action, it says Done.
And if I reload the page, you can see, after the Wi-Fi
cooperates, that the device from Ken is now blocked, and
this has also been applied in the Google Apps Admin Panel.
So this is one of the new features
we're launching today.
And this demo application is one way to kind of see what's
going on there.
So if I come back to the presentation, the next thing
we're going to do is walk through the code that made
that application possible.
So just to give you an idea of how the code is structured,
it's a very common model view controller set up.
Here, the servlets act as controllers, and the view is
index.html.
That's really just a template.
And then we have our servlets talk to the client library.
Our data model here is completely represented by the
Directory API.
So that's important to note.
We don't really have a local data model.
So the first thing we're going to do is query mobile devices
in the domain.
So here, you can see a method on the devices servlet to do
that, and you can see actually how simple it is.
So here, just with four lines of code, I'm able to get a
list of devices within the domain and then print them to
the screen.
This is one of the ways that we're really trying to address
that simplicity factor again.
Just making it easier for you to get the data that you need
out of your Google Apps domain.
The next thing we can do is query for individual devices,
and then just return the list.
So the previous method just printed a list, and here, we
actually get the list of devices themselves.
And then we can also get matching devices with a query.
So I don't know if you noticed this in the sample
application, but there was a search mechanism.
And I can apply that search mechanism here.
In case I have thousands of devices in my domain, I don't
have to find each one by scrolling
through hundreds of pages.
That add row to device table method is really just a view
generator method that creates a table row with the device's
information.
And then taking action on a device.
For instance, I blocked a device.
You can see how that's done here via
this take action method.
So the take action method is really just a wrapper around
these five lines of code.
So these five lines of code create a new directory object,
which allows you to interact with the Directory API.
And then a mobile device action, I which create a new
action object that I want to set.
In this case, it might be block.
And that action parameter is just a string representing the
action's name.
And then I set up the request, and I call Execute.
And once I call Execute, this makes a request out to the API
and blocks the device.
So one thing that we've noticed is that an easy way
for us to guarantee that there is feature parity between the
Google Apps user interface and the Admin SDK is to use our
own Admin SDK to build the Google Apps interface.
So what does that mean?
Well, I'm going to switch over here to my demo tablet.
And this is something launching towards
the end of the month.
It's a mobile C panel.
So this mobile C panel allows me to manage my users and
groups and other domain resources while on the go.
So this works on my phone or on my tablet, and this is
something that Google is going to release.
The important thing to note about this entire application
is it's built using our Admin SDK, so we're
eating our own dog food.
We know that the Admin SDK works and works well, because
we have to use it as well.
So here if I click Users, you can see all of
the users in my domain.
And if I click Ankur, I can find out more information
about Ankur.
So here, I can do other things, like I can edit
Ankur's information.
So I could change his name, I could change his email
address, or change his phone number.
I could add a new phone number.
I'll just punch in a random phone number here, click Done,
and OK, and it updated the user on the spot.
So what that just did was make a call out to the Admin SDK
and save that new phone number.
If I come back, click Done, I can do other things.
I can also suspend the user or delete the user.
And then if I come back to this menu, I can also do other
things like manage groups.
So if I look at the All Managers @ACME Group, here you
can see this admin@ankurt10sep is one of the users, but I've
decided that I want to make this user an
owner of this group.
So I edit the role, and I click Owner, and I click Save.
And when I click Save, Ankur is now an owner of this group.
So you can see there, using this app that we've built,
we're actually using a lot of the features that you would
have to use in order to build your own applications with
maybe more advanced use cases.
So this is something that's becoming super important to us
and it's a goal for us in the long term.
And I really want to sell that point because I realize that
previously, there has been somewhat of a disconnect
between the Google Apps Admin UI and what was available to
do via the API.
And this is something that we're really keen on
addressing.
I know that a lot of you in the audience need to do some
edge case that the UI allows and the API doesn't.
And so what you have to tell your users is, oh, by the way,
you can't do that in my tool.
You have to go to the Apps Admin UI.
We are addressing that point directly.
So in the coming months, you'll start to see that get
better and better and better.
So what's next?
The next things that we have going on are essentially
improving the developer experience across the board.
So here, in the documentation--
forgive me.
Let me switch my screen.
Pretty noob mistake right there.
So let me show you the documentation here.
This is how it looks today, and you can see that huge list
of APIs I mentioned previously.
And it's also kind of difficult to find out what you
need to do in order to address your use case.
Today, we're launching this, and it's our new developer
experience for the Admin SDK.
So here you can see, we've moved to more documenting the
use cases and not so much documenting individual APIs.
So if you need to manage users, for instance, or if
you're new to the Admin SDK, you probably don't really care
that that's the Directory API.
Rather, you just want to see how to do it and then later
on, you'll start to learn our own terminology as you become
more and more of an expert.
So we're working on making it easier for new users of the
Admin SDK while also keep keeping it as good reference
material for advanced users.
And we're also working on keeping it very up-to-date
when we add new features to the Admin SDK.
So in making integration easier, again, we're working
on reproducing the simplicity and consistency of the two
APIs, both Directory and Reporting, into other APIs
that will be a part of the Admin SDK.
And we're also looking at giving more feature complete
sample applications in a broad range of languages.
What's important to note is that these two new APIs are on
our new API infrastructure at Google.
You'll know that some of the previous APIs have been on
this thing called G Data, and G Data had custom client
libraries for every single API.
Whereas with the new API infrastructure, the client
libraries are consistently kept up-to-date in a more
automated way so that, for instance, the Java client
library, if you download the latest version, you will
immediately have access to the latest features of the API.
There's no delay there.
The other thing, again, that we're really focusing on is
continued feature parity with Google UX.
And we're starting to do this by developing the applications
for Google using our APIs first and then
adding features second.
So with that, the upcoming features.
We're going to add more enterprise objects in the API.
We know this is a huge feature request, and we're working on
making the availability of data just much wider.
We're also working on giving powerful structured search.
The worst thing on the planet that I'm sure everybody in the
room has encountered is having to fetch a full list of
resources and then manually search them
yourself, and that sucks.
So we're working on making that just a lot better so that
you don't have to do a lot of that processing on your end.
Also, we're giving an extensible user schema--
and this is a big one-- so that you can set more and more
properties on a per user basis so that you don't have to have
a separate data store for some properties about your users
and then use Google Apps for the other properties.
We're going to give you a login activity audit.
Again, I think this has been a pretty
popular feature request--
the ability to just detect logins from users.
And then lastly, we're going to give G+ reports and let you
find out exactly how your users are
interacting with Google+.
So with that, thank you.
And what I'd like to do now is take questions.
There's two microphones.
[APPLAUSE]
AUDIENCE: Hey Vic.
It's Charlie Wood.
A couple of questions.
First of all, I know there was talk about push notifications
in at least some of these APIs.
Is that included?
Is it roadmap?
VIC FRYZEL: That's in the roadmap.
AUDIENCE: Second, what is the process, or is there a
process, for increasing API quotas?
VIC FRYZEL: So that's a very good question.
So these two new APIs are managed in the Google APIs
Console, which I didn't show.
If you've used any other Google API really, I'm sure
you're familiar with the Google APIs Console.
When you go there, there is, as of today, this new option
called Admin SDK.
And when you can flip Admin SDK on and off, you can also
request more quota.
And what that does is it sends an automated item into our
system and then we review it each week.
And then that would allow you to get more quota.
AUDIENCE: And then finally, this is kind of a detail, but
when you're fetching a long list and you're paging 100
results at a time, did it make it in to where the total
number of requests and the total result set is actually
in each page?
VIC FRYZEL: You mean the result size, like the total
number of users in each page?
AUDIENCE: Yeah.
VIC FRYZEL: Yeah, that made it in.
AUDIENCE: All right.
Thanks.
VIC FRYZEL: I'll take one from the back.
AUDIENCE: Yeah.
My name's Scott Howell.
I'm curious about the Google Sign In for external websites
and how this Admin SDK--
can you assign different levels of rights to those
users for those external sites, ie, say I have, I don't
know, 500 users in my Google domain and I want to give them
access to an external website, can I manage those user levels
through this?
VIC FRYZEL: So you mean access to use Google+ Sign In on
another website?
AUDIENCE: On an external website not part of--
VIC FRYZEL: I'm with you.
AUDIENCE: Not a Google App.
VIC FRYZEL: So currently, you can't manage that per
application basis.
What you can do is revoke access
after it's been granted.
And what we're working on is making it so that you can
control individual access.
Let's hypothetically say that you wanted to add an
application to all of your users, and you want to give
them access to that application specifically, but
not to all of the other applications on the web,
that's something that we're working on.
AUDIENCE: OK.
Great.
Thank you.
AUDIENCE: Hi.
I'm [INAUDIBLE] from Sears.
The question that I had is when you are trying to add the
objects, do have the ability to maintain the history of the
changes that have been done on the user profiles?
Like for example, my phone number was XYZ.
Phone number now is ABC.
Can I track the XYZ as well?
VIC FRYZEL: Yeah, so that's part of this new SDK as well.
AUDIENCE: Sure.
Thanks.
VIC FRYZEL: Thank you.
AUDIENCE: Is this new API going to be available, or is
it available already, for Google Apps Script?
VIC FRYZEL: For Google Apps Script?
AUDIENCE: Yeah.
VIC FRYZEL: So the existing apps interface exists already
on Apps Script, and what we're working on is updating it to
use the new SDK.
I don't have a timeline for you, but it should be soon.
Hi.
AUDIENCE: Hi.
This is [INAUDIBLE]
from SAP.
We had an example of device management with a device
approved and rejected.
What are the plans for Google regarding remote device
management?
VIC FRYZEL: Remote device management?
AUDIENCE: Yes.
For example, when the company has a set of employees with
mobile devices, does Google have plans to set up more
capabilities to manage maybe remote device wipe or those
type of features?
VIC FRYZEL: So what we have today is the ability to
install an application on your device that lets you know the
state of the device remotely.
However, I don't have anything to announce today about our
plans there in the longer term.
Thanks.
AUDIENCE: Thank you.
AUDIENCE: Hi.
My name's Raoul.
I have two questions.
One, any update on auto sign out or time
out for Google Apps?
Or if a user is signed in and he is not active for 30
minutes, is there something which we can trigger that will
sign him out of the session?
That's one.
And second question is, though there is an audit trail which
you have started on Google Docs, does it cover the
external files also which we upload?
VIC FRYZEL: The external files that you upload?
AUDIENCE: Yeah.
VIC FRYZEL: Both of your questions I think I have a
solution to, but they're a little bit more advanced.
Come find me afterward, and I'd be
happy to walk you through.
AUDIENCE: Sure.
Thanks.
AUDIENCE: Hi.
I'm Jeff Williams from the University of Minnesota.
At the University of Minnesota, we have five
different domains that are each with a different account
and they're not merged together.
Is there any way that we could leave the data in place but
have you update the metadata to consolidate the domains so
that we have a single human domain instead of having five
separate domains?
VIC FRYZEL: A single domain instead of five separate.
So you want to merge the domains
without merging the domains?
AUDIENCE: We want to merge them, but we don't want to
copy all of the data that's in there back to our servers and
lose fidelity, and then copy it back to your servers again.
Because why?
You've got all of the documents for all of the
different campuses, so if we could log in as admin on the
source and the destination domain, we might be able to
migrate the users over by just updating on your side the
metadata that describes the access permissions that they
have to the various pieces.
VIC FRYZEL: That's a really good feature request.
Come find me afterward, and I'd like to take some
requirements about that, and then I could make sure that
that lands.
AUDIENCE: Frank LoCascio, Esource Capital,
a Google Apps reseller.
On the APIs, is there going to be work done on the APIs that
go after the data in the reseller console?
VIC FRYZEL: Are there any APIs that what?
AUDIENCE: Go after the data in the reseller console.
VIC FRYZEL: We do have a set of APIs for this.
Come find me afterward, and I can point you
in the right direction.
AUDIENCE: OK, and a little bit different than APIs, another
quick question.
Will there ever be the ability to change the primary domain?
VIC FRYZEL: Change the primary domain?
I don't think so.
AUDIENCE: We have companies changing
their names, and it's--
VIC FRYZEL: Yeah, freaking companies, man.
[LAUGHTER]
VIC FRYZEL: Hey.
AUDIENCE: Hi there.
I'm Chris.
I'm with June Star.
I support maybe 12, 15 companies in Google Apps, and
depending on when they were deployed, I have to juggle two
different admin consoles, resort to GAM to get a lot of
stuff done that I can't get done through
various ones of those.
And keeping track of who's on where and who knows what is a
bit of a hassle.
Is this going to supplant all of that juggling, or?
VIC FRYZEL: It's going to definitely make a lot better.
Do you develop your own applications?
AUDIENCE: As little as I can, but I do have to
do some of it sometimes.
VIC FRYZEL: Two things I would say.
One is that we're working on making the admin panel just
more robust.
I'm sure there are certain edge cases that you're having
trouble telling your users to do, and that's where your
application comes into play.
I'm not sure specifically in your case what
those edge cases are.
I'd be happy to discuss them on a one by one basis.
But we're working on making the admin panel just more
robust so that you can do more of these things.
The other thing I would say is that as we're working to hit
feature parity between the Admin SDK and the Admin UI,
everything that you can do in the UI, you'll be able to do
in the SDK.
So in those cases in which you're sending a user just to
the admin panel to do one thing and then to your
software to do something else, they could eventually have one
destination.
It's either going to be in the admin panel
itself or in your software.
So come find me afterward.
I'd be happy to talk about your specific edge cases.
AUDIENCE: Thank you.
VIC FRYZEL: Thanks.
Hey.
AUDIENCE: Hi.
Miguel from the [INAUDIBLE] company.
Does this Admin SDK plan to have PKI
management at one point?
VIC FRYZEL: I didn't hear the last part, sorry.
AUDIENCE: PKI.
VIC FRYZEL: Can you--
AUDIENCE: PKI, certificate management.
VIC FRYZEL: Sorry.
I totally did not get your abbreviation.
Public Key Management?
AUDIENCE: Yes.
VIC FRYZEL: I don't think that we have
that in the near future.
I would say that that's a really good feature request.
The entire product team for the Admin SDK is in this room,
so they're hearing everything that you say.
[LAUGHTER]
AUDIENCE: Thank you.
VIC FRYZEL: Hey.
AUDIENCE: So I wanted to plus one Charlie's request for the
push notifications and the change feed for the--
VIC FRYZEL: Absolutely.
That's definitely in the pipeline.
AUDIENCE: And also, the [? three LO ?], understanding
what's been authorized by someone within the domain.
VIC FRYZEL: Understanding what's been authorized by
somebody in the domain?
AUDIENCE: Someone approves certain requests in the
marketplace, someone within your domain, so just to know
what has been approved by which users within the domain.
VIC FRYZEL: Got it.
That's something we can help you with.
AUDIENCE: Today?
VIC FRYZEL: You can view that data today, but you can't
programmatically access it in the SDK today.
AUDIENCE: OK.
Lastly, Charlie was also talking about the quotas.
So I understand the per day quota, but for us, I think the
bigger bottleneck, especially when you're trying to run in
parallel, is the per second quota, the server limits.
So is that--
VIC FRYZEL: We can help you out there.
Worst case, we just multiply your per
second quota by 80,000.
But I think we can help you out there.
I don't know if we have a specific per second quota set.
I'm sure we do.
No?
No.
So come find me afterward and we can talk about how to get
your-- like I understand that case.
Like you migrate a university and while migrating that
university, you're making constant requests in one day.
And you're trying to finish your migration in less than a
week or something, right?
That's what you're talking about?
So I understand that in that week, your QPS is going to be
through the roof.
And then next week, you go on vacation.
You've been paid, right?
And so we can set a very, very high queries per day limit,
and that would still suffice.
And since there's no queries per second limit, I think you
would be OK.
The other thing you could do to make that even faster is
just set up concurrent requests.
So if you thread this stuff out, you can actually send
your QPS up very, very high and still get a high
throughput rate for migrating accounts or whatever.
AUDIENCE: So there's no per second rate?
VIC FRYZEL: No.
Hold on.
I misspoke.
There is one, I just don't know what it is off
the top of my head.
[LAUGHTER]
VIC FRYZEL: Sorry, man.
Hey.
AUDIENCE: Hey.
Jeff Williams from the U of M again.
So you might not be the right person, but I'm going to ask
anyway, just in case.
When we rename a user with the API, sometimes the user's
rename doesn't go through very quickly.
They don't get an alias or nickname, because we've got
many domains that are there.
So they can't get mail for potentially a day.
Most of the time, it's not a day.
Most of the time, it's right away.
But then sometimes when it's not, then apparently there's
some process that Google does to catch up on the ones that
didn't make it successfully.
And then there's sometimes ones that don't make it from
the first and the second layer of that process.
And we've had tickets with Google about it, and every
time, it's all happy and good until we get to the third or
fourth level, and then it's like, oh yeah, well, sorry.
VIC FRYZEL: So forgive me.
That is Google's problem, and it's something
we're working on.
I'm sorry that you had to endure that.
I realize that's a bad experience, and it's something
that we really care about and are fixing.
I'm familiar with that specific issue, and it's
something that we've been working on for a while.
It's a very complicated problem on our end.
A lot of people don't quite understand this, but
essentially when you create a user at Google, that touches
more than 1,000 machines instantly within
a matter of a minute.
And so keeping those machines in sync can
sometimes be tricky.
So feel free to come find me afterward or find any of the
team here, and I'd be happy to help you address that as soon
as possible.
Thanks.
AUDIENCE: Hi.
Just had a question about the Google+ Profiles API versus
the Google Profiles API.
Where it does seem that, if you have a Google+ profile
that is locked for some reason because you've contravened a
naming convention, then the user in the Google Profiles
API is not returned, which doesn't seem to be documented.
Is that just the documentation?
VIC FRYZEL: I think that is a documentation error.
I can help you get that fixed.
Sorry about that.
Hi.
AUDIENCE: Hi.
So there have been a couple questions about
quotas and the like.
And one of the reasons that's been an issue for--
hasn't really been an issue for us, but it could be a
potential issue is that the result set size when trying to
get user information from the Provisioning API previously
has only been 100 results per query.
Is that going to change with this API?
VIC FRYZEL: I think that's changing.
It's 500 now.
AUDIENCE: 500?
Excellent.
Thanks.
VIC FRYZEL: Hey again.
AUDIENCE: Hi.
Do we have an Active Directory equivalent coming out soon?
VIC FRYZEL: Forgive me, I didn't hear you.
AUDIENCE: Active Directory equivalent coming out soon for
Google Apps?
VIC FRYZEL: I don't have anything to announce today.
AUDIENCE: Active Directory for Exchange.
There is an Active Directory for Exchange,
so similar to that.
VIC FRYZEL: I'm familiar, but I don't have anything to
announce today.
Sorry.
Other questions?
I think I told half of you in the room to come find me
afterward, so it might take a while.
But make sure that you come to our Office Hours, which are on
the third floor.
A whole bunch of us are going to be
there answering questions.
And then make sure to attend the rest of the apps sessions
throughout the rest of the day.
There's a lot of interesting content.
Thank you very much.
[APPLAUSE]