►
Description
In this 18-minute developer focused demo – Waldek Mastykarz and Paolo Pialorsi confirm the benefits of using a common set of back-end APIs to provide enterprise level functionalities to a host of UIs - Teams, Outlook, Office.com, Viva and ACEs built with SPFx components. The example scenario – An office desk booking app. Security and API hosting from Azure, data in SharePoint lists. Reports in Power BI, Booking cards in Teams and Viva Connections Dashboard. Notifications in Outlook. Thorough code walkthrough. This PnP Community demo is taken from the weekly Microsoft 365 Platform Community call recorded on May 17, 2022.
Demo Presenters
• Waldek Mastykarz (Microsoft) | @waldekm
• Paolo Pialorsi (PiaSys) | @PaoloPia
Supporting materials
• Sample – PnP.SafeDesk365 | https://github.com/pnp/PnP.SafeDesk365
Learn more
• Microsoft 365 Unified Sample gallery - https://aka.ms/m365/samples
• Microsoft 365 Platform Community in YouTube - https://aka.ms/m365/videos
• Microsoft 365 Platform Community - http://aka.ms/m365pnp
A
All
right
so,
as
we
build
apps
on
microsoft
365,
they
can
be
of
many
shapes
isis
right
like
we
have
apps
that
are
destinations,
that
is
a
web
app
or
an
app
on
your
phone
right.
These
are
apps
that
you
explicitly
need
to
open,
but
the
really
true
powers,
when
you
think
of
it,
to
extend
your
app
so
that
your
app
spans
from
all
the
way
being
destination
being
a
web
app
being
a
mobile
app
to
extension.
That
shows
where
employees
already
are,
because
we
are
in
outlook
we're
in
teams.
We
are
on
office.com.
A
We
are
in
viva
right.
So
we
are.
There
are
a
number
of
different
apps
on
microsoft,
365
that
we
already
use
for
our
work
and
there's
nothing
worse,
and
I
guess
everybody
admits
that
that
there's
nothing
worse
than
to
do
a
thing
for
your
work
and
then
having
to
go
to
another
app
to
lose
the
context
of
your
work
having
to
switch
back
and
forth
between
multiple
apps,
because
you
need
that
full
picture
for
for
whatever
task
you're
trying
to
accomplish.
A
So
when
you
build
microsoft,
365
apps
think
of
it
that
your
apps,
the
apps,
that
you
build
for
your
work,
can
span
from
standalone
experiences
to
extensions
that
show
up
inside
microsoft,
365
where
users
already
are
when
you,
let's
think
about
scenario
right.
So
let's
say
we
wanted
to
build
an
application
for
our
company,
we're
going
back
to
office
and-
and
we
still
are
required
to
book
a
seat
because
we
don't
want
to
open
up
already
for
everybody.
A
We
have
limited
space,
so
we
want
people
to
book
a
space
ahead
of
time
before
they
arrive,
so
that
everybody
is
guaranteed
a
place
to
sit
right,
and
in
that
scenario
we
have
few
few
use
cases
right.
So
we
are
an
employee
and
we're
trying
to
find
a
seat.
We
and
we
want
it
for
a
given
date
or
a
portion
of
the
date,
and
we,
when
we
arrived
in
the
office,
we
want
to
check
in
to
confirm
that
yes,
we're
there
and
we're
going
to
use
that
seat.
A
It's
not
available
for
everybody
right
and
then
also
we
have
another
actor
facilities.
Who
wants
to
be
able
to
manage
the
bookings
that
everybody
places
right
and
and
then
then
also
afterwards
to
be
able
to
report
on
that
right?
So
there
are
a
number
like
when
you
think
about
this
scenario.
You
can
already
imagine
envision
few
ways
how
you
could
go
about
it,
how
different
actors
work
throughout
the
workdays
some
might
be
on
the
go.
Some
might
be
behind
a
desk
right.
A
So
what
are
the
different
ways
in
which
you
could
support
them
in
their
work?
And
here
are
a
few
experiences
that
you
could
imagine
you
would
build
right.
So
if
you
we
would
start
on
top
left,
you
might
have
a
personal
app
in
teams
right
that
allows
people
to
manage
bookings
directly
from
teams
so
not
having
to
go
anywhere
else.
Imagine
that
you
are
an
employee
and
you
want
to
book
a
seat
on
the
go
you're
on
your
phone.
A
In
this
place,
this
type
of
type
not
more
than
five
meters
away
from
coffee
right,
because
that's
your
thing
right
and
it
can
find
for
you
that
spot
without
you
having
to
to
worry
about
that
right.
So,
let's
have
a
look
like.
How
would
that
work
in
practice?
How
you
could
build
a
microsoft,
365
app
for
your
workplace?
A
A
B
B
You
can
find
the
whole
source
code
of
the
solution
that
valdec
showed
us
a
few
seconds
ago,
and
now
let
me
dig
into
the
solution
from
a
practical
point
of
view.
First
of
all,
I
will
show
you
the
user
experience
when
working
with
the
viva
connection,
adaptive
card
extension,
which
will
be
the
main
topic
of
my
demo
today.
Of
course,
we
don't
have
time
enough
to
cover
all
of
the
different
flavors
of
ui
that
we
implemented,
but
we
will
focus
on
viva
connections
now
here
you
can
see.
B
Let
me
try
to
be
lucky
and
let
me
search
for
a
free
desk
and
wonderful.
I
found
the
one
desk
desk01,
which
is
really
nice
and
close
to
the
coffee
machine,
five
meters.
Far
from
the
coffee
machine,
I
can
book
it
and
as
such
tomorrow
I
will
be
able
to
get
into
my
headquarter
and
still
using
the
same
adaptive
card
extension,
I
will
be
able
to
check
in
or
check
out
when
I
will
be
done
using
the
desk.
B
As
you
can
see,
the
experience
from
an
end
user
point
of
view
is
really
straightforward
and
simple.
Now,
let's
dig
into
the
technical
solution,
so,
first
of
all,
we
decided
to
use
microsoft,
lists
and
so
lists
stored
in
sharepoint
online,
at
the
very
end,
to
store
the
locations
to
store
the
desks
and
to
store
the
facilities
and
all
the
other
stuff
that
represents
the
repository
and
the
storage
of
data
for
our
solution.
B
This
is,
for
the
sake
of
simplicity,
and
to
give
you
a
solution
that
you
can
easily
deploy
in
your
environment
to
play
with
it.
Then
we
created
a
set
of
apis
on
top
of
the
lists
in
microsoft
lists
and
through
these
apis
we
make
available
to
all
of
the
different
flavors
of
ui
components
that
we
have
the
functionalities.
So
let
me
reduce
this
one,
so
we
have
the
api
to
manage
bookings.
We
have
the
api
to
manage
desks
and
to
do
all
the
stuff
that
we
need.
B
For
example,
if
I
want
to
book
a
location,
I
can
just
use
the
bookings
endpoint
and
do
my
stuff
through
this
api.
This
api
has
been
registered
in
azure
active
directory.
In
the
tenant,
where
we
are
using
this
solution
and
technically
speaking,
this
is
an
app
registered
in
azure
id,
which
is
exposing
an
api.
B
So
we
are
making
the
rest
api
available
to
all
of
the
client
solutions
that
we
built
for
the
safe
desk
365
and
in
order
to
consume
this
api,
you
simply
need
to
have
the
booking.write
permission
scope
assigned
to
an
application
which
will
rely
on
our
backend
api.
So
now
that
I
have
showed
you
what
we
have
under
the
cover,
let
me
switch
to
the
actual
source
code
of
the
adaptive
card
extension.
B
It
is
a
quite
rich
one,
so
I
will
not
dig
into
every
single
file,
but
I
will
give
you
an
idea
of
how
we
implemented
it.
First
of
all,
we
have
the
adaptive
card
extension
by
itself,
which
is
a
sharepoint
framework
component
which
inherits
from
base
adaptive
card
extension
in
this
component.
We
have
a
set
of
properties
and
a
state
like
we
do
in
real
components
and
from
a
properties
point
of
view.
B
We
simply
keep
track
of
the
settings
like
the
uri
of
the
application
api
that
we
want
to
consume
and
the
url
that
we
want
to
use
and
stuff
like
that,
while
in
the
state
we
keep
track
of
the
status
of
the
ui
and
specifically,
we
keep
track
of
all
of
the
available
locations.
All
of
the
desks
that
we
have
all
of
the
bookings
of
the
user
and
those
that
are
for
today
and
stuff
like
that.
So
we
keep
the
state
of
our
application
to
better
manage
our
logic.
B
Then,
in
the
uninit
method
of
our
component
of
our
spfx
component,
we
do
a
a
bunch
of
things.
First
of
all,
we
initialize
the
state
of
the
component
and
then
in
every
adaptive
card
extension
that
we
want
to
create.
We
can
have
two
different
flavors
of
ui
elements.
There
could
be
card
views
and
quick
views.
What
we
saw
here
while
booking
our
desk,
this
one
is
called
a
card
view
and
it
is
an
experience
based
on
a
predefined
set
of
ui
templates.
B
We
have
three
templates,
one
just
based
on
text,
one
based
on
text
and
a
secondary
text
and
the
third
one
based
on
an
image
which
is
the
one
I'm
using
right
here,
so
that
I
can
show
a
nice
image
and
a
ui
with
up
to
two
buttons
in
the
ui.
Then,
when
you
click
on
one
of
these
buttons,
this
one
is
called
quick
view
and
this
one
is
based
on
a
json
template
created
using
the
adapted
card,
json
syntax.
B
So
here,
as
long
as
you
rely
on
the
adapter
card
schema,
you
can
build
whatever
kind
of
ui
experience
you
like,
and
that's
why
you
were
able
to
see
different
ui
components
through
the
navigation
flow
of
the
user.
So
if
I
go
back
here
here,
we
are
simply
registering
the
card
views
and
the
quick
views
that
we
are
going
to
use
in
our
solution.
The
welcome
one
is
the
one
we
see
by
default
as
the
welcome
screen
of
the
adapter
card
extension.
Then
we
can
select
the
flow
when
we
want
to
book
a
new
desk.
B
We
can
go
for
the
free
or
for
the
specific
desk.
We
can
even
get
a
response
that
there
are
no
available
spots.
If
that
is
the
case,
and
we
can
get
the
confirmation
of
a
check
in
or
of
a
checkout
when
the
user
will
do
checking
checkout.
So
once
we
have
configured
this
date
and
the
registration
of
the
cart,
we
can
fetch
the
actual
data
from
the
api.
So
we
rely
on
a
fetch
data
method
that
we
invoke
asynchronously
so
that
we
can
start
rendering
the
ui
of
the
adaptive
card.
B
In
fact,
as
you
can
see
here,
if
I
will
refresh
you
see,
we
are
now
loading
and
once
we
will
be
done,
we
will
have
the
actual
data
available.
That's
what
we
do
in
the
fetch
data
and
in
the
fetch
data
we
simply
work
using
different
functionalities
that
we
have
out
of
the
box
in
sharepoint
framework.
What
do
I
mean?
Well,
whenever
you
want
to
consume
in
sharepoint
framework,
whether
you
are
creating
an
adaptive
card
extension
like
we
are
doing
right
now
or
a
web
part
or
an
extension
or
a
team?
B
Stop
doesn't
really
matter
what
kind
of
ui
component
you
are
building,
but
in
sharepoint
framework
you
can
always
easily
consume
an
external
api
which
can
be
micrograph
or
a
third-party
api,
and
you
can
do
that
safely
and
securely,
using
azure
active
directory
as
the
security
infrastructure
supporting
you
in
the
consumption
of
the
back-end
api.
Here.
What
we
do
is
to
use
the
context
of
sharepoint
framework
to
get
through
the
aad
token
provider.
Factory
object,
as
you
can
imagine,
based
on
the
name.
B
We
simply
use
the
token
that
we
get
through
the
token
provider,
and
then
we
use
a
client
object
to
invoke
the
back-end
api.
How
do
we
do
that
well
to
keep
the
architecture
clean
and
reusable?
We
decided
to
create
a
package
so
an
npm
package
that
we
called
safedesk
365-sdk,
which
is
right
now
in
preview
version,
as
you
can
see,
and
we
are
relying
on
this
sdk
to
consume
the
backend
api.
B
So
what
we
do
here,
we
rely
on
our
client
and
we
get
the
location
we
get
the
bookings,
we
filter
the
bookings
of
today,
and
then
we
configure
the
state
of
our
component
once
we
have
done
that,
we
need
to
render
the
ui
and
the
ui
can
be
rendered
either
using
the
car
views
or
the
quick
views.
I
will
give
you
a
quick
overview
of
the
idea
when
we
create
a
card
view.
B
This
will
be
a
typescript
class
which
will
simply
define
the
buttons
that
we
want
to
show
in
the
ui,
and
here
we
simply
say:
okay,
let
me
see
if
I
have
any
booking
for
today,
because
if
I
have
any,
I
will
show
the
button
to
create
a
new
booking,
as
well
as
the
button
to
check
in
or
to
check
out
based
on
where
I
am.
If
I'm
already
checked
in,
I
will
have
the
button
to
check
out.
B
If
I
still
need
to
check
in,
I
will
see
a
check-in
button,
then,
when
the
user
will
click
on
the
button,
I
will
simply
associate
an
action
which
will
be,
for
example,
let's
focus
on
the
action
to
book
a
new
desk.
If
I
select
book
a
new
desk,
I
will
show
a
quick
view,
which
is
the
one
built
on
adaptive
card,
json
schema,
which
will
be
the
one
I
registered
before
in
the
uninit
method.
B
So,
for
example,
when
I
click
on
the
book
button,
this
is
the
quick
view,
this
list
of
locations
and
this
list
of
time
slots
are
based
on
the
data
binding
of
an
object
that
I'm
providing
through
the
get
data
method,
and
you
can
see
here
I'm
providing
the
locations
so
in
the
json
matching
to
this
quick
view.
I
use
the
adaptive
card.
Syntax
here
is
version
1.3,
and
I'm
saying
that
I
have
a
container
in
which
I
will
show
a
text.