►
From YouTube: Elsa Workflows Community Meeting 19 ( 2022-07-26)
Description
Due to some technical issues alot of audio was not recorded, there will be an extra video with explanation and a small demo.
Meeting 19
Topics
- Who is Gurkan? :)
- Elsa 3 updates
○ Flowchart parallel execution
○ Activity definitions
○ Background jobs
- Elsa 2.9
Need to fix outstanding issues then release
A
Due
to
some
technical
difficulties,
someone's
audio
was
not
recorded
this
guy
and
there
are
a
lot
of
chunks
that
went
missing
because
of
that.
But
in
this
video
we
have
gurkhan
who
is
introducing
himself,
and
there
is
a
nice
conversation
with
muhammad
and
friends
so
enjoy,
and
there
will
be
an
extra
video
coming
with
some
explanation
and
a
demo.
B
I
think
people
don't
know
me
right
yeah.
I
think
people
don't
know
me,
shall
I
introduce
myself
a
little
bit,
hey
guys,
so
my
name
is
gurkham.
I'm
an
old
colleague
of
sipka
from
rtl
friends
office
and
I
recently
stopped
working
for
rtl
and
I
decided
to
join
fully
as
a
team
to
make
as
a
part
of
my
life
for
now
and
my
expertise
area
is
mostly
microservice
architecture
on
that
net
environment.
I
have
also
bits
of
frontends
and
mobile
applications,
but
mainly
vacant,
and
I'm
a
geek
nerd
a
little
bit.
D
Yeah
nice
to
meet
you
too
yeah.
We
can
do
that
yeah.
I
added
some
comments
about
that
yeah
and
two
seven.
What
was
it?
It's
a
bit
down
there,
two
eight
seven
two.
I
saw
you
posted
some
comments
about
that
mohammed
yeah
yeah.
If
I
understand
it
correctly,
I
think
I
had
the
same
questions
regarding
that
when
we
have
multiple
loops,
but
then
I
also
encountered
the
situation
that
we
discussed
previously
when
you
have
a
loop
and
and
fork
that
comes
from
another
loop
and
the
resetting.
D
That
would
be
quite
tricky,
but
let's
first
go
over
the
proposal
that
we
on
the
same
page.
So
let
me
get
it
here,
okay,
so
the
idea
was
to
have
a
differentiation
between
the
normal
join
without
an
explicit
join
activity
in
the
workflow.
Basically,
what
we
I
propose
is
then
just
to
select
one
of
the
options
which
is
wait
for
a
continue
always
which,
whenever
something
gets
activated
it
just
continues.
It
makes
sense
from
the
perspective
of
the
user.
D
It
just
says:
well
whenever
you
come
here,
we'll
continue,
and
we
discussed
this
as
well
with
the
four
well.
The
four
was
basically
executed
within
the
activity,
so
it
didn't
activate
it
twice
for
the
join
and
then
to
make
it
explicit-
and
I
looked
into
the
bpmn
notations
and
the
best
practices
in
that
is
to
have
an
explicit
work
and
join
to
also
give
more
details
about
what
the
intent
is
of
the
workflow.
D
Having
just
emerged
on
an
activity
doesn't
really
show
you
what
the
intent
is
and
especially
when
we
would
have
had
properties
to
manipulate
the
behavior
of
the
merging
on
the
activity
itself.
It's
not
visual
in
the
process
itself,
and
I
think
that
is
one
of
the
most
important
things
that
we
we
can
benefit
from.
D
Whenever
one
of
the
branches
has
an
activity
that
is
activating
an
activity
that
has
a
joint
just
continue
from
there
and
schedule
the
next
activity.
This
means
that
we
should
abandon
the
current
implementation
implementation.
When
we
do
branch
by
branch
execution,
because
then
it
wouldn't
make
sense
to
do
so,
because
one
branch
will
have
priority
over
the
others,
and
only
when
it's
completely
finished
or
comes
to
a
blocking
activity,
then
the
others
get
a
chance
to
execute.
D
We
have
a
wait
for
it
for
any
once,
which
means
that
when
you
have
a
merge,
whenever
one
of
the
branches
is
going
to
activate
the
join,
it
will
continue,
and
when
the
other
branches
is
activated,
then
it
will
not
continue
unless
the
number
of
executions
is
higher,
so
the
first
one
will
execute
if
the
second
branch
and
that
this
merge
is
going
to
be
executed
as
well,
it
says.
Well,
I
already
have
that
threshold
of
one
I'm
not
gonna,
do
that.
D
This
is
something
that
I
was
thinking
about
and
also
in
the
second
thing
that
I
added,
because
in
the
first
one
I
approached
it
this
bit
the
same
way
as
you
described
at
the
moment
with
a
token
or
an
indication
in
which
context
it
is
going
to
execute.
But
I
thought
that
it's
really
tricky
to
do
that.
D
There
are
so
many
different
paths
that
you
can
take,
and
we
looked
at
that
example,
then,
last
time
where
you
have
an
or
that
is
merged
within
separate
branch
that
isn't
coming
from
a
for
loop
or
a
loop
that
can
continue
multiple
times
and
how
you
could
distinguish,
then,
which
brands
to
reset
and
which
brands
not
to
reset.
And
if
you
think
of
that.
Also
from
the
perspective
of
that,
the
process
needs
to
be
clear
in
the
intent
how
it's
executed.
D
C
D
C
Yeah,
it
should
be,
I
think,
in
the
workflow
execution,
because
that
is
a
safeguard
that
must
be
there,
and
I
think
we
discussed
this
one
few
weeks
back,
that
there
is
already
a
mechanism
to
do
that,
but
I
think
it
has
to
be
by
default
there.
Otherwise,
because
if
you
are
in
a
production,
environment
and
the
user
makes
the
mistake-
and
you
are
running
hot
and
there
is
no
other
way
other
than
to
stop
everything
and
kill
the
the
instance.
C
So
probably
some
safeguards
should
be
there,
so
some
safeguards
in
the
workflow
execution
itself,
and
if
we
can
also
give
some
visual
indication
to
the
user
that
this
kind
of
scenario
might
cause
trouble,
or
this
kind
of
scenario
is,
is
not
recommended.
Visual
feedback
is
very
important,
so
explicit
join
is
definitely
a
very
good
visual
feedback,
but
also
if
we
can
give
some
indication
that
this
workflow
maybe
is
not
going
to
work
the
way
we
are
intending
yeah.