►
From YouTube: Magento MSI Open Demo. May 31, 2019
Description
Agenda:
• General Updates on what's happening
• Improved Stock Item configuration discussion
• Using Sagas for compensating reservations when something goes wrong
• Selected Source on Order grid feature request overview
• Stock Item Configuration UI considerations
• MSI Quality updates
Related links:
1. Sagas
https://github.com/magento-engcom/msi/issues/2290
https://microservices.io/patterns/data/saga.html
2. Sources in Order Grid feature request
https://github.com/magento-engcom/msi/issues/2281
A
A
Welcome
to
another
weekly
MSI,
open
demo
today
have
some
interesting
items
of
the
agenda,
which
are
not
really
demos,
but
some
kind
of
discussions
and
I'm
not
totally
sure
but
maybe
Rodrigo
would
be
still
able
to
demo
his
store
or
not.
So
please,
let
me
know,
and
you
can
jump
in
any
moment
if
you
wish
to
do
it
this
time.
A
Do
you
start
a
guess?
I
guess
I'll
give
some
general
update
and
what's
happening
on
the
msi
track
and
then
we'll
proceed
with
with
those
eyes
and
configuration
questioned
by
alessandro,
though
the
general
update
is
that
we
are
still
working
on
publishing
the
general
available
msi
one
one,
two
packages.
We
have
finished
the
main
test
cycle
and
additional
test
cycle,
so
everything
is
apparently
green,
which
is
really
great,
and
packages
are
already
deployed
to
the
internal
quality
repo.
So
I
guess
we'll
be
able
to
publish
them.
A
A
Quite
a
lot
of
effort
in
store
pickup.
This
week
we
have
managed
to
merge
the
Alexandra's
call
request,
which
introduced
the
store,
pickup
shipping
method.
This
pool
request
is
really
important,
as
it's
pretty
much
in
locks
of
the
future
work
on
the
checkout,
and
we
already
have
a
first
full
request
by
creative
style,
which
is
targeting
and
Fromm's
and
implementation
for
this
topic.
A
A
The
idea
behind
this
is
to
simplify
tracking
of
different
kind
of
tracks,
which
may
be
interesting
for
someone
likes
to
pick
up
it
separately
and
some
bug
fixes
bond
product
and
stuff
like
that,
and
also
the
open-source
team
which
is
working
on
the
core
repository.
They
set
up
a
nice
project
for
us,
which
has
managed
pretty
much
automatically
it's
still
in
pretty
messy
state,
because
we
have
to
do
some
manual
work
to
kick.
C
It's
a
game,
but
I
realized
that
he
didn't
follow
all
the
directives
that
were
given.
So
I'm
trying
to
everything
and
I'm
trying
to
to
do
things
based
on
vertical
slices.
So
what
I
wanted
to
do
was
to
try
to
provide
the
service
for
a
backorders
configuration
from
from
each
level.
So
the
service,
the
Web
API
the
test
and,
at
the
moment,
I'm
stuck
at
deciding
how
to
define
the
Web
API
interface
because
it
has
not
been
designed
and
we
have
I
think
a
couple
of
possibilities.
C
C
Basically,
setters
based
on
a
first
approach,
which
would
use
a
route
like
this
inventory,
configuration
recorders,
SKU
source
code
and
the
method
and
so
on,
depending
on
the
scope
of
the
configuration.
This
would
lead
to
a
lot
of
routes,
because
we
have
11
configuration
options,
though
this
would
lead
to
a
lot
of
routes
and
before
going
on
this
way,
I
wondered
whether
it
was
better
to
define
inventory
configuration,
route
and
specializing,
which
kind
of
of
operation
we
have
based
on
the
body
rather
than
on
the
root.
B
D
C
C
Is
a
lot
of
that?
There
is
a
lot
of
things
to
do.
I
just
started
working
on
this
kind
of
functionality,
so
I
can
I
can.
If
you
prefer,
I
can
submit
initial
pull
requests
working
progress,
pull
request.
There
is
still
a
few
code
I'm
trying
to
cover
the
code
with
integration
test
far.
So
you
see
you
already
see
some
tests
here
that
cover
basically
setting
and
getting
this
value
from
configuration
table.
C
C
A
A
C
C
A
You
thank
you
Alessandro.
That
already
looks
good,
that
we
have
some
kind
of
API
is
in
development
and
I.
Think
the
next
point
on
the
agenda
would
be.
Igor
has
come
up
with
an
idea
to
use
sagas
for
for
exceptional
cases.
For
example,
when
order
is
placed
for
canceled
or
processed
in
an
correct
way,
an
exception,
that's
thrown
the
saga
would
allow
us
to
compensate
the
creates
its
reservation
back
to
the
initial
state.
The
I
guess
eager
will
shed
some
light
on
this.
D
Actually
Eugene
already
told
the
main
idea
behind
behind
the
changes
like
we
had
a
shot
with
Paul
Hoffman,
who
is
currently
who
like
who
currently
released
some
msi
extensions
and
they're,
currently
working
for
particular
emicida
stimulation.
They're,
like
you,
can
see
the
thread
in
the
hematite
channel
and
that
particular
problem,
which
happened
to
fall
that
for
some
particular
orders.
D
D
But
I
like
either
sales
or
like
warrior
mechanism
and
based
on
the
universe
station
we
have
is
also
they
exceptionally
actually
is
pretty
much
expected.
But
what
is
not
expected
from
the
poll
side
was
that
there
is
a
reason
mechanism
is
not
change,
transactional
scope,
so
that
like
when
we
are
making
their
old
back.
Regarding
that
order
placement
we
are
not
compensating
the
compensated
transaction
for
for
the
reservation,
and
this
interview
and
the
other
side
effects
for
us
for
MSI.
It
creates
for
each
of
those
attempt
for
order
for
shipment
creation.
D
We
were
ending
out
with
creating
reservation
again
and
again
so
that,
as
a
result,
we
have
the
math
on
the
reservation
and,
like
heat
effect,
saleable
quantity
of
the
product.
The
debt
I
created
the
dedicated
ticket.
For
that,
where
I
propose
to
create
a
saga
like
it
is
pretty
much
what
we
want
to
do
in
in
our
activity
for
the
service
isolation.
D
So
the
main
idea
that
we
will
like
the
main
issue
here,
that
we
can't
make
the
the
single
scope
for
our
transaction
and
we
can
combine
the
shipment
reduction
and
we
can
combine
a
reservation
creation
in
the
same
scope
of
the
database
transaction
because
potentially
reservation
should
be
like,
should
be
created
in
this
Co
one
database
in
the
scope
of
the
one
domain
and
the
ship
in
supposed
to
be
created
in
scores.
Another
one,
though,
that
it
should
be
done
like
this.
D
We
supposed
to
have
two
local
transactions
combined
is
go,
perform
business
event,
and
if
there
is
there
are
gonna,
be
some
problem
happens
with
a
shipment
creation.
We
just
need
to
compensate
our
compensation
production,
so
this
is
the
main
idea.
So
you
know
like
increasing
in
our
pitch
blog
of
the
of
the
exception
which
handles
their
signal
creation.
D
D
Because
for
many
merchants
it's
really
like
valuable
information.
And
currently
we
just
provide
an
ability
to
see
what
source
has
been
used.
If,
if
merchants
will
just
narrow
down
to
a
particular
ordinal
page
and
see
on
the
order
detail
page
what
a
data
source
is
in
use,
but
this
information
currently
not
provided
in
discovered
or
agreed.
So
Steve's
like
ask
whether
it's
possible
to
implement
oscilloscope
of
them
aside,
so
I
just
created
that
the
ticket
so
mark
and
evaluated
make.
D
On
the
common
room
like
whether
it
makes
sense
or
not,
and
the
variation
for
this
and
the
last
but
not
least,
those
is
pretty
interesting
because
we
had
like
a
big
shot
to
these
guys
from
next.
Yes,
so
they're
currently
working
on
all
the
side
customization
and
they
made
right
top
which
they
published
like
three
days
ago
and
in
the
scope
of
this
write
jobs.
They
described
their
particular
business
case
and
actually
the
main
the
main
issue.
D
They
wanted
to
highlight
that
they
brought
their
particular
business
case
when
they
have
to
two
warehouses,
one
of
those
in
Germany
know
and
other
one.
In
French.
They
have
pants
and
shorts
which
are
located
on
Drummond
warehouse.
They
have
just
pants
on
the
French
warehouse
and
they
are
for
their
particular
business
case.
They
wanted
to
provide
an
ability
for
Drummond
website
to
sell
just
items
located
at
Drummond
warehouse,
but
for
French
website.
B
D
D
Actually
it
replicates
t-shirts
only,
but
the
problem
with
this
setup
is
that
they
have
dated
application
between
the
German
source
and
the
Drummond
four
French
source,
because
Drummond
source
is
kind
of
more
broader.
It
contains
both
t,
shirts
and
pants,
while
the
German
for
French
source
contains
only
only
shorts.
That
is
the
order
like
if
they
like.
If
the
shipment
will
imply
just
shorts,
they
need
to
update
data
in
both
sources,
esource
and
D,
for
French
source,
the
third.
D
They
make
a
conclusion
that
there
is
something
wrong
with
MSI
and
we
have
a
chart
with
these
guys
here,
so
that
I
described
a
better
way.
How
that
particular
particular
setup
can
be
created
for
them,
and
the
thing
correct
and
the
probably
a
deal
degradation
here
would
be
to
create
three
different
sources
and
put
like
great
Drummond
source.
But
the
German
source
will
contain
just
hands
and
pain.
French
source
and
the
train
source
will
contain
dust
pans
as
well
and
the
great
another
source
which
would
be
probably
physically
located
in.
D
This
source
will
allocate
just
shorts
and
the
regarding
this
talk
to
source
assignment.
Each
stop
will
have
two
sources
assigned
to
them
like
the
Drummond.
Stove
will
have
Force,
One
and
source
three
and
the
French
stock
will
have
like
source
2
and
the
source
free,
and
in
this
case
we
don't
have
dated
application
and
we
can
place
order
to
either
one
of
those
stocks
and
buy
a
customer
from
French
can
be
making
delivery
of
shorts
from
drawing.
So
this
case,
why
I
wanted
to
highlight
the
skids.
B
D
The
quantity
per
source
item
should
be
synchronized
between
deutsche
source
and
deutsche
for
french
source,
because
we
have
the
duplication
of
the
sausage
shorts
quantity
here
and
here
and
in
fact
we
have
like,
like
the
source
item
montague,
we
have
the
tool
source
item
objects,
but
in
fact
they
represent
the
single
source
item
which
they
have
in
reality
and
the
possibility
of
the
inconsistencies
very
high
here.
So
that,
like
you,
need
to
you
need
to
avoid
of
such
customization
as
much
as
possible.
So
this
is
probably
pretty
much
all
from
my
site.
A
D
You
don't
have
a
particular
design,
because
even
it's
erratically,
there
are
two
main
design
patterns
which
would
which
could
be
applicable
for
sagas.
First,
one
is
orchestration
bass
awaken
this
slide.
You
can
see
it
could
be
our
castration
bass.
This
means
that
we
have
the
orchestrator
are
kind
of
like
the
vending
machine
or
the
state
pattern.
D
So
there
is
some
controlling
point
which
proceeded
from
one
operation
to
another
like
like,
let's
consider,
for
example,
order
replacement.
So
we
have
the
decision-making
point
and
this
point
make
sure
that
each
particular
small
small
transaction
is
finished
successfully
and
then
the
internal
state
switch
to
another
one,
and
we
can
proceed
to
another
another
logical
protection
and
the
after
that
all
the
local
transaction
will
be
fulfilled.
We
can
complete
the
whole
business
transaction
now
it
is
possible,
but
here
what
would
it
would
count
we?
D
D
So
this
is
much
better
from
the
scalability
point
of
view,
but
a
little
bit
more
complicated
to
synchronize
is
even
all
of
those
transactions
and
to
check
whether
the
whole
business
transaction
was
completed
successfully,
though
we
are
still
considering
which
approach
is
better
like
in
general,
but
I
believe
for
each
particular
is.
We
will
use
particular
implementation
of
second,
so
here
we
can
discuss
the
one
which
is
more
suitable
for
this
particular
case,
I.
Believe
in
this
particular
case
it
would
be.
D
It
would
be
pretty
much
simplistic
that
we
don't
have
lot
of
a
lot
of
local
transactions,
but
we
have
just
one
like
here:
we
have
just
a
two
transaction.
The
first
one
is
the
shipment
creation
and
we
supposed
to
track
of
the
shipment
creation
finished
and
based
on
those,
like
actually
I,
believe
in
you
to
track
the
catch,
the
exception
thrown
after
the
after
the
different
creation
and
the.
If
something
went
wrong,
we
need
to
handle
this
appraiser
properly.
We
are
the
respondent
compensation,
also
tax.
D
It
should
not
be
really
to
to
complex,
like
it
is
described
here,
for
example,
of
these
slides,
but
it
should
be
pretty
simplistic
and
we
just
need
to
track
all
all
the
possible
exceptions,
and
also
we
may
need
to
investigate
it
better
on
a
source
code.
So
whether
we
have
just
one
or
several
potential
exceptions
thrown
after
after.
D
B
A
C
C
The
question
is,
since
this
kind
of
UI
is
pretty
new
far
as
I
know,
to
Magento.
The
dub
is
how
we,
how
do
we
handle
the
fact
that
in
this
particular
case,
the
merchant
could
select
a
stop
change?
Some
other
options,
change
stock
against
us
change.
Other
options
do
these
again
and
again
for
each
stock,
and
these
information
is
not
saved,
probably
until
it
leaks
done
and
then
saves
the
little
product
page.
C
So
what
we
probably
need,
Europeans
trying
to
figure
out
the
best
possible
design
not
to
confuse
the
merchants
because,
for
example,
switching
between
different
stocks
and
changing
configuration
options
doesn't
necessarily
make
it
clear
that
those
options
are
memorized
for
subsequent
save
or
maybe
they
have
to
be
saved
upon
each
change.
Maybe
we
have
to
add
some
Bouton's,
so
I'm,
not
a
UI
expert.
So
what
I'm,
basically
asking
here
is
some
help
from
your
sides
to
define
the
better
interface
that
can
can
help
the
merchants
get
his
data
saved
correctly
without
any
confusion.
B
B
C
C
F
A
C
C
C
C
C
C
B
A
Like
the
way,
if
this
was
much
more
productive
than
we
expected
initially
at
least
we
are
having
some
conversations
kicked
off
regarding
this
question,
though,
if
we
don't
have,
anyone
else
would
like
ask
questions
or
present
something.
Then
it's
time
to
introduce
Tom
with
the
weekly
quality
report
once
once
again
like
like
every
other
week,.
F
Thanks,
Yugi
and
I
think
we've
missed
the
last
week
or
two,
but
we're
back
and
just
a
brief
update
this
week.
A
couple
of
things
to
highlight
so
hopefully
she'll
have
my
screen
there.
Let
me
put
this
into
a
presentation
yeah.
We
can
see
it
right
there.
We
go
that's
more
like
it.
Okay,
so
last
ima,
what
we're
talking
about
automated
testing
wise.
F
So
this
is
one
of
the
headline
features
here,
so
we're
always
looking
for
these
lines
to
chart
up,
as
you
can
see,
between
the
24th
and
the
31st,
and
the
total
tests
in
blue
and
the
not
automated
some
manual
tests
yet
to
be
automated
and
have
tracked
dyeing
know
the
reason
for
that
is
not
that
we
have
less
test.
We
in
fact
have
about
five
more
tests
to
find
in
that
period,
but
we
have
rationalized
em
our
testing
and
test
reporting
and
we're
starting
to
break
out
integration
and
Web
API
testing,
where
it's
appropriate.
F
So
these
numbers
and
I
give
a
more
accurate
reflection
of
our
functional
and
functional
backlog
so
that
the
total
number
of
tests
that
were
reporting
on
for
this
nigh
until
it's
broken
out
further
is
the
total
number
of
tests
that
are
functional,
front-end
tests,
not
web
api
or
integration,
which
is
why
those
numbers
of
track
down,
but
it
gives
us
a
true
place
for
our
gray
automate
a
number
to
track
up
to.
So
these
are
the
new
numbers.
F
That's
why
that
is,
and
in
coming
weeks,
if
it's
necessary
or
useful,
we
can
also
plot
sort
of
the
gap
that
we've
taken
out
there.
There's
Web
API
functional
tests.
We
can
track
them
separately
or
on
a
combined
graph,
but
for
now
this
is
just
home
down
to
only
functional,
that's
where
the
numbers
are
Gandhari,
but
in
reality
they
really
haven't.
F
So
that's
worth
noting
another
point
in
that
we
haven't
tracked
up
with
track
149
to
155
for
the
automation
numbers
and
that
that's
happened
over
sort
of
the
last
three
weeks
where
we
have
been
able
to
bridge
reports
because
I've
been
out
of
the
office
and
things,
and
so
it
wasn't.
Six
out
of
this
weeks,
it's
six
been
added
over
the
last
two
weeks:
okay
as
severity
and
component.
F
While
those
numbers
have
gone
down,
the
proportions
are
almost
identical,
as
we
haven't
lost
any
coverage
in
our
major
areas
of
focus,
cut
log
and
seals
in
terms
of
manual
testing,
then
so
again
by
component
catalog
and
seals
primarily,
but
what
we're
looking
at
with
the
manual
testing.
So
this
is
a
chart.
That's
all
blue
for
pass.
Know
people
like
to
scream
but
I
like
to
use
blue
and
what
this
showing
us
is
our
last
regression
cycle.
F
We
passed
all
that's
important
to
know
in
the
fact
that
we've
run
three
and
individual
smaller
regression
cycles
over
the
last
month,
along
from
the
one
one
to
release
and
forward
and
our
initial
sort
of
start
of
the
month
report.
Back
three
weeks
ago
and
four
weeks
ago,
we
were
running
into
somewhere
between
five
and
nine
percent
failures
identified
and
now,
as
we
rerun,
everything
in
fixes
are
made
we're
back
to
a
full
pass
status
for
the
latest
set
of
executions
that
we
did
so.
F
As
you
say,
it
is
all
green,
but
that
is
coming
off
the
back
of
several
failures
out
of
about
a
month
ago,
so
we
have
identified
and
track
their
might,
and
these
regression
cycles
have
been
and
very
useful
in
identifying
bugs,
and
then
you
know
bringing
this
back
up
to
a
full
pass.
Otherwise,
that's
it
for
this
week
and
we'll
have
more
next.
Unless
anyone
has
any
questions,
I'll
stop
it
there.
A
We
were
expecting
Rodrigo
to
give
a
presentation
on
their
implementation
for
their
customer,
but
unfortunately,
due
to
some
technical
issues,
we're
gonna
have
to
postpone
that
to
the
next
week,
so
please
guys
tune
in
next
week.
The
demo
is
going
to
be
big
and
really
interesting,
because
we
already
have
some
content
for
the
next
Friday
and
that's
it.
Thank
you
very
much.
Everyone
have
a
great
weekend
and
have
a
great
rest
of
the
day.