►
From YouTube: Developing Enterprise Blockchain Applications with Hyperledger Fabric - Andrew Coleman, IBM
Description
Developing Enterprise Blockchain Applications with Hyperledger Fabric - Andrew Coleman, IBM
With the increasing adoption of blockchain across industries such as finance, healthcare and supply chain, enterprise architects and developers are creating or adapting client applications to interact with these distributed ledgers. The challenge is making these technologies usable without the developer having to be an expert in crypto and the complex transaction endorsement requirements around blockchain. The latest v2.4 release of Hyperledger Fabric adds a new component to radically simplify the life of client application developers. By embedding the ‘gateway’ programming model directly into the Fabric peers and creating a new set of lightweight SDKs, the creation of client applications has become easier than ever. This session will teach the developer how to connect their applications to a Fabric network and invoke transactions to modify and query the ledger state.
Sessions Details & Slides (if available): https://sched.co/14H4B
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)
A
A
A
Are
you
familiar
with
the
new
programming
model
that
came
in
in
version
1.4?
Yeah?
Good?
That's
good!
That's
fine!
So
this
is
going
to
make
no
assumptions
that
you're
familiar
with
that.
But
if
you
are,
then
what
I'm
going
to
do
is
highlight
the
the
differences,
the
simplifications
and
improvements
that
we've
made
in
the
latest
version
in
2.4
and
really
it's
all
around.
A
You
know
the
client
applications
that
I'm
not
really
going
to
talk
much
about
developing
smart
contracts,
but
you
know,
as
a
client
application
developer
you're
going
to
be
interested
in
submitting
transactions,
invoking
the
smart
contracts
that
are
on
The,
Ledger
and
then
we'll.
You
know
we'll
talk
about
the
basics
and
we'll
go
on
to
some
some
more
advanced
stuff
and
I'm,
going
to
Pepper
this
presentation,
with
with
with
Snippets
of
code
in
the
various
languages
that
we
support
and
I
don't
favor
anyone
over
and
over
the
other,
they're,
all
equally
capable.
A
A
A
It
has
pluggable
consensus
protocols,
so
you
know
the
the
ordering
node
can
has
evolved
over
the
years
it.
Currently,
the
default
is
raft-based
orderer,
which
is
Crash
fault
tolerant,
but
we
are
actually
actively
working
now
on
a
Byzantine
fault,
tolerant
ordering
service,
and
we
plan
to
deliver
that
in
version
three
now,
notably,
smart
contracts
can
be
authored
in
a
general
purpose,
programming
language
and
we
support
three
out
of
the
box.
But
you
know
it's
extendable.
A
A
So
what
I'm
going
to
do
now
is
sort
of
start
focusing
on
on
the
topic
of
this
talk
and
I
just
want
to
give
you
a
picture
of
one
component
of
fabric,
which
is
the
pier.
Now
the
pier
and
you
know,
a
blockchain
network
will
run
multiple
peers
across
multiple
organizations,
but
inside
the
pier
is
The
Ledger
itself
and
and
The
Ledger
is
made
of
of
two
components:
there's
the
there's
the
blockchain,
which
is
the
you
know,
the
the
ordered
set
of
transactions
where
the
transaction
you
know
marks
wherever
say
you
know.
A
If
you
look
at
your
bank
accounts,
you've
got
lines
saying
well,
something
was
paid
in,
something
was
paid
out,
they're
the
transactions
and
then
you've
got
the
run
in
total.
The
current.
What
we
call
the
world
state,
which
is
if,
if
you
run
all
of
those
through
this
database,
you
end
up
with
this
world
State
like
your
current
bank
balance,
and
so
all
valid
transactions
will
affect
that
world
sites.
When
it's
finally
committed
to
The
Ledger,
now
hosted
by
the
peer,
although
in
a
separate
process,
is
a
smart
contract.
A
So
all
transactions
are
encoded
into
the
smart
contract,
so
when
a
client's
application
invokes
a
transaction,
submits
or
evaluates
a
transaction,
it
runs
the
smart
contract
in
this
chain
code
container.
We
call
it
chain
code
and
fabric
and
that
will
interact
with
the
Ledger
and
it
can
also
emit
events.
So
you
can
have
contract
events
and
also
when
blocks
are
committed.
A
You
get
these
Block
events
now,
at
the
top
there,
with
the
blockchain
developers,
us,
okay
and
I
I've
I
split
it
into
two,
because
we've
got
developers
who
focus
on
Smart
contracts
and
we've
got
developers
that
focus
on
the
client,
application
and
I,
don't
believe
that
they
are
necessarily
the
same
person.
So
you
know
the
the
developer
that
develops
a
smart
contract
will
have
deep
knowledge
of
how
that
works.
The
developer
Who
develops
the
client
application
is
probably
also
developing.
A
You
know,
interacting
with
other
systems
database
system
messaging,
middleware
integration,
as
we
heard
earlier,
these
blockchain
developers
are
not
just
focusing
on
blockchain
there's
a
whole
raft
of
other
things.
They
have
to
worry
about
in
their
day
job,
and
so
probably
the
skill
sets
of
of
these
two
developers
are
different.
So
certainly
the
the
client
application
developer
will
need
to
know
what
that
does,
but
not
necessarily
how
it
does
it
and
that's
very
much
driven
our
design
of
the
of
the
programming
model.
A
So
you
don't
have
to
worry
about
this,
but
you
know
back
in
the
old
days.
You
have
to
use
the
right
hundreds
of
lines
of
code
just
to
submit
a
transaction
onto
The
Ledger,
and
so
we
we
felt
the
need
to
raise
the
layer
of
abstraction
on
that,
and
we
also
we're
very
careful
with
the
naming
of
the
of
the
classes
and
the
methods
in
the
new
programming
model.
A
We
wanted
to
speak
the
language
of
the
target,
audience
of
people
that
were
familiar
with
networks
and
and
contracts
and
transactions
rather
than
you
know,
fabric
terms,
like
you
know,
chain,
code
and
channels,
and
things
like
that.
Although
we've
kind
of
mixed
and
matched
a
little
bit-
and
we
came
up
with
it
with
the
idea
of
the
of
the
Gateway,
which
was
very
much
a
sort
of
a
virtual
object
used
in
the
in
this
programming
model.
A
So,
towards
the
end
of
last
year
we
developed
we,
we
released
fabric
version
2.4
and
one
of
the
major
new
components
in
2.4
was
with
the
Gateway.
So
the
Gateway
is
an
implementation
of
this
high-level
programming
model.
But
it's
now
in
the
peer
itself,
rather
than
as
a
layer
in
the
in
the
in
the
SDK,
and
so
we
we
now
expose
that
as
a
as
a
service
from
the
peer.
And
so
we
went
back
and
we
rewrote
the
the
three
s
sdks.
A
A
The
Gateway
peer,
the
The
Chosen
Pier,
appear
that
you
trust
okay
to
to
to
run
this
life
cycle
transaction
life
cycle
on
your
behalf
and
then
the
pier
itself
will
make
connections
to
all
of
the
other
peers
in
the
network
and
also
all
of
the
ordering
service
on
your
behalf.
So
you
only
have
to
now
make
one
connection,
and
a
consequence
of
that
is
that
you
no
longer
need
these.
These
Network
config
files
or
CCP
files,
depending
on
the
SDK
that
you
used
it,
was
called
different
things,
but
it
was
a.
A
It
was
basically
this
yaml
file
format
that
defined
all
of
the
endpoints
that
you
might
want
to
connect
to,
and
it
also
had
other
things
like
grpc
options,
timeouts
and
stuff
like
that.
But
what
we've
actually
done
now
is
we
say
actually
the
client
application
can
make
that
one
single
grpc
connection
Supply
that
and
we
no
longer
need
that
cccp
file
commit
strategies.
So
that
was
something
where
you
know
what
defines
when
a
transaction
is
committed
to
The
Ledger
they
put
out
these
Block
events,
but
how
many
Block
events
do
we
listen
to?
A
Well,
actually
would
by
embedding
the
Gateway
in
the
pier
we've
now
automated
all
of
that,
and
we
actually
have
an
ideal
strategy
that
I'll
explain
to
you
later,
so
you
don't
have
to
worry
about
that.
Either
we've
done
away
with
wallets
for
storing
identities.
These
are
all
things
that
weren't
really
Central
to
interacting
with
fabric,
and
in
fact,
you
know
you
generally
developers
who
are
developing
these
applications
will
have
their
own
mechanisms
for
storing
their
private
keys,
and
things
like
that.
A
Okay,
so
this
isn't
about
smart
contracts,
but
it's
useful
to
know
what
a
smart
contract
does
and
and
what
it
looks
like.
An
important
thing
to
note
is
that
all
transactions
have
to
go
through
a
smart
contract.
All
interactions
with
The
Ledger
have
to
go
through
a
smart
contract,
and
this
is
really
sort
of
the
the
framework
of
what
it
looks
like
you'll
have
a
class.
This
is
this
is
Javascript,
you've
got
a
class,
extends
contract
and
then
you've
got
methods.
A
A
So,
if
you're
already
using
the
new
programming
model,
you'll
be
familiar
with
this
basic
hierarchy
of
objects.
At
the
top
level,
we've
got
a
Gateway
which
represents
you
know
in
the
old
days,
a
virtual
connection
into
the
network.
Now
it's
that
Gateway
actually
is
in
the
pier,
and
so
you
can
then
get
a
connection
to
each
of
the
networks
and
that's
a
that's
a
channel
in
fabric
terms
and
once
you're
targeting
a
channel.
A
You
can
get
an
object
representing
a
smart
contract
instance
on
that
channel
and
there
sort
of
the
the
highest
level
of
abstraction.
You
can
evaluate
a
transaction
which
will
invoke
a
transaction,
a
transaction
function
to
do
a
read
operation
on
The,
Ledger
or
submit
transaction.
If
you
want
to
modify
The
Ledger
and
under
the
covers,
they're
doing
very
different
things,
and
you
can
also
hook
into
events.
So
your
client
application
can
listen
to
events,
whether
the
chain
code,
events
or
Block
events
as
they're
being
omitted.
A
Okay,
we've
got
some
work
there
to
specify
our
identity,
because
you
know
it's
a
permission:
Network,
that's
the
identity
that
your
transactions
are
done
under
you'll
need
some
sort
of
signer
implementation,
a
function
that
signs
the
proposals
and
the
transactions.
So
that's
a
function
that
just
takes
a
digest
and
returns
a
signature.
A
And
then
you'll
meet
your
grpc
connection
into
your
favorite
Pier
and,
given
that
you'll
then
create
a
Gateway
instance
using
these
three
things:
access
your
network,
your
contract
and
then
you
can
start
submitting
transactions.
So
we've
got
two
transaction
submissions
one
after
another
and
then,
when
your
application
ends,
there's
some
there's
some
cleanup
code.
That's
that's
the
general
structure
of
a
very
simplified
application
and
you
know
that's
taken
from
real
code,
barring
some
imports.
This
is
Java.
A
A
A
A
Yeah,
no,
so
what
what
so
so?
The
question
was
the
pair
that
you
connect
to.
Does
it
have
to
be
a
member
of
the
channel
that
you
want
to
transact
on,
and
the
answer
is
not
necessarily
because
the
Gateway
service
itself
will
when
it
comes
to
we'll,
come
on
to
this
in
more
detail.
So,
let's
start
with
a
quick
answer
which
is
no
and
then
I'll
explain
why
later
yeah.
A
Then
you,
because
these
these
These
are
now
the
lighter
weight
ones
that
replace
the
older
ones,
and
they
all
do
support
the
same
thing,
but
they
look
different.
They
do
it
in
different
ways
and
the
reason
is,
we've
really
tried
to
you
know:
adopt
the
idioms,
the
patterns
that
are
meaningful
to
that
particular
language.
So
so,
for
example,
in
Java
we've
adopted
this
sort
of
fluent
style
Builder
pattern,
so
you
know
you
can
chain
your
functions
together.
A
Obviously
Java
supports
exception
handling,
so
you
know,
you're
surround
it
with
a
big
try,
catch
block
and
that
you
know
that
makes
next
to
a
Jarvis
Style
with
with
node
typescript
or
JavaScript.
Then
you
typically
pass.
You
know:
JavaScript
objects,
json-like
objects
to
pass
in
your
your
options
and
with
go.
We've
adopted
this.
This
idea
of
optional
functional
functional
arguments,
which
is
which
is
very
popular
in
in
go
apis,
but
they
all
do
the
same
thing.
A
So,
let's
step
through
each
each
part
of
the
process,
so
we've
got
to
connect
to
the
Gateway
and
a
Gateway
object
represents
the
connection
to
the
the
fabric
network
with
a
given
identity.
So
you
know:
if
you
want
to
interact
with
the
network
using
two
or
more
identities,
then
you
can
have
two
or
more
gateways.
A
A
Obviously,
when
you're
dealing
with
go
you'd
want
to
check
the
error
as
it
comes
back
and
do
error
handling,
you
know,
as
you
go
along
in
the
code
in
in
node
or
Java,
you
would,
you
would
use
exception,
handling
mechanisms,
so
that's
creating
your
gateway
object,
and
so
before
you
do
that,
you
need
a
grpc
connection.
Now
we've
got
out
of
the
business
of
making
those
grpc
connections
on
your
behalf.
A
You
only
need
one
now,
rather
than
one
to
each
pair
you're
connecting
to
and
actually
each
language
has
a
perfectly
capable
grpc
Library
itself,
and
so
rather
than
you
know
us
sort
of
wrapper
that
and
then
you
know
every
time
a
new
Option
or
something
different
is
required.
You
know
you
come
to
us
and
say:
oh
well,
can
you
support
this
and
then
we?
A
And
very
similar
with
identity
and
signing
you
know,
rather
than
you
know,
with
the
old
apis,
we
said
well
give
us
your
private
key
and
trust
us.
We
we,
you
know,
we
won't
do
anything
nasty
with
it,
we'll
just
use
it
for
signing
what
you
now
actually
do.
Is
you
provide
a
function
that
does
signing
and
we
will
invoke
it
at
times
when
the
transaction
needs
to
be
signed.
A
Now,
if
you
have
a
a
private
key,
then
we
provide
a
helper
function
to
create
a
signing
function
for
you,
but
you
know
be
reassured
that
your
private
key
never
goes
across
to
the
Gateway.
It
always
stays
in
your
client
application.
It
always
did,
but
you
know
this.
This
API
emphasizes
the
fact
that
it,
you
know
no
keys,
get
passed
across
the
network
into
the
server,
so
we
always
call
back
again
into
your
client
application
when
we
need
anything
signed.
A
So
any
transaction
that
modifies
The
Ledger
has
to
go
through
a
process
of
endorsement
and,
depending
on
the
endorsement
policy,
which
is
associated
with
the
smart
contract
that
you're
invoking,
this
transaction
might
need
to
be
invoked
or
simulated
on
on
multiple
peers
across
multiple
organizations,
and
you
know,
as
we
saw,
that
smart
contract
that
was
installed
on
on
apia,
we
saw
that
it
gets
in
votes
and
I
said
that
it
it
generates
a
read,
write
set.
It
doesn't
modify
The
Ledger
at
that
point.
A
What
it
does
is
it
runs
against
that
peers,
copy
of
a
ledger
and
it
and
the
read
write
set,
represents
what
it
would
do
to
its
Ledger
okay.
So
it
that's
that's
an
endorsement
that
peer
then
signs
it
and
sends
it
back
to
the
requester
so
to
submit
a
transaction.
You've
got
to
go
off
to
various
peers
and
gather
all
the
endorsements,
and
they
must
all
agree.
Okay,
both
the
read
and
the
right
set
have
to
agree
all
of
them
and
when
they
do,
you
gather
those
together.
A
It
gets
signed
again
on
the
client
side,
and
then
it
gets
sent
off
to
the
ordering
service.
Okay
and
then
that
that
orders,
the
transactions
using
its
consensus
mechanism
and
it
broadcasts
it
out
to
the
to
the
network
and
commits
it
and
that's
quite
a
complex
bunch
of
stuff
and
that
all
gets
done
in
one
function
called
submit
transaction.
A
A
So
what
that
then
does
on
your
behalf?
Is
it
gathers
the
endorsements
from
itself
and
from
any
other
organization,
that's
required
in
order
to
satisfy
the
endorsement
policy
and
then
once
it's
gathered
all
that
it
will
send
it
to
the
ordering
service
and
the
ordering
service
will
batch
up
transactions,
order
them
and
broadcast
them
to
the
to
every
pair
okay
for
committing
to
The
Ledger,
and
then
only
at
that
point
do
they
emit
a
block
event
and
the
Gateway
will
return
control
from
that
submit
transaction.
A
So
querying
The
Ledger
doing
a
read
from
the
ledger,
so
just
to
emphasize
that
all
interactions
with
The
Ledger
are
done
through
the
smart
contract.
So
if
you
don't
have
any
transaction
functions
that
read
from
The
Ledger
and
return
values,
then
you
can't
query
with
Ledger.
It
has
to
be
done
through
the
smart
contract.
It
still
has
to
be
invoked,
but
if
you're
not
modifying
The
Ledger,
it
doesn't
have
to
go
through
this
endorsement
and
ordering
process.
A
A
How
do
I
know
I've
got
the
most
up-to-date
value
and
you
know
you
used
to
wait
on
these
various
commit
events
to
before.
You
were
sure
that
you
know
you've
got
that,
but
now
the
Gateway
is
managing
that
all
before
you.
So
it
knows
after
it's
submitted
to
the
transaction.
It
should
look
when
it's
doing
a
query
for
the
highest
block
before
it
returns.
A
a
result
to
you.
A
A
It's
sharing
your
sensitive
data
with
other
organizations,
unless
it's
pretty
sure
that
it's
okay
and
I'll
explain
in
the
next
slide
what
the
endorsement
logic
is,
but
you
know
we
we
Transit
data.
It
does
take
a
more
guarded
approach
and
because
of
that,
you
could
result
in
the
Gateway
not
collecting
enough
endorsements
to
satisfy
the
various
policies.
A
And
so
that's
that's
the
one
situation
that
I
can
think
of
anywhere,
where
the
the
application
developer
would
actually
want
to
specify
who
the
endorsing
orgs
should
be,
and
that's
probably
okay
with
with
private
data,
because
you
know
typically
you're
doing
things
like
well
I.
You
know
I
want
to
sell
my
asset
to
that
organization
there
and
you
you
know
who
the
buyer
and
the
seller
are,
and
it's
a
good
chance
that
they
will
be
the
two
walls
that
need
to
endorse
the
transaction.
A
So
you
also
need
to
be
aware
that
who
you're
using
as
your
as
your
gateway,
peer
and
I,
said
at
the
beginning.
That's
your
your
trusted
peer
and,
if
you're
sending
sensitive
data
across
then
you
know
you
really
are
trusting
that
peer
to
to
handle
that
or
to
even
see
that
private
data
and
if
you're,
an
organization
that
doesn't
run
up
here,
then
you'll
need
to
send
it
to
appear
that
you,
you
do
trust
in
another
organization.
C
C
A
A
So
each
smart
contract
is
deployed
an
endorsement
policy.
So,
for
example,
you
know
that
that
top
one
is
a
majority.
You've
got
three
orgs
I
need
two
of
them.
That's
the
default
policy.
The
second
one
is
a
bit
more
specific.
It
says:
well,
actually
I
want
org
one
to
sign
it
and
then
either
all
three
or
all
four.
A
So
all
one
might
be
a
you
know,
an
auditor
or
a
you
know,
regulator,
someone
who
absolutely
has
to
sign
every
every
transaction,
but
it
gets
more
complicated
when
we're
dealing
with
with
private
data
collections
and
multiple
chain
codes.
So,
for
example,
you
know
a
transaction
proposal
might
have
to
satisfy
multiple
endorsement
policies
at
the
same
time.
A
So,
if
we're
doing
chain
code
to
chain
code,
if
one
chain
code
is
deployed
using
that
one
and
the
other
one
is
with
the
second
one,
actually,
both
of
those
at
the
same
time
have
to
be
satisfied
and
the
only
way
to
satisfy
both
of
those
at
the
same
time
is
to
have
org
one
and
all
three
sign
it.
So
we're
now
narrowing
down
we're
forming
a
sort
of
a
derived
endorsement
policy
that
takes
into
account
both
of
those
and
it
gets
worse
with
with
private
data
collections
because
they
have
their
own
signature
policies.
A
And
so
we
need
to
bring
those
in
as
well
and
if
you're
doing
a
read
from
a
private
data
collection,
then
you've
got
the
ownership
policy
as
well,
which
might
you
know
limit
you
to
who
you
know,
whoever
has
copies
of
the
private
data
collection
and
then
it
really
gets
worse
with
with
with
state-based
endorsement
policies,
because
you
know
each
individual
state
within
the
the
metadata
in
The
Ledger
can
have
an
endorsement
policy,
that's
just
just
for
that
state
itself
and
they
can
change.
So
a
transaction
can
change
those,
so
they're
Dynamic.
A
So
whenever
you're
submitting
a
transaction,
all
of
those
have
to
be
satisfied,
and
so
how
does
the
Gateway
do
that
so?
Prior
to
2.4,
the
client
application
had
to
understand
all
of
the
things
that
were
being
touched
by
the
the
the
smart
contract.
Okay,
it
really
needs
to
understand
how
the
smart
contract
worked
rather
than
just
what
it
did.
A
A
So
is
there
any
performance,
overhead,
no
I'd
say
the
other
way
around
it's.
You
know,
because
because
we
now
know
exactly
who
to
Target,
we
don't
have
to
go
off
a
lot
of
applications.
The
way
they
used
to
handle.
This
was
just
get
everyone
to
endorse
it,
because
the
problem
was
too
difficult
to
solve.
If
you
get
everyone
to
endorse
it,
build
up
this
huge
transaction
and
pass
it
through
and
let
the
like
let
the
final
validation
phase
decide
whether
that
worked
or
not.
But
now
you
know
up
front.
A
A
So
so
it's
two
phases.
First,
it
simulates
it
on
on
the
local
pier.
In
order
to
then
understand
what
the
endorsement
policy
will
be
and
then
it's
got
a
you
know
a
set
of
endorsers
that
it
needs.
Obviously
it's
already
done
it
itself,
so
whatever's
left
it
will
then
in
parallel,
go
out
and
gather
all
the
others.
So
it's
a
two-step.
C
A
A
If
you
you
know
for
endorsement,
if
you,
if
you,
if
you
need
to
do
that,
then
there's
another
form
which
is
submit
and
evaluate
okay,
so
they're
slightly
lower
level
than
than
the
submit,
and
then
let's
go
and
node
examples:
okay,
using
functional
arguments
or
or
JavaScript
objects,
but
that
just
allows
you
to
you
know
slightly
finer
control
or
we
can
get
even
more
control.
If
we
want
to
well
okay,
the
submit
transaction
is
you
know
it's
going
out,
it's
getting
multiple
endorsements,
it's
Gathering
the
responses.
A
You
know
it's
submitting
to
the
order,
it's
a
weight
and
a
commit
notification.
We
can
break
that
down
now
into
individual
things,
so
so
in
Java
we're
using
the
you
know
the
the
style
where
you
just
chain
them
together.
So
we
can
create
a
new
proposal.
We
can
put
transient
data
in
there
and
and
then
we
build
and
endorse
and
before
we
submit
we
can.
You
know
we
can
pick
out
intermediate
results.
A
We
can
get
the
transaction
ID
or
the
result,
and
so
you
know,
and
we
can
Implement,
you
know
different
flow
logic
we
might
want
to.
You
know,
do
some
different
retry
options
or
something
like
that
in
between
each
step.
So
if
you
really
want,
you
know
the
high
level,
one
is
great,
but
if,
if
you
want
finer
control,
you
want
to
do
your
own
logic
in
there,
then
then
we
can
break
out
these
steps
and
you
can
have
more
control
over
them.
A
So
if
a
peer
doesn't
have
the
chain
code
installed,
then
the
Gateway
will
not
try
and
get
it
to
endorse
a
transaction.
So
so
the
Gateway
pair,
you
know
the
the
service
Discovery
and
the
Gateway
are-
are
working
very
closely
together,
yeah
yeah.
So
if
there's
a
transaction
proposal
on
on
a
channel,
so
let's
come
back
to
your
question
earlier
about
channels.
What,
if
it's
not
in
the
channel?
Well,
that's
fine,
because
it
will
work
with
a
discovery
service
to
to
find
a
peer.
A
That
is
a
member
of
that
channel
across
organizations
yeah
and
the
site
the
same
with
change
it
unless
you're
passing
transient
data,
in
which
case
it
won't
just
go
off
to
another
organization
willy-nilly,
but
yeah.
Apart
from
that,
you
know,
you've
got
you've,
got
a
channel
and
a
chain
code
ID.
It
will
find
the
peers
and
the
organizations
that
can
run
that
and
it
will,
it
will
ask
them.
A
All
right,
so
some
some
other
logic-
and
it
comes
back
to
your
question
earlier
about
well-
does
does
submit
transaction
wait
for
the
commit.
Yes,
it
does,
but
if
you
don't
want
to
wait,
for
example,
if
you,
if
you
want
something
a
bit
more
responsive
if
you're
writing
a
rest
application,
where
you
know
you
want,
you
want
to
get
a
result
back
fairly
quickly
or
you're,
updating
a
UI
or
something
like
that.
A
Then
you
don't
want
to
sit
there
waiting
for
the
you
know
the
the
order
at
a
batch
of
transactions
and
and
to
validate
and
commit
you'll
still
need
to
eventually
before
you
know
that
transaction's
been
committed.
But
in
the
meantime
you
can.
You
can
do
some
other
logic,
and
so
you
can
do
an
async
submit,
submit
async
you
know,
and
then
it
will
return
control
to
you
as
soon
as
it's
successfully
sent
to
the
ordering
service,
and
it
will
return
an
object
along
with
that.
A
A
Yeah,
so
so
the
so
the
commit
will
actually
wait
for
the
commit
on
the
Gateway
itself.
So
it's
only
going
to
wait
for
that.
One
one
commit
yeah,
that's
right,
because
it
yeah
that's
one,
and
it
only
needs
to
because
if
it's
followed
up
by
a
query
and
evaluate
transaction
that
Gateway
knows
it
can
find
it
knows
it
can
find
appear.
That
has
that
one,
because.
A
A
So
so
you
can
handle
blockchain
events
yourself,
so
you
can.
You
can
wait
on
Block
events,
so
you
might
have
some
application
that
you
know
wants
to
receive
the
Block
events
and
do
something
like
you
know,
store
data
on
a
you
know,
an
off-chain
database
or
something
like
that,
and
you
can
wait
on
these
chain
code
events
or
contract
events.
A
A
Error
handling,
so
so
the
errors
are,
you
know,
potentially
coming
back
across
your
grpc
Channel
and
we've
very
much
adopted
the
the
grpc
best
practices
for
error
handling,
and
you
know
we
support
what
it
calls
the
the
Richer
error
model.
So
there's
a
link.
If
you
want
to
read
about
that-
and
you
know,
there's
an
error
type,
so
there's
hierarchy
of
Errors,
so
you
know
we
can
indicate
whereabouts
in
the
transaction
flow.
A
A
grpc
error
has
a
status
code
and
you
know
Google
define
a
you
know:
a
well-defined
set
of
of
status
codes
and
each
one
has
a
different
meaning
in
as
far
as
you
know,
should
you
try
and
retry?
Is
it
a
transient
error
or
is
it
more
of
a
an
application
coding
error
and
things
like
that,
so
we
we've
tried
to
you
know,
keep
all
of
our
errors
within
the
the
framework
that
it
sets
out
there.
So,
for
example,
you
know
if
the
read
write
set
mismatches,
then
that
should
be
with.
A
A
High
availability,
so
you
you
know
you're
now
in
charge
of
managing
your
grpc
connection
and
typically
in
a
cloud
deployment.
You'll
go
through
a
you
know,
an
Ingress
controller,
a
load,
balancer,
okay,
and
that
you
know
you've
got
you've,
got
a
single
connection,
endpoint
for
your
client
and
that
will
fan
out
to
multiple
gateways.
By
the
way,
every
peer
is
a
gateway
peer
unless
you
turn
it
off.
So
by
default,
every
peer
can
can
work
as
a
gateway,
and
we
can
do
that
fairly
easily,
because
the
the
Gateway
is
stateless.
A
All
right,
so
we've
we've
also
done
a
lot
of
work
on
documentation.
We've
we've
Rewritten,
the
you
know
the
develop
an
application
section
and
so-
and
you
know,
there's
a
large
section
on
how
the
Gateway
Works
internally,
if
you're
interested
in
the
internals
and
we
built
a
a
lot
of
new
samples.
So
we've
got
these
asset
transfer
samples
and
there's
quite
a
few
of
them,
and
we
go
from
the
really
easy
through
to
the
really
quite
Advanced.
A
So
we
demonstrate
all
you
know
the
private
data
and
state-based
endorsement
so
they're
all
in
the
in
in
the
fabric
samples
we've
got,
you
know
the
Java
dock,
JS
dark,
godoc,
API
reference,
okay,
so
that's
all
indexed
from
that
URL
there
getting
help,
of
course,
where
there's
the
the
fabric
mailing
list,
disc
called.
If
you
want
to
have
a
conversation
and,
of
course
stack
Overflow
and
if
you
find
bugs
then
by
all
means,
raise
an
issue
on
the
on
the
fabric,
Gateway
repo.
A
You
know
way
back
in
in
version
1.4,
and
this
is
the
natural
progression
where
we've
you
know,
we've
put
all
of
that
logic
into
the
pier
itself
and
really
I
encourage
you,
if
you're,
if
you're
around
Wednesday
morning,
to
try
this
out,
because
we've
built
a
workshop
that
will
take
you
from
nothing
through
to
deploying
a
a
fabric
Network
on
on
kubernetes,
and
you
know,
building
some
client
applications
and
and
running
them,
and
that
that
will
run
Wednesday
morning
in
the
hotel
next
door.
I'd
leave.
A
So
so
so
the
question
is
what
about
calling
the
external
service
off
chain.
So
are
we
talking
about
from
a
client
application
or
from
a
smart
contract?
Okay
right
that
that's
a
conversation
over
a
beer
tonight,
but
this
was
more
about
client
applications.
But,
generally
speaking,
I
would
say
that's
a
bad
idea,
because
you
know
that
that
external
thing
could
change
and
it
won't
have
been
endorsed
by
the
the
multiple
endorses
that
I
have
to
sign
off
a
smart
contract.