►
From YouTube: Elsa Workflows Community Meeting 6 ( 2022-04-26 )
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
B
A
Of
course,
yeah
no
worries.
So,
let's
look
at
the
history
yeah
today
I
fixed
the
blog
in
ls2
and
added
support
for
reading
a
data
set
from
the
sql
query
activity,
and
actually
I
want
to
show
this
and
also
in
combination
with
a
question
that
once
asked
about
input
output
storage,
how
to
deal
with
large
objects
in
in
elsa
wordpress.
So
we
can
combine
that
a
little
bit.
So
this
issue
was
an
interesting
one.
A
Basically,
the
thing
that
happened
is
if,
if
you
have
a
workflow
that
branches
into
two
brands
of
execution,
for
example,
using
a
fork
activity
and
one
branch
performs
some
some
job
for
maybe
it
blocks
some
some
activity.
In
this
case
it
was
using
a
telnets
activity
to
wait
for
an
audio
file
to
complete
playing,
and
the
other
brands
was
then
waiting
for
some
user
input,
so
the
user,
while
being
on
the
call
they
can
press
one
of
the
digits
on
the
keypad.
A
So
this
workflow
will
be
blocked
in
two
activities
and
then
at
some
point
one
of
those
activities
would
resume
and
if
the
outcome
of
one
of
those
activities
is
that
the
user
was
no
longer
connected
on
the
phone,
the
outcome
would
be
call
inactive
or
something
like
that.
And
then
I
wanted
to
finish
the
workflow.
So
then,
I
would
attach
a
finis
activity
to
that
outcome,
with
the
expectation
that
that
would
end
the
workflow
and
no
longer
waiting
for
that
key
keypad
input
to
arrive.
A
What
happened
is
that
the
workflow
would
remain
suspended
on
the
other
one
and
the
keypad
blocking
activity,
and
the
issue
was
that,
because
that
activity
was
already
scheduled,
it
would
rem,
it
would
keep
adding
a
blocking
activity
or
it
was
already
added
and
if
there's
an
at
least
one
blocking
activity
in
the
workflow
execution
context,
then
the
workflow
will
not
be
marked
as
completed.
It
will
remain
suspended.
So
that
is
fixed
with
this.
With
this
update
here.
C
B
A
Yeah
in
most
cases,
that
is,
that
is
true.
What
the
joint
activity
will
will
do.
It
will
clear
out
any
and
all
blocking
activities
in
between
the
join
activity
and
the
previous
fork
activity.
So
if
you
have
three
branches,
let's
say
two
timers
and
one
signal
and
the
signal
gets
triggered,
then
it
will.
The
joint
activity
will
make
sure
that
the
two
timer
activities
will
be
cleared
so.
A
Yeah
then
no,
then
it
will
be
fine,
because
the
joint
activity
will
have
would
have
cleared
the
blocking
activities,
but
the
the
fitness
activity
actually
think
of
it.
The
finish
activity,
I
think,
also
clears
blocking
activities.
However,
if
the
it
it's,
it
was
a
timing
issue.
So
if
the
other
activity
that
wood
block
executes
after
the
finish
activity
or
the
the
activity
before
the
finish
activates
or
the
other
blocking
activity,
actually
I
should
just
show
you
it's
easier
than
me
trying
to
talk
in
the
air.
So
it's
this
situation
here.
A
A
But
if
let
me
try
and
remember
the
exact
detail
or
the
the
sequence
of
events,
but
what
would
happen
is
that
this
finish
activity
would
have
executed
and,
after
the
finish
activity
executing
this
activity
will
execute
and
this
one
will
create
a
bookmark
and
add
itself
as
a
blocking
activity
and
because
there's
a
blocking
activity
after
this
executed,
the
finish
activity
tries
to
delete
the
blocking
activities,
but
once
that's
done
and
this
activity
executes
and
then
adds
a
blocking
activity,
the
workflow
will
not
end.
So
that's
yeah.
A
That
was
that
was
the
issue
here,
because.
B
A
B
And
okay,
my
second
question
is
about
the
finish
activity:
is
it
mandatory
to
have
this
finished
activity
in
the
end
of
the
workflows,
because
normal
dot
included
door
closed.
A
A
Automatically,
but
when
you
may
want
to
use
that
is,
for
example,
when
you
are
in
a
loop
or
here
that
this
is
a
very
long
workflow,
but
let's
see
so,
for
example,
here
is
a
for
each
loop
and
it's
it
may
loop
for
well,
it's
it's
actually
gonna
loop
indefinitely,
because
this
this
will
it's
not
being
cleared.
So
it's
going
to
iterate
and
then
oh
once
this
one
is
done.
It
will
go
back
to
the.
If
and
then
this
is
done
and
then
here
it's
in
an
infinite
loop.
A
So
here
I'm
in
an
initial
group.
So
without
the
finish
activity
the
workflow
would
never
end.
So
if
you
have
a
construct
like
this,
then
having
a
fitness
activity
makes
it
easy
to
just
end
the
workflow
and
when,
in
this
case,
when
do
I
want
to
finish
the
workflow
whenever
the
call
is
no
longer
active.
Okay,.
C
Yeah,
thank
you,
but
does
that
mean
that
when
you
use
a
finish,
if
you
have
any
blocking
activity
somewhere
else
in
the
that's
gonna
be
erased
and
then
it's
gonna
be
finished
right?
That's.
C
A
Yeah
process,
okay,
yeah
and
it's
also
potentially
convenient.
If
you
have
complicated
four
workflows
and
then
you
don't
want
to
be
using
a
joins,
but
just
have
parallel
paths
of
execution
and
at
some
point
you
reach
some
condition
that
should
terminate
the
workflow.
Then
the
finish
activity
is
great,
because
then
you
don't
have
to
merge
back
into
a
join
activity.
So
it's
convenient
in
certain
circumstances.
So
this
is
a
an
enhancement
to
the
the
gen
evaluation
results
converter.
So
what
what
does
this
thing?
Do
it's?
A
Basically,
when
a
bit
of
javascript
executes
it
may
return
a
result
and
that
result
is
then
tried
to
be
converted
into
a
target
type,
and
this
is
used
when
you
have,
for
example,
for
example:
there's
a
execute
sql
query
and
this
this
activity
has
the
following
output:
a
data
set.
So
before
this
changed
here,
this
data
set
was
not
supported,
so
so
the
javascript
engine
would
throw
an
exception
that
you
know.
A
The
thing
needs
to
need
to
be
convertible
to
our
eye,
collection
of
objects,
and
that
exception
would
occur
not
in
this
activity,
but
in
the
for
its
activity,
because
the
input
of
the
four
heats
this
items
property-
is
of
type
a
collection
of
objects,
but
the
output
here
is
a
data
set,
so
the
intuition
of
the
developer
ran
into
this
was
well
it's
a
data
set
and
it
implements
I
list
source.
So
it
should
just
work,
but
highly
source
was
not
being
handled.
A
But
the
next
issue
which
is
not
solved
here,
is
that
the
data
set-
it's
not
it's,
although
it's
serializable,
you
cannot
deserialize
it
because
it
uses
certain
objects
that
have
internal
constructors.
So
if
it
ends
up
in
your
workflow
instance
in
the
database,
then
your
designer
and
the
dashboard
is
broken,
which
is
a
separate
issue
to
fix.
But
so
you
wouldn't
be
able
to
look
at
the
screen
anymore,
because
then
the
system
would
try
to
deserialize
a
bit
of
json,
which
it
could
not
do
because
the
specified
type
as
an
internal
constructor.
A
So
that
would
fail.
So
that's
clearly
a
that's
bad
situation.
If
you
do
want
to
work
with
a
data
set,
you
can
you
just
need
to
make
sure
that
the
output
of
this
activity
is
not
stored
in
the
workflow
instance,
but
instead
stored
elsewhere.
So
in
this
case
I
updated
execute
sql
activity,
so
you
can
no
longer
configure
the
output,
because,
right
after
this,
this
particular
change,
it
specifies
a
default
workflow
source
provided
using
the
transient
warfare
source
provider
and
it
disables
the
selection
of
a
workflow
provider
from
the
ui
using
this
property
here.
A
So
before
this
change,
you
could
choose
to
use
a
workflow
instance
as
a
storage
or
blob
storage,
but
now
this
is
disabled.
We
may
reconsider
this,
but
what
should
be
prevented.
Is
the
user
selecting
the
workflow
instance
of
the
provider
unless
we
actually
implement
a
json
converter
that
is
able
to
convert
or
serialize
a
data
set
and,
of
course,
deserialize.
A
The
data
set
without
it
using
the
sql
activity
is
quite
dangerous
because
it
will
break
the
system,
but
again
that's
a
separate
issue
that
needs
to
be
handled
elsewhere
separately,
because
we
can't
have
the
entire
system
broken
because
of
one
broken
workflow
instance.
Obviously,
so
that's
a
thing
to
be
fixed
yeah.
With
this
this
little
converter,
this
gent
result
converter.
We
can
now
actually
use
the
execute
sql
query
in
a4
heats,
which
now
looks
like
this,
so
you
can
access
the
output
which,
just
to
remind
you,
is
now
in
stored
transiently.
A
So
it's
in
memory
it's
not
stored
as
part
of
the
workflow
instance.
You
can
access
its
tables
and
by
default
that
table
name.
The
name
is
table1,
which
returns
a
a
data
table
object
and
that
table
object
itself.
Has,
of
course,
a
set
of
rows,
a
collection
of
rows
and
the
collection
of
rows
is
being
iterated
on.
So
that
means
the
current
value
through
a
row
and
then
you
can
access
it
its
columns
to
get
back
to
the
workflow
storage.
A
As
I
mentioned,
it's
important
to
configure
the
output
properties
of
of
an
activity
that
returns
an
object
that
you
do
not
wish
to
store.
So
in
the
case
of
the
execute
sql
query
activity,
that's
now
handled
automatically,
you
don't
have
to
do
anything
but
the
for
each
activity
being
a
general
purpose
activity.
You
have
to
take
care
still
of
its
input.
So
this
items
property
is
an
input
property.
A
So
you
need
to
make
sure
that
is
stored,
transiently
as
well,
and
since
it
outputs
individual
items,
assets,
output
that
needs
to
be
stored,
transiently
as
well,
because
the
output
would
be
individual
items
of
a
data
set
or
a
data
table
or
whatever
that
input
is
and
again
that's
just
not
serializable
out
of
the
box.
Does
any
of
this
make
sense.
B
A
B
Like
lots
of
restrictions
in
order
to
use
this
activity
right
now,
yeah.
A
So
what
I'm
wanting
to
do
is
to
let
this
be
up
to
the
user,
where
the
user
needs
to
make
conscious
decisions
of
what
gets
stored
in
what
shape
into
the
workflow
instance
through
workflow
variables.
So
that
means
you
could
have
workflows
that
can
deal
with
any
type
of
objects
that
are
not
serializable
large
files,
for
example,
or
of
course
they
are
still
serializable,
but
you
don't
want
them
to
be
serialized
as
part
of
your
peripheral
instance,
because
that
would
make
it
too
big.
A
In
the
case
of
the
execute
sql
query
activity
where
it
returns
an
object,
that's
not
serializable
or
the
variable
is
not
deserializable
so
to
not
have
to
deal
with
those
things.
Those
in
lc3
those
activities
will
always
return
those
objects,
but
they
will
always
be
transiently.
If
you
want
to
capture
some
details
and
persist
it
as
part
of
your
workflow
instance,
you
have
to
explicitly
do
so
by
storing
it
in
a
workflow
variable
and
then
it's
up
to
you
to
store
it
in
such
a
way
that
it
is
serializable.
D
Do
you
think
maybe
it
would
be
a
more
easy
to
to
work
on
it
or
for
exa3
to
to
make
some
kind
of
streaming
capacity.
D
Okay,
because
for
a
loop,
it
could
allow
us
to
only
read
one
line
per
line
on
the
database.
Yeah
good.
C
A
C
I
think
what
you
said
that
it
was
the
wrong
solution
for
the
right
problem.
Still,
it
makes
sense
to
me
that
you
be
able
to
say
okay
for
this
one.
I
want
to
have
a
transient
and
this
one
I
want
to
have
it
as
a
blob
storage,
for
instance.
The
option
is
still
there
because
then
you
can
take
an
account
from
okay
when
it
recovers.
I
can't
fully
recover-
or
I
have
to
go
back
to
so
many
steps
when
it
recovers
to
start
to
work
again
and
if
that's
even
possible,
yeah.
A
Maybe
this
is
the
right
solution.
I
don't
know
I've.
My
intuition
at
this
point
is
that
this
is
not
the
way
to
go,
but
instead
to
let
the
user
decide
what
are
the
critical
sections
of
a
workflow
where
work
needs
to
be
persisted
in
case
of
disaster,
and
the
warfare
needs
to
start
one
step
ago
or
two
steps
ago.
It
would
be
up
to
the
user
to
to
control
this
more
explicitly.
A
A
benefit
of
else
of
threes
is
that
it's
more
easy
to
encapsulate
sub
activities
to
to
do
this
work,
so
it
wouldn't
necessarily
clutter
your
workflow
as
it
would
today
with
lc2
when
you
have
to
deal
with
these
lower
level
stuff,
potentially
it
it
takes
more
activities
and
it
takes
away
from
the
overall
process
that
you're
trying
to
model
with.
Also
three,
you
can
have
this.
These
nested
activities
more
easily
compose
these
sub
steps.
So
maybe
maybe
it
will
be
better
to
to
look
for
a
different
solution
there,
but
basically.
C
If
I'm
standing
correctly,
is
that
basically
you
say
well,
it's
going
to
be
transient
always,
but
we
can
mitigate
that
by
an
additional
activity
that
can
be
hidden
through
subway
sub
processes
to
have
it
stored
persistently
and
then
it's
a
design
choice
by
the
one.
That's
is
designing
the
process.
Yeah
that
makes
sense.
A
D
B
I
agree
because
I
feel
in
the
current
design
it
is
very
easy
to
accidentally
store
large
amount
of
data
in
the
workflow
instance,
and
then
it
might
go
grow
out
of
hand
what
we
feel
sometimes
that
we
have
to
go
one
by
one
and
change
it
to
transient
and
persist
only
the
critical
information
that
we
want
to
persist
going
to
also
three.
Maybe
that
is
our
right.
C
A
Big
and
yeah
absolutely
I've
seen
that
many
times
I
haven't
prepared
any
demos.
Maybe
if
any
one
of
you
have
a
question
on
a
specific
topic,
maybe
we
can
look
into
that
or
I
can
show
you
the
work,
an
update
with
elsa
3..
So
last
time
we
spoke
a
little
bit
about
activity,
signaling
and
the
brake
activity
that
wasn't
implemented
then,
but
it's
now
it's
implemented.
So
let
me
let
me
just
showcase
that
for
a
bit,
so
this
is
elsa
3.
This
is
a
coded
workflow.
A
We
have
a
simple
4
activity
that
will
iterate
between
zero
to
three
and
then
each
current
value
is
stored
in
a
workflow
variable,
which
is
scoped
just
to
the
it.
It
only
exists
in
the
in
the
four
activity
here
and
then
the
body,
the
the
iterating
body
of
the
for
loop,
performs
a
condition
that
if
the
current
value
equals
two,
then
it
will
break
out
of
the
loop.
Otherwise
it
will
continue.
So
it
should,
in
theory,
never
write
the
value
of
three.
So
for
that
there's
a
unit
test
here
and
that's
this
one.
A
So
here
the
test
verifies
that
indeed
the
output
would
be
start
and
then
0
1
and
then
the
final
one
and,
as
you
can
see
it
executed
successfully,
but
just
to
prove
it
to
you,
but
I
of
course
succeeded
I'll
start
zero
one,
and
but
what
I
want
to
show
you
is
the
the
actual
implementation
of
how
does
one
go
about
implementing
a
break
activity?
So
let's
look
at
the
brake
implementation
first,
which
is
very,
very
simple,
so
it
just
sends
a
signal
called
brake
signal.
A
I
think
we
had
this
the
last
time
as
well,
so
nothing
new
here.
The
interesting
part
will
be
the
activity
that
actually
responds
to
this
break.
So
in
this
case
the
the
four
activity
and
not
just
the
four
activity-
the
sequence
activity,
of
course.
Well,
the
behavior
I
would
expect
to
see
is
that
if
I
break
here
out
of
the
for
loop,
I
would
also
break
out
of
the
sequence
I
would
expect
not-
and
I
wouldn't
expect
another
write
line
like
in
c
sharp
code.
A
Whatever
code
comes
after
the
the
break
statement
should
not
execute
so.
Similarly,
this
should
not
execute
when
this
breaks.
So,
let's
take
a
look
at
the
the
four
first,
so
the
there's,
a
new
small
concept
in
in
elsa,
three
called
behaviors,
so
the
four
activity
adds
a
behavior
called
break
behavior
and
what
I
allow
behaviors
to
do.
A
It
allows
you
to
reuse
right
logic
that
can
be
reused
across
activities
because
for
the
this
particular
break
implementation,
I
had
to
use
it
the
exact
same
implementation
for
for
or
each
and
for
a
while
and
a
behavior
is
just
a
way
to
delegate
logic
from
an
activity
to
a
separate
class.
That
is
then
reusable
and
also
cleans
up
your
activity
a
little
bit.
Potentially,
it
makes
your
activity
harder
to
follow.
A
So
it's
a
it's.
It's
a
balance
there
to
be
stricken,
but
the
so
this
great
behavior,
what
it
does
it
in
its
constructor.
It
registers
for
the
brake
signal.
So
you
could
just
do
this
from
the
activity
which
I
did
initially
and
then
I
had
a
lot
of
repetitive
code
for
the
four
for
each
and
while
activities,
and
now
I
have
all
of
that
code
just
here.
Well,
it's
not,
to
be
honest,
a
whole
lot
of
code,
but
it's
the
same
logic
that
is
now
living
in
one
place.
A
So
I
listen
for
the
break
signal
and
the
first
thing
I
do
is
I
capture
this
event,
so
I
instruct
the
event
bubbling
process
to
not
propagate
the
event
any
further
up
the
the
call
stack
if
you
will
so
that
imagine,
there's
a
nested
four.
Let's
say
I
have
a
four
here,
but
also
an
outer
four.
I
do
not
want
to
break
out
of
the
outer
for
loop
or
while
loop
or
whatever
loop.
I
just
want
this
one
to
capture
it.
So
that's
the
first
thing
to
do.
A
Then:
I
will
just
remove
any
potential
child
activity,
execution
contacts
that
are
child
branches
of
the
for
loop
or
whatever
activity
this
behavior
runs
in,
and
this
is
for
scenarios
where
you
are,
for
example,
breaking
out
of
a
loop
that
is
part
of
a
fork
or
a
branch
of
a
fork.
So
my
intended
behavior
there
is
that
if
I
break
out
of
a
four
and
this
inside
of
this
iteration
is
a
fork,
then
I
I
want
to
clear
all
of
this.
A
Pipeline
that
is
no
so
the
way
it
works,
it's
not
a
pipeline,
but
it
because
you
add
it
as
behavior.
It
does
get
iterated
over
at
some
point
and
I
will
show
you,
but
the
point
of
behavior
is
to
register
for
for
signals
and
potentially
implement
certain
methods
that
would
be
invoked
from
from
the
workflow
runner.
So
here,
for
example,
there's
an
execute
sync
that
the
behavior
can
implement,
and
this
is
invoked
by
by
some
other
logic.
So
I
think
that
was
the
reflect
running.
A
But
let's
see
it's
the
base
activity
class
that
is
responsible
for
this.
So
when
you
inherit
from
activity
you
will
overwrite.
The
execute
async
actually
will
overwrite
this
one.
So
this
is
a
virtual
method
and
then,
after
your
activity,
logic
executed.
This
base
class
will
then
iterate
over
its
behavior
and
invoke
its
execute
async.
D
A
Yeah
at
this
point
I
just
have
two
concrete
use
case
scenarios,
one
being
the
brake
behavior,
which
listens
for
some
signal
and
an
auto
complete
behavior
that
actually
implements
execute
async
by
completing
the
activity
that
just
executed.
So
if
you
look
at
the
activity
base
class
constructor,
what
I'm
doing
I'm
adding
two
more
behaviors,
so
the
autocomplete
behavior
is
added
by
default,
which
means,
if
you
want
to
opt
out,
you
actually
have
to
remove
the
behavior,
which
is
not
quite
nice,
I'm
contemplating
introducing
a
separate
base
class
for
activities
that
need
to
opt
out.
A
A
So
I'm
still
trying
to
figure
out
the
the
nicest
most
elegant
way
to
to
deal
with
reusability
in
the
form
of
behaviors,
but
without
it
being
too
complicated
or
weird
or
having
to
do
stuff
like
this.
D
A
The
activity
yeah
for
specific
activities
right
and
and
also
for
all
any
activity-
if
you
want
to
that,
you
can
do
today.
So
there's
there
is
middleware
here
so
there's
middleware
to
allow
you
to
execute
code
before
a
workflow
executes
and
after
and
at
the
exit
activity
at
player
itself.
So,
for
example,
this
is
loading
middleware,
yeah.
C
A
So
this
level
of
middleware
allows
you
to
execute
code
before
the
activity
executes
and
after
and
then
of
course,
this
is
a
pipeline.
You
can
build
up
programmatically,
but
this
this
applies
to
all
activities
out
of
the
box.
Of
course,
your
middleware
could
test
for
the
activity
being
executed.
So
if
it's
of
type
custom
activity1
for
example,
then
you
can
do
something
specific
or
if
the
activity
implements
some
interface,
then
you
can
do
something
specific
for
any
and
all
activities
that
implement
that
interface,
so
that
infrastructure
is
in
place.
A
But
it's
an
interesting
idea
to
be
able
to
implement
behaviors
in
a
way
that
doesn't
require
you
to
mess
around
with
custom
middleware.
Maybe
there
could
be
middleware
that
then
checks
to
see
if
the
activity
being
executed
has
a
certain
behavior
that
it
then
executes.
So
that's
that's
potentially
interesting
yeah,
so
I
have
actually
three
use
cases
for
behavior.
This
behavior
is
responsible
for
basically
invoking
completion
callbacks
of
activities
and
what
is
it
called
completion
callback?
You
ask.
A
I
will
tell
you,
for
example,
the
let's
take
the
sequence
activity,
so
the
sequence
activity
is
a
container,
so
it
can
have
an
array
of
activities
that
it
will
schedule
one
by
one.
So
that's
what
you
see
here
in
actually
in
the
container
that's
its
base
class,
it
will
schedule
children
and
that's
that's
a
protected
virtual
method
that
the
parent
class
can
or
that
child
class
can
implement.
So
here
it
implements
that
by
checking
what's
the
current
index,
which
by
default
of
course,
is
zero.
A
So
as
long
as
the
current
index
is
less
than
the
total
number
of
activities
in
the
list,
it
will
schedule
that
activity
here
so-
and
this
is
the
important
point-
so
it
will
schedule
the
activity
for
execution
and
register
a
callback
that
gets
invoked
once
the
child
activity
completes
execution.
Now
you
have
to
imagine
or
realize
that
the
child
or
the
activity
being
scheduled
could
be
a
very
complicated
activity.
It
could
be
a
sequence.
It
could
be
a
four.
A
It
could
be,
of
course,
a
simple
activity,
but
it
could
also
be
a
complete
state
machine
or
a
flowchart
activity
that
ends
under
certain
conditions,
unknown.
Unbeknownst,
of
course,
to
this
sequence
activity,
but
the
runtime
takes
care
of
knowing
when
something
completes
and,
of
course,
individual
activities
themselves
need
to
notify
the
system
when
they
complete.
When
that
happens,
this
callback
gets
executed,
allowing
you
to
do
whatever
is
necessary.
A
So
in
the
case
of
the
sequence,
it
needs
to
just
get
the
next
activity
in
the
list
and
schedule
that
one-
and
this
happens
continuously
until
the
current
index
is
greater
than
or
equal
to
the
number
of
activities
after
which
it
completes
itself,
and
because
here
this
is
an
explicit
action.
Of
course
it
needs
to
opt
out
of
the
autocomplete
behavior
that
is
registered
here
in
the
base
class.
So
it's
not
that
that's
the
story
of
activity,
completion,
callbacks
and
in
that
mechanism
is
implemented
by
this
behavior
and
and
so
it.
A
Of
course,
it
knows
that
the
completion
callbacks
they
are
stored
in
the
workflow
execution
context.
It
knows
which
one
to
fetch
from
from
some
list
and
then
actually
invoke
it
on
the
on
the
right
activity.
This
is
low-level
infrastructural
stuff,
that's
implemented
with
behaviors.
You
could
wonder:
does
it
make
sense
for
this
infrastructure
level
stuff
to
be
implemented
as
behaviors?
I
don't
know
yet
it's
it's
an
experiment.
One.
B
A
A
As
well,
yeah,
certainly
and
writing
custom
aware
is
easy,
customizing
it.
The
pipeline
is
relatively
easy
as
well,
and
I
can
show
a
quick,
quick
sample
so
here
I'm
configuring,
the
workflow
engine
execution
pipeline.
So
that's
the
the
outer
pipeline,
basically
that
so
that's
not
the
activity
pipeline,
we'll
we'll
get
to
that
next,
but
the
syntax
is
the
same.
So
here
we
have
what
this
call
that
gives
you
a
pipeline.
Workflow
execution
builder,
is
what
this
pipeline
is
called
and
then
using
these
methods
to
add
middleware.
A
That
will
then
evoke
so
you,
if
you
want
workflows
that,
where
you
don't
care
about
persistence,
you
can
just
not
register
the
persistence
middleware,
so
it
will
not
be
stored
in
a
database.
It
will
be
very
fast.
Maybe
you
don't
care
about
workflow
context,
which
we've
talked
about
a
few
weeks
ago.
You
can
opt
out
of
that
in
this
case.
Actually
you
need
to
opt-in
because
it's
an
optional
module
and
this
one
is
required.
This
is
the
the
default
strategy
to
schedule
activities
and
then
process
these
activities
using
a
stack-based
model.
A
What
pipeline
you
want
to
use,
so
you
could
you
can
imagine
being
able
to
declare
multiple
types
of
pipelines
for
the
workflow
execution
itself,
but
also
for
activities
themselves
and
then
give
them
some
identifier
or
some
name
and
then
associate
them
with
a
workflow
very
advanced,
but
for
certain
advanced
scenarios
might
be
just
what
you
need.
Maybe
you
have
a
class
of
workflows
that
need
to
execute
quickly
and
you
don't
care
about
persistence
and
a
fault
tolerance.
It
just
needs
to
perform
and
other
processes
or
other
definitions.
A
You
do
want
to
have
persistence
and
all
that
important
stuff
revolving
around
long-running
processes,
and
you
can
associate
those
workflows
with
appropriate
pipelines
just
as
an
idea
to
think
about.
So
here
you
can
say
use
word
for
context.
So
apparently
this
is
necessary
for
both
pipelines
and
what
else?
The
logging,
of
course
use
logging,
and
if
you
have
custom
middleware,
you
would
just
say
use.
A
I
thought
there
was
a
extension
method
allowing
you,
oh
yeah,
use,
middleware
and
then
the
type
of
your
middleware,
which
itself
is
a,
would
be
a
simple
class
that
just
implements
this
interface
here
and
then
you
can
do
perform
logic
before
your
activity
executes
or
the
next
middleware
executes
and
and
after
very
similar,
of
course,
to
the
hp
network,
middleware
pipeline
architecture,
and
this
all
is
optional.
When
you
add
elsa
to
your
application,
it
will
have
a
default
pipeline
configured
for
you,
so
this
is
optional.
A
I
also
updated
the
elsa
3
project
board
with
ones
of
new
tabs.
So
of
course,
we
still
have
the
overview
lots
of
work
to
be
done
still,
but
I
categorize
it
by
core
work
items,
activities,
designer
related
items
and
bugs
just
to
try
and
maintain
a
a
good
overview
of
what
work
is
yet
to
be
done
before
you
can.
Actually,
you
know,
release
an
an
initial
version
of
elsa,
3
and
alpha
version,
and
I
actually
want
to
do
the
same
for
lsat
2
as
well.
Right
now
we
have
projects
for
well.
A
We
have
different
projects
for
for
elsa
too,
but
it
would
be
better
to
have
a
single
overview
like
we
have
here
so
here
we
have
these
eight
projects
and
it's
it's
all
an
attempt
to
categorize
them.
So
we
have
workflow
designer
specific
projects,
stuff
that
needs
to
be
us
something
specific
to
web
books,
some
customer
specific
boards.
A
So
it's
hard
to
maintain
good
out
with
you
and
having
a
single
view.
That
also
allows
us
to
have
a
some
sort
of
backlog.
That's
prioritized
and
we
can,
of
course,
keep
prioritizing
and
organizing,
but
then
it
would
also
allow
the
community
to
see.
When
can
they
expect
a
certain
feature
to
be
picked
up,
not
as
a
guarantee
but
as
a
as
a
hopeful
indication
so
yeah?
That's
what
I've
been
up
to.
A
Yeah
for
sure,
so
what's
next
for
elsa
3,
so
currently
yeah,
I
started
to
work
on
the
startup
activity
which
allows
you
to
schedule
a
bookmark
in
the
future.
At
a
specific
time
step.
We
have
it
in
elsa
too,
but
we
also
needed
nelson
3.
So
that's
next
on
my
list
and
then
hopefully
this
week
or
next
week,
a
customer
offered
to
contribute
one
or
two
front-end
developers
to
help
speed
up
the
elsa
3
designer
implementation.
A
So
that's
all
of
this
this
stuff
here
so
hopefully
we
can
get
that
started
soon
and
and
speed
up
the
the
implementation
and
thereof
all
right.
That's
all
I
have
does
anyone
have
any
questions
or
what
topics
I
would
like
to
discuss
today.
D
For
me,
or
maybe
maybe
not
for
today,
but
maybe
for
next
week,
I've
started
a
discussion
on
a
sort
of
execution
context.
There's
a
sequence
be
able
to
think
about
where
we
can
execute
some
part
of
the
workflow
and
choose,
for
example,
execute
the
first
part
on
a
specific
vm,
the
other
part
and
other
vm
that
can
access
to
a
sql
server,
etc.
I've
started
a
discussion
on
this.
Maybe
we
can
just
talk
about
it
on
github
and
and
then
try
to
talk
on
it
next
week,
yeah.
C
Do
that
I
don't
think
I
mentioned
it
in
the
previous
time,
but
I
like
how
to
deal
with
testing
and
get
on
some
tricks
and
tips
and
tricks
about
that.
How
you
can
manage
the
quality
of
your
workflows
and
activities.
It
would
be
interesting
to
see
and
to
discuss
which
approaches
are
used
and
whether
the
pros
and
cons
of
each
so.