►
From YouTube: Elsa Workflows Community Meeting 5 ( 2022-04-19 )
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
I've
been
working
on
activity
signaling,
which
is
a
a
way
to
communicate
between
activities
when
something
is
done
or
when
something
needs
to
happen.
An
example
use
case
is
the
signaling
of
a
completion
of
a
child
activity
so
that
a
container
activity,
like
sequence,
knows
when
to
schedule
its
next
child
or
when
it
as
a
whole
is
finished
so
that
it
can
explicitly
mark
its
own
or
signal
its
own
completion.
So
that's
one
use
case.
A
Another
use
case
is,
for
example,
the
break
activity
in
combination
with
four
for
each,
and
while
you
can
imagine
that,
if
you
have
a
performance-
and
you
have
some
condition
within
this
for
loop,
where
you
want
to
break
out
of
the
for
loop,
you
can
use
the
break
activity
in
lc2
and
also
3.
We
need
the
same,
but
it's
going
to
be
implemented
using
signaling
in
elsa
2,
it's
more
hard
coded
and
there's
pieces
of
code
external
to
the
activities
that
set
or
manipulate
state
of
parent
activity.
A
So,
for
example,
here
we
have
a
brake
activity.
It's
a
very
simple
one.
All
it
does
is
send
a
signal
called
the
brake
signal,
which
is
nothing
more
than
a
vocal,
not
even
a
field.
So
this
represents
a
signal.
It
could
carry
some
more
data
if
applicable.
But
that's
not
the
case
here,
and
the
nice
thing
about
this
is
that
the
brake
activity
itself
doesn't
need
to
know
anything
about
for,
while
for
these
activities,
but
of
course,
those
activities
they
they
listen
basically
for
the
break
activity.
A
So
here
let's
take
the
the
four
activity
which
models,
the
c,
sharp
four
statement
and
basically
iterates
from
a
start
value
until
an
end
value
using
a
step,
and
if
you
want
to
break
out
of
such
a
loop,
you
use
the
brake
activity
and
this
activity
will
then
listen
for
it.
So
here
it
registers
a
handler
for
the
brake
signal.
So
when
the
brake
signal
is
received,
it
doesn't
matter
how
deep
the
hierarchy
is.
So
you
could
have
a
for
example,
you
could
have
a
forward
loop
somewhere
in
your
workflow
and
then
within
the
iterate.
A
The
the
body
brands
where
you
put
in
your
the
codes,
basically
that
you
want
to
execute,
could
be
a
flowchart
could
be,
could
be.
A
simple
activity
could
be
very
complicated
activity,
doesn't
matter
how
deep
it
goes,
but
at
some
point,
if
there's
a
break
activity,
that
break
signal
will
bubble
up
this
hierarchy.
So
it's
kind
of
similar
to
a
dom
event
in
a
document.
Object
model.
It's
it's
inspired
on
that.
A
But
of
course
it's
not
exactly
the
same,
but
the
nice
thing
is
any
activity
in
the
r
key
can
listen
and
respond
to
a
signal.
So
here
the
four
activity
will
respond
to
it,
using
an
on
break
private
handler
which
isn't
fully
implemented.
Yet
it
just
for
now
says
stop
propagation,
so
that
if
you
have
yet
an
outer
four
construct
or
a
looping
construct,
you
don't
want
it
to
break
out
of
sight
of
that
as
well.
So
so
I'm
working
on
this
little
api
too,
to
be
able
to
control
when
to
stop
this
propagation.
A
This
bubbling,
what's
yet
to
be
done,
is
this
some
some
instrument,
some
instructions
set
to
allow
the
this
activity
to
actually
cancel
everything
else
has
been
scheduled
as
below
this
or
as
as
a
child
brands
of
this.
This
activity
here
I
mentioned
test.
So
let's
look
at
these
tests
here.
Well,
the
four
e's
workflow
test
will
fail
so
jump,
but
just
to
demonstrate
what
it's
supposed
to
do.
So
here
we
have
a
sample
workflow.
A
It
starts
with
a
sequence
which
contains
just
one
activity
called
a
four
heats,
and
this
for
each
will
or
well
for
eats
each
item
that
it
receives
in
its
constructor.
It
will
execute
a
writeline
and
then
the
idea
is
is
that
it
at
some
point
will
break,
must
have
updated
this.
I
thought
I
had
a.
It
would
look
like
this.
Let's,
let's
take
an
if-
and
this
would
have
some
condition
and
if
that
condition
evaluates
to
true,
let's
say
we
then
want
to
break
out
of
it.
So
that's
that's
the
idea.
A
Otherwise
we
do
a
right
line,
let's
say-
and
this
of
course
would
be
based
on.
Maybe
the
current
item
doesn't
matter
this
test
currently
fails
because
the
the
four
each
does
not
actually
implement
the
break
the
breaking
construct
yet,
but
that's
a
work
in
progress
and
I
mentioned
being
able
to
complete
container
activities
like
sequence,
the
sequence
activity
should
only
complete
once
its
children
have
completed.
So
here
we
have
another
sample
workflow
again,
starting
with
a
sequence,
then
a
sequence
of
activities,
one
of
them
being
another
sequence.
A
The
expectation
is
is
that
we
would
see
write
lines
from
start,
then
line
one
through
three
and
then
end,
and
this
actually
works
and,
as
you
can
see
in
the
output
start,
one
two
three
and
and
without
the
the
activity
signaling
it
wouldn't
work.
What
would
happen
is
you
would
see
start
and
then
maybe
line
one
and
then
end
and
then
line
two
and
three.
So
it's
it's.
It's
a
more
flexible
way
of
implementing
it
before
this.
This
was
this.
A
This
activity
signaling
it
was
working
as
well,
but
using
a
more
rigid
implementation,
which
I
can
show
you
quickly.
So
here
we
have
the
activity
invoker
middleware,
which
is
responsible
for
actually
well.
This
is
basically
the
inner
loop
that
works
on
the
stack
of
activities
to
execute
and
then
at
the
end
of
that
inner
loop,
it
would
try
and
complete
its
parents
and
completing
its
parents
means
whenever
an
activity
finished.
A
So
that's
in
progress
for
elsap2.
I
worked
on
a
little
thing,
called
workflow
compensation
and
what
is
workflow
compensation?
That's
that's
what
you
do
when
your
workflow
falls,
but
the
workflow
has
already
performed
some
work.
Maybe
it
created
a
flight
reservation
which
are
actually
credit
cards,
but
something
happened
later
on
and
now
you
want
to
undo
or
roll
back
those
those
steps.
So
here
is
an
example
from
windows,
workflow
foundation,
which
describes
the
process
of
compensation
and
how
that
compares
to
transactions.
A
It
talks
about
a
the
compensable
activity
in
in
windows,
overflow
foundation,
and
that's
what
I
took
as
an
inspiration,
including
the
the
example.
So
here
they
have
a
a
flight
booking
workflow.
Basically,
so
this
this
new
activity,
it
has
a
bunch
of
outcomes.
The
body
outcome
represents
the
work
that
you
want
to
do.
That
can
be
potentially
be
rolled
back,
but
the
rollback
would
be
done
through
the
compensate
output
and
the
compensate
outcome
is
scheduled
as
soon
as
as
the
workflow
faults
or
an
activity
faults.
A
Then
this
gets
executed
and
I
think
I
have
a
small
example
for
that.
Maybe
it's
easy
to
just
show
that
demo
to
see
it
in
action,
so
this
is
almost
literally
the
same
sample
workflow
used
in
the
wf
documentation.
So
what
do
we
have
here?
We
have
the
compensable
activity
which,
when
it
executes,
will
execute
a
body
outcome,
and
here
what
we
do
is
we
charge
the
credit
card
reserve
a
flight
and
then
one
once
the
body
executed.
A
Then
it
will
just
continue
with
whatever
comes
next,
so
then
we
have
a
manager,
approval
activity
and
then
we
are
simulating
a
fault,
and
this
is
another
new
activity
that
allows
you
to
fold
the
workflow
from
within
the
workflow,
without
having
to
throw
an
exception
which
still
works,
of
course,
but
this
is
another
way
to
to
fault
your
workflow
and
you
can
provide
a
error
or
a
message
with
that.
So
whenever
this
executes
the
workflow
will
enter
a
defaulted
state
and
when
that
happens,
the
compensator
outcome
will
execute
of
this
compensable
activity.
A
A
So
here
we
see
the
credit
card
for
the
flight
has
been
charged,
flight
has
been
reserved,
managed
approval
received,
but
then
a
fault
happened
and
that
causes
the
cancellation
of
the
flight
and
the
cancellation
of
the
credit
card
charges.
And,
of
course
this
also
works
in
the
designer,
and
I
think
I
may
have
even
prepared
a
design,
but
I'm
not
sure
if
I
used
it
with
the
monolith
or
the
the
server
sample
perfect,
but
let's
find
out
well,
I
think
I
deleted
the
workflow,
but
that's
okay.
Let
me
just
create
it
from
scratch.
A
A
A
The
fault
activity
has
no
outcome
because
there's
nothing
to
do
once
your
workflow
falls
for
some
reason
you
do
want
to
execute
something,
or
even
just
have
a
something
visual
to
just
to
show
what
you
wanted
to
do
like,
for
example,
in
this
demo.
You
can,
of
course,
just
use
the
javascript
activity
and
throw
a
new
error,
but
this
will
cause
a
fault,
and
then
we
can
pretend
something
you
know
what
what
else
do
we
want
to
do
here
and
that
is
purchase
the
flight?
A
Ultimately,
we
want
to
take
the
flight
and
once
the
flight
has
been
taken,
then
even
if
the
workflow
should
fault
after
this.
In
this
example,
it
would
not
make
sense
for
the
compensable
activity
to
compensate
the
process,
because
it
doesn't
make
sense
you're.
You
are
already
on
the
plane.
So
at
that
point,
what
you
will
want
to
do
is
confirm
the
compensable
and
that
will
ensure
that
even
if
the
workflow
falls
hereafter,
the
compensate
brands
will
not
execute.
A
So
for
that
you
need
to
use
the
confirm
activity
and
then
provide
the
name
of
the
compensable
activity.
You
want
to
confirm
yeah,
it's
a
great,
a
great
point.
I
wasn't
sure
myself
either,
but
I
trusted
the
documentation
in
about
work
windows
workflow
and
they
also
talked
about
a
cancel
option.
So
that
happens
whenever
a
fault
occurs
within
the
body.
So
so,
if
that's
a
valid
use
case
scenario
and-
and
I
assume
it
is
because
it's
there
in
documentation-
I
figured
maybe
it
is
useful.
A
But
I
agree:
I'm
you,
you
could
do
everything
here
on
the
dawn
brand
and
it
would
still
execute
the
compensate
brands.
But
then
you
would
not
have
the
ability
to
have
a
separate
cancellation
brands
whenever
this
anything
happens
in
the
body
brand.
So
let's
say
here
something
false.
Then
you
may
want
to
execute
different
logic,
yeah
so
to
confirm
points
back
to
this
compensable
activity
to
confirm
this
one
explicitly
yeah,
absolutely
so
that
that
would
work.
We
could
do
it
like
that,
but
I
would
like
to
get
a
better
understanding
of.
A
Why
did
the
windows
workflow
foundation
team
choose
to
do
it
like
this,
and
I
don't
fully
understand
so
once
I
do
get
that.
I
don't
want
to
miss
anything,
but
if,
if
there's
no
valid
reason
for
doing
it,
this
way
then
yeah
and
then
it
would
seem
simpler
to
have
the
body
execute
to
the
end
automatically
confirm
the
compensable
activity,
but
the
thing
with
the
compensating
windows
workflow
foundation.
It
doesn't
confirm
this
one.
A
Never
unless
you
explicitly
do
in
this
context
of
elsa,
which
makes
sense
for
when
you
look
at
other
activities
like
if,
for
example,
n4
they
have
well
the.
If
has
a
true
and
a
false
branch,
and
once
either
of
those
have
fully
executed,
then
the
the
final
outcome
that
done
outcome
is
scheduled.
I
can
imagine
that
you
would
expect
something
similar
here.
As
you
say,
body
would
be
whatever
happens
now
and
done.
If
something
happens
here,
then
the
compensate
branch
executes
and
if
nothing
bad
happens,
nothing
falls.
A
Then
the
done
happens
and
then
implicitly
compensable
would
have
to
be
confirmed,
which
means,
if
something
falls
in
the
done
branch,
it
will
not
evolve
compensate
similar
or
maybe
they
say
the
same
thing
that
trunks
just
described
yeah.
We
can
think
about
it.
I
I
kind
of
like
that
it
seems
more
natural
here.
So
let's,
let's
give
that
some
more
thought,
so
what
they?
What
they
just
describe,
is
if
let's
say
now
that
let's
say
something
happens
here,
let's
say
you
have
something
happening
and
and
then
it
goes
wrong.
Where
did
it
go?
A
What
okay?
Let
me
refresh?
Oh,
oh
yeah,
this
is
my
favorite
feature,
the
random
switching
of
the
outcomes
and
it
happens
when
you
don't
expect
it
and
then
yeah
okay.
So
here
it
is
the
body
this
folds
and
then
because
this
falls
in
the
body
brands,
then
the
cancel
will
execute.
And
let
me
let
me
show
you
so
here.
Let's
say
it
charges
a
credit
card.
Now
something
goes
wrong.
So
all
we
need
to
do
is
cancel
the
credit
card
charge.
A
Oh,
if
that
works,
then
if
we
run
this
workflow,
it
will
go
from
compensable
to
body
charge,
credit
card
fault
and
then
schedule
the
cancel
brands.
So
that's
what
happened
and
that
and
it
does
not
schedule
the
done
outcome,
because
it's
now
altered
and
stuff
has
been
cleaned
up,
but
it's
not
going
to
continue
so,
as
you
can
see
in
the
well,
you
can't
see
the
journal
here
right
now.
That's
an
open
issue
by
the
way,
but
let's
go
to
the
workflow
instance
viewer.
A
A
Let's,
let's
give
it
some
thought
and
then
we
can
make
make
a
change
if
you,
if
you
think
that
makes
more
sense
yeah,
but
wouldn't
you
be
able
to
do
the
same?
Let's
say
we
charge
a
credit
card,
we
reserve
flight
and
then
let's
say
this
still
fails.
But
what
if
we
again
just
do
the
the
compensator
here?
What
would
happen
it
would
try
to
cancel
flight
which
has
not
yet
been
reserved.
So
then
this
might
fail.
Actually-
and
here
it
doesn't
try
to
cancel
the
fight.
That's
right!
A
You
can
use
the
compensativity
more
than
once,
of
course
yeah.
So
that's
that's
a
good
point.
There's
actually
also
a
compensate
activity
to
it
to
let
you
explicitly
compensate
a
compensable
activity
which
is
similar
to
our
fault,
but
it
doesn't
default
to
the
workflow.
It
just
cancels
the
workflow
and
after
executing
the
compensable
compensate
outcome
of
whatever
you
specify
here
yeah.
So
it's
at
the
very
least,
it's
quite
flexible.
So
that's
yeah.
That's
a
new
feature
for
2.7.
It's
right
now
available
in
my
gut
and
then
the
next
version.
A
You
should
be
able
to
enter
as
a
as
a
user
every
five
seconds
between
10
and
11,
and
then
it
should
generate
the
current
expression.
That
would
make
sense
something
similar
is
done
for
the
types
or
the
javascript
intellisense
support
with
autocomplete.
What
it
does
it
it.
It
uses,
typescript
definitions
so
which
are
dynamically
generated
server
sites
for
this
you
would
need
something
similar,
probably
so.
This
workflow
starts
with
two
triggers
one,
the
chrome
and
then
a
signal
received.
A
But
when
a
when
you
start
a
workflow
with
signal
received
it's
so
here,
you
configure
it
to
listen
for
tests.
Then,
at
this
point
it's
not
correlated,
but
once
it
executes
that
it
works,
like
instance,
should
be
correlated
with
this
one.
That
sounds
like
a
bug,
because
it
this
should
work
in
theory.
You
should
be
able
to
start
a
new
instance
from
within
this
workflow,
but
using
this
trigger,
and
that
should
just
work
and
if
it
doesn't
means
it's
broken.
So,
if
you
remove
this
line,
then
it
works
yeah.
A
So
what
should
happen
when
you
trigger
a
workflow
while
also
providing
a
correlation
id,
then
two
things
can
happen.
One
would
be,
let's
say,
a
workflow.
A
new
workflow
instance
gets
created
because
a
workflow
was
found
that
uses
the
specified
activity
type
as
its
starting
activity.
So
that's
a
trigger,
so
it
should
then
instantiate
that
workflow
create
a
workflow
instance
and
correlated
by
whatever
correlation
the
d
was
specified.
So
that's
one
two.
If
an
existing
workflow
instance
is
found
by
that
correlation
id,
then
that
one
executes
yeah.
A
I
think
it's
if
it
finds
an
existing
instance
of
the
specified
workflow
definition.
Then
it's
going
to
trigger
that
workflow
instance
and
it's
not
going
to
instantiate
a
new
one,
even
though
you
are
yeah
in
this
case.
It's
it's
a
trigger,
so
I
we
we
might
have
to
change
this,
that
it
also
uses
as
a
trigger
which
should
happen,
but
clearly
it
doesn't
yeah.
If
it's
the
same
correlation
d
for
the
same
workflow
definition,
then
it's
what
it
will
use
the
existing
one.
A
It
will
not
create
a
new
one
with
the
same
correlation
id
as
it
is
yeah.
We
can
talk
about
that.
But
yes,
that's
the
design,
but
we
can
talk
about
it.
Talk
about
why
it
makes
sense
or
why
it
does
not
make
sense
and
to
also
talk
about
other
use
case
scenarios
where
it's
actually
desired,
that
there's
no
duplicate,
workflow
instances,
because
there's
use
case
scenarios
where
you
want
unique
workflows,
because
a
workflow
is
correlated
with
a
unique
customer,
let's
say,
and
then
you
don't.
A
You
may
not
want
to
have
another
workflow
instance
with
this
customer
which,
depending
on
your
scenario,
might
be
interpreted
as
a
as
an
issue
or
as
a
bug
yeah.
Let's
talk
about
when
it
makes
sense
when
it
does
not
make
sense
and
and
how
to
control
that,
because
you
clearly
have
a
scenario
where
it
actually
makes
sense,
so
we
need
to
find
a
way
where
we
can
do
so.
We
should
start
with
describing
the
expected
behavior
and
then
see
if
that's
actually
the
case,
and
in
here
maybe
that's
not
maybe
it's
doing
something.