►
From YouTube: Elsa Workflows Community Meeting 8 ( 2022-05-10 )
Description
# May 10, 2022
## Topics
- Steering Committee 2022-2023
- Amanda Seiken - @Amanda-SVT
- Cristina Mudura - @cristinamudura
- Frans van Ek - FransVanEk
- Jérémie Devillard - @jdevillard
- Sipke Schoorstra - @sfmskywalker
- Elsa 3
- API controllers
- Workflow Definition Handling
- Export
- Lots of designer work ahead :)
A
Oh,
I
also
don't
have
too
many
topics.
We
can
go
over
the
updates
first,
some
commit
from
tomi
about
workflow
metadata,
so
this
is
adding
a
metadata
field
to
the
summary
model,
a
bill
issue,
something
on
linux
with
case
sensitivity
fixed
by
peter.
Some
multi-tenancy
fixes
specifically
engaged
the
end
point
middleware.
So
this
is
about
multi-tenant
use
of
elsa,
which
is
missing
and
some
all
the
changes.
A
Sorry,
I
could
clear
my
throat
a
little
bit,
so
this
is
ls2.
Not
nothing.
Much
has
changed
there.
I
did
some
light
work
on
elsa
3,
but
I've
been
away
for
most
of
the
week
last
week,
so
not
much
progress
there,
but
the
progress
that
has
been
made
is
pretty
cool
yeah.
Maybe
else
I'll
just
show
a
little
bit
there.
One
nice
thing
that
I
discovered
has
to
do
with
the
ability
to
control
from
an
application's
point
of
view,
what
controllers
to
include.
So.
A
This
is
an
issue
for
some
users
with
elsa
too,
and
they
can
fix
it.
I
will
show
you
how,
but
the
problem
is,
is
when
you
bring
in
elsa
libraries,
for
example.
Let's
take
a
look
at
lsat2
here.
We
have
this
server
api
which
exposes
endpoints.
If
you
want
to
work
with
the
designer,
then
you
do
want
to
have
all
of
these
endpoint
controllers
exposed
in
your
application,
but
there's
also
a
packets
in
the
http
activities,
library.
It's
also
exposed
to
some
endpoints
and
some
users
don't
like
this.
A
They
do
want
to
use
the
hp
endpoint
activities,
but
they
don't
care
for
these
two
controllers
and
then
the
question
is:
how
do
you
exclude
these
controllers
because
by
default
asp.net
core,
starting
with
version
3.1?
I
believe
they
will
include
all
controllers
that
have
been
from
all
packages
that
are
referenced
by
the
main
application.
So
there's
a
way
to
change
that
and
I've
been
experimenting
with
that
in
lsat3.
So
let
me
show
an
example.
A
So
here
we
have
a
sample,
asp.net,
core
application,
and
then
here
here
I
go
ahead
and
add
2d,
add
controller,
so
that's
mpc
services
and
then
what
I
do
I
clear
application
part.
So
this
is
the
key
to
controller
discovery
in
asp.net
core
by
default.
It
will
add
application
assembly
parts
based
on
the
references
of
the
current
application.
So
this
will
include
by
default
the
elsa
api
controllers,
because
I'm
referencing
that
packets.
But
by
doing
this
I
will
clean
out
all
of
these
included
parts
and
then
I
can
build
it
up
from
scratch
again.
A
So
I
can
add
my
own
controllers.
If
I
want
to
so
in
this
example,
I
don't
have
them
so
this
call
is
not
necessary,
but
it
would
be
necessary
if
you
did
have
controllers
in
your
application
or
controllers
in
any
other
of
your
own
projects.
So
you
will
want
to
add
them
manually
back
and
then
you
can
add
the
elsa
api
controllers
that
you
want.
So
this
extension
method
is
just
a
simple
helper.
A
It
uses
the
assembly
part
to
add
at
this
at
this
current
assembly,
so
in
this
case
elsa
api
as
an
application
part,
and
we
can
even
do
it
using
a
custom
part
called
the
types
part
if
you
wanted
to
add
one
controller
from
a
given
assembly.
If,
if
that's
something
you
would
want,
so
this
is
nice,
because
this
solves
the
problem
of
automatically,
including
controllers
that
you
don't
want
to
be
exposed
through
your
epic
application,
and
this
allowed
me
to
basically
refactor
all
of
these
endpoints
from
what
they
call
are
called.
A
I
forgot
the
name,
but
there's
this
simple
way
of
adding
api
endpoints
and
that
doesn't
require
to
use
controllers.
But
I
refactor
this
to
use
controllers,
because
this
gives
me
the
ability
to
use
you
know
all
the
asp.net
core
stuff
like
action
filters
model
binding
with
with.
Of
course,
you
have
there's
a
way
to
do
it
with
these
simple
api
endpoints.
But
then
you
don't
have
support
for
swagger
generation,
for
example
not
out
of
the
box
at
least,
and
now
I
get
all
these
capabilities
back.
So
it's
more
convenient,
I
think,
can.
B
I
ask
a
question
yeah
sure,
so
I
can
see
that
you're
in
the
services
and
then
you
can
clear
them.
Are
you
planning
on
making
a
stan
extension
that
you,
for
instance,
can
clear
only
the
elsa
parts,
because
this
method,
as
you
use
it,
now
cleans
everything?
So
you
have
to
inject
all
the
things
that
you
actually
developed
yourself,
yeah
exactly.
A
And
this
is
up
to
the
application.
You
don't
have
to
do
it
like
this.
You
could
also
choose
to
exclude
just
elsa
or
any
other
packages
that
you
don't
want,
and
then
you
don't
have
to
build
it
from
scratch.
So
this
is
now
I'm
clearing
everything,
but
you
could
do
it
the
other
way
around
by
just
removing
the
elsa
api
controller.
A
A
C
How
about
the
authorization
and
answer,
for
example,
I
want
to
have
different
authorization
for
the
end
points
to
publish
the
workflows
and
the
endpoints
to
just
view
the
status
of
the
workflow.
So
I
have
some
users
who
can
publish
workflows
but
other
users
who
can
just
view
the
status
of
the
execution.
A
Yeah,
that's
the
that's
a
great
question
and
I'm
not
entirely
sure
yet,
but
I've
been
playing
with
the
thought
of
annotating.
These
controllers,
with
a
authorized
attribute
like
this
and
then
providing
a
some
policy
name
and
in
this
policy
name,
could
be.
For
example,
in
this
case
list
activity,
descriptors
and
workflow
definitions
would
get
its
own
set
of
policies
so
that
you
have
fine
variant
control
over
what
permissions
are
required
for
a
user
to
invoke
these
endpoints
and
then
you
can
control
this.
A
A
Exactly
yeah,
I
think
this
will
be
a
good
way
to
do
it.
Maybe
we
can
even
use
a
single
elsa
policy,
but
have
some
sort
of
I
know.
Maybe
a
custom
attribute
that
lets.
You
specify
permissions
that
are
required
by
the
user
so
that
you
can
have
one
policy
but
then
map
it
to
claims
where
permissions
are
mapped.
To
a
claim.
A
I
don't
know
we
will
do
some
experimentation
to
see
what
works
nicely
for
those
who
weren't
there
last
week
and
well
you're
not
able
to
watch
the
video
yet
because
it's
not
published
yet
we
have
the
results
from
the
stem
committee
election,
and
so
these
are
the
top
five
winners.
So
that
means
these
five
people
are
now
officially
steering
committee
members
and
I
still
have
to
create
an
issue
and
get
up
to
list
these
people
and
request
for
a
brief,
bio,
an
avatar
or
a
photograph,
and
maybe
we
can
put
it
on
the
elsa
website.
A
We
discussed
this
last
week
so
for
those
who
see
who
are
seeing
this
for
the
first
time,
congratulations,
you
made
a
cure.
Another
change.
Where
else
are
three
com?
What,
when
compared
to
elsa
2,
is
the
way
workflow
definitions
are
handled,
so
in
elsa
2.
We
have
this
notion
of
workflow
providers
and
one
such
implementation
gets
workflows
from
the
database.
Another
one
gets
it
from
programmatic
workflows
that
you
write
in
c,
sharp
and
another
one
from
blob,
storage,
etc.
A
And,
of
course,
you
can
extend
it,
but
that
implementation
is
inconvenient,
to
say
the
least
when
it
comes
to
listing
available
workflows
to
the
system
using
pagination,
for
example,
currently
in
elsa
2.
If
you
go
to
the
screen,
you
have
to
first
select
the
workflow
provider
and
then
you'll
get
a
list
of
those
workflows
for
that
workflow
provider
and
just
to
show
you
what
I
mean,
let
me
see
if
I
can
start
elsa
tool
on
my
machine.
A
So
if
you
go
to
workflow
registry
here,
you
see
the
the
three
providers
that
come
out
of
the
box,
so
there's
a
programmatic
one
blob
source
and
database,
and
these
workflows
come
from
the
database.
This
one
are
coded
in
in
elsa,
but
this
approach,
it's
very
inconvenient
because
one
this
is
not
a
great
ux,
and
if
you
wanted
to
just
list
pages
of
workflows,
it's
tricky,
you
can
do
it,
but
it's
it's
not
very
straightforward.
A
With
elsa
three
everything
gets
stored
in
a
database,
so
your
coded
workflows,
workflows,
loaded
from
json
files
or
from
your
own
backend
or
doesn't
matter
where
it
comes
from
during
startup.
These
workflows
are
discovered
and
then
a
definition
is
added
to
the
database.
We
are
already
doing
this
in
lsatool
just
for
triggers
and
now
in
ls3.
We,
the
initial
version,
did
the
same
thing.
It
was
then
indexing.
All
of
these
workflows
get
all
the
triggers,
but
now
it's
not
just
indexing
the
triggers.
It's
also
loading
the
workflow
workflows
into
the
database.
A
This
has
two
big
advantages:
one
well
what
I
just
mentioned.
It's
now
easy
to
query
pages
of
workflow
definitions.
They
are
all
treated
the
same,
but
of
course
they
are
not
the
same.
Programmatic
workflow
is
not
the
same
as
a
workflow
defined
in
json,
but
I
regard
it
as
an
implementation
detail
and
what
that
brings
me
to
the
second
advantage.
What
we
can
now
do
is
we
can
allow
the
user
to
publish
or
unpublish
a
workflow,
that's
coded
in
c
sharp.
A
You
won't
be
able
to
add
activities
because
well,
if
it's
coded
in
c
sharp,
you
can't
change
that
code
just
like
that
in
theory,
it's
possible,
but
it's
not
very
practical,
but
at
the
very
least
we
could
allow
the
user
to
change
activities
around
change
variables,
like
you
know,
input
variables
for
the
workflow
and
maybe
change
other
metadata
for
this
workflow.
That
is
then
used
at
runtime
by
this
workflow
or
in
the
designer
so
that
you
have
visual
control
over
over
the
layout
of
your
workflow.
A
So
those
are
some
of
the
advantages
that
brings
this
this
new
approach.
So
let
me
show
you
in
the
database
what
that
looks
like
so
here
we
are
looking
at
the
sqlite
database
and
it's
it
shows
the
word
for
definitions
and
the
way
to
distinguish
the
different
types
of
workflows
are
by
looking
at
the
materializing
name,
so
the
clr
ones
are
workflows,
discovered
from
source
code
and
the
json
ones
are
created
using
the
api
or
the
designer
which
uses
the
api,
and
it's
not
completely
implemented.
A
Yet,
and
by
that
I
mean
you
can't
currently
load
a
clr
workflow
into
the
designer,
because
there's
some
additional
work
to
be
done
to
make
that
work
properly
and
also,
I
need
to
put
in
some
limits,
because
even
though
you
should
be
able
to
publish
and
unpublish
a
coded
workflow
or
clr
workflow
having
multiple
versions
of
it,
maybe
it
makes
sense.
Maybe
it
doesn't.
A
B
A
Will
only
see
the
json
one,
so
I'm
putting
a
hard-coded
filter
for
json
type
workflows
when
loading
the
workflow
definitions.
So
here
you
can
load
workflow
definitions
and
these
are
the
ones
created
by
the
designer.
Last
week
we
talked
a
little
bit
about
the
size
of
these
icons.
I
made
it
a
little
bit
smaller.
We
could
go
even
smaller,
but
it's
already
smaller
than
what
you
see
on
this
on
the
canvas
here.
So
it
should
be
a
little
bit
better
and
I
added
some
fancy
icons
to
this
one.
A
At
least
it's
not
complete
yet
but
I'll
work
on
that
iteratively
yeah.
So
I
think
that's
it
for
the
update
with
elsa
3..
Actually,
I
forgot
about
input
export
the
input
and
export
api
endpoints.
I
finished
today
I'm
currently
working
on
implementing
it
in
the
designer
so
for
export,
that's
implemented.
So
now
we
can
export
workflows
from
the
designer,
but
import
isn't
done
yet.
So
that's
that's!
Actually
what
I'm
currently
working.
A
Than
that
there's
another
front-end
developer
working
on
some
of
the
tasks
for
the
designer.
Now
you
can
take
a
quick
look
at
those
yeah,
so
mainly
these
guys
here,
but
not
much
progress
since
last
week,
because
we
looked
at
the
same
list
and
nothing
has
moved
except
for
the
the
name
field
that
one
has
has
been
done,
which
is
nice.
Has
anyone
any
any
questions
about
any
of
the
things
I
discussed
just
now,
yeah.
B
B
About
the
versioning
of
clr
and
it's
a
tricky
one
actually,
so
I
don't
even
think
yeah
like
I
said
it's
only
for
the
position
or
the
flow.
It
might
be
interesting
to
have
versioning,
but
I
can't
guarantee
that
it
works.
If
you
update
the
clr
and
have
them
side
by
side,
that's
impossible,
I
guess
what
do
you
mean
side
by
side?
Well,
that
you
have
the
old
version
of
the
implementation
of
some
activities
or
the
workflow
itself,
because
you
can
update
a
in
internal
workings
of
an
activity
which
basically
gives
you
a
new
version.
B
A
Yeah,
if
you
create
a
if
you
update
a
workflow
created
in
code-
and
you
didn't
create
a
copy
of
that
code,
then
there's
no
way
of
displaying
that
site
beside
side
by
side,
but
there's
also
another
tricky
issue.
If
you
do
make
a
change,
for
example,
you
add
an
activity
or
remove
an
activity,
change
connections,
then
the
workflow
definition
encode
may
be
referencing
activities
that
are
no
longer
there
for
the
new
ones.
It's
okay,
they
just
don't
have
a
position,
but
for
the
ones
that
have
been
removed.
A
The
designer
needs
to
take
that
into
account
as
well
or
the
back
end.
I
don't
know
that's
another
thing
to
be
aware
of
for
the
for
handling
this
correctly.
Another
thought
I
had
was,
if
you
look
at
the
the
data
column
for
for
a
workflow,
I
added
a
binary
data
and
the
data.
So
in
theory,
what
we
could
do
is
compile
the
workflow
builder
or
the
workflow
definition
encode
into
an
assembly
and
then
store
the
byte
data
of
that
assembly.
A
Here
in
this,
in
this
column-
and
this
way
you
have
a
version
always
even
if
you
make
changes
to
the
source
code,
the
system
will
then
see
that
it
has
changed,
because
some
signature
or
some
hash
has
changed,
and
then
it
will
do
a
new
compilation
and
store
that
in
a
second
record.
But
of
course
it's
tricky
potentially,
because
if
you
delete
your
database,
then
you
delete
all
of
your
assemblies.
But
of
course
you
will
always
have
your
source
code
and
the
system
will
just
create
a
new
definition
from
that.
B
A
B
B
A
B
Specific
versions
of
an
external
dll
or
package,
and
how
are
you
gonna,
handle
that
if
you're
gonna
update
it
later
on-
and
you
have
a
different
version
then,
because
in
the
main
assembly,
you
have
all
the
references
to
the
other
dlls
and
if
you
update
that
the
old
ones
you'd
expect
the
old
version
of
that
package.
Yeah.
B
A
B
B
C
Me
what
I
feel
is
that
if
you
are
going
with
a
programmatic
workflow,
it
is
something
like
a
built-in
functionality
or
business
logic
related
workflow,
that
you
are
not
intending
to
change
without
doing
all
the
checks.
So
I'm
not
sure
if
it
is
really
required
to
keep
the
version
control
for
that,
because
if
it
is
some
workflow
that
you
are
trying
to
evolve
over
time,
then
definitely
you
want
to
use
the
designer
so
that
you
can
let
the
users,
you
know,
change
the
workflow
and
keep
the
version.
A
I
I
get
what
you
mean,
but
there's
also
scenarios
where
you
want
to
use
the
workflow,
that's
programmatic,
but
then
you
have
an
existing
system
in
production
with
workflow
instances
that
depend
on
on
a
certain
schema
of
your
workflow.
And
if
you
have
new
requirements
and
you
make
changes
to
that-
one
workflow
definition
in
code,
then
your
existing.
A
C
A
A
certain
point
with
ls2
it's
possible
to
a
certain
point,
because
if
you
have
a
programmatic
workflow
and
you
use
c-sharp
lambdas
for
example,
then
they
don't
translate
well
to
the
designer.
So
the
designer
would
just
display
some
type
name
of
that
lambda
expression,
but
not
the
actual
expression.
So
it
wouldn't
be
able
to.
Then
it
would
not
be
an
actually
executable
workflow.
So
the
workflow
designer
can
display
the
activities
using
the
automatic
automatic
layout
algorithm.
But
that's
just
the
read-only
view.
A
If
you
then
would
want
to
actually
use
that
as
executable
workflow,
so
that
you
can
also
version
it
that
won't
work
and
with
elsa
3
it's
a
little
bit
easier
because
the
model
you
create
programmatically
is
actually
a
serializable
model,
but
it
has
the
same
problem.
If
you
use
c-sharp
lambdas,
then
it
won't
be
executable
anymore.
Unless
you
use
javascript
expressions
because
then
that
gets
stored
as
well
in
the
out
in
the
serialized
output.
So
that
would
be
a
way.
A
So
you
could
start
out
with
a
programmatic,
workflow
export
it
to
the
designer
or
to
some
json
format
using
the
designer,
for
example,
and
then
you
would
have
a
personal
workflow
through
the
designer
but
yeah.
It's
it's
tricky
and
I
think
for
programmatic
workflows.
Probably
the
most
pragmatic
way
is
to
just
create
a
multiple
version,
so
create
a
copy
of
your
workflow
definition,
and
you
could
use
file
nesting
to
have
different
versions
so
that
it
keeps
stays
a
little
bit
organized
in
your
in
your
source
code.
Maybe
now.
B
A
Actually,
there
is
a
way
to
do
so,
and
I
will
show
you
okay.
So,
for
example,
let's
say
we
have
this
workflow.
We
can
say
that
this
workflow
has
a
definition
id.
So
this
is
the
the
logical
workflow
definition
id.
So
this
could
be
wow.
So
this
is
important
for
this
to
be
the
same
for
all
versions,
and
then
I
can
say
builder
dot
version
one.
A
So
this
would
be
version
one
and
this
class
will
be
called
one
like
this,
and
now
I
create
a
new
version
and
I'll
call
this
one
two,
but
we
will
keep
the
workflow
definition
to
while
but
of
course,
increase
the
version
number.
So
this
way
new
workflow
instances
will
use
this
second
version,
but
existing
instances
will
still
be
referencing.
This
one.
B
A
That's
very
true,
of
course,
it's
also
easy
to
make
a
mistake.
It's
like,
I
could
add
an
activity
here
and
then
deploy
to
production
and
then
realize
that
I
made
a
mistake,
and
now
all
of
my
workplaces
no
longer
work,
these
existing
ones,
there's
also
a
lot
of
code
that
you
generate.
So
that's
harder
to
look
at.
Of
course.
If
you
treat
this
as
an
immutable
workflow
definition,
then
you
only
have
to
look
at
it,
but
never
change
it.
A
You
would
have
to
create
copies,
which
you
can,
of
course
get
by
by
introducing
the
good
structure
using
a
folder
structure
or
file
nesting,
but
yeah
it's.
I
agree
that
having
a
binary
format,
it
makes
it
opaque
and
hard
to
troubleshoot,
especially
if
you
have
all
the
versions
and
they
run
in
production.
A
Then
let's
say
there's
an
issue:
you
want
to
troubleshoot,
there's
no
way
to
go
back
to
your
older
version
unless
of
course
go
back
and
get
using
git
versioning,
but
it
makes
it
more
complicated,
more
complicated
than
having
these
classes
in
code
readable
to
to
you
so
yeah
yeah
and
of
course
this
is
the
easiest
way.
It
doesn't
require
fancy
compilation
and
storing
it
in
byte
code
or
executing
code
at
runtime,
etc,
or
compiling
this
at
runtime
I
mean
yeah.
This
is
already.
B
A
So
in
ls3
I
wonder
we
have
a
2
in
elsa
3.
We
have
versioning
and
we
have
this
okay
and
if
you
don't
specify
a
definition
or
a
version
version
defaults
to
1
and
the
definition
id
defaults
to
the
type
name,
just
as
an
fyi.
So
what's
next
for
elsa
3.!
Well,
you
guys
have
seen
the
list
I'm
going
to
spend
a
little
bit
time
on
the
front.
End
myself
as
well,
probably
I'll
be
picking
up
the
toolbar
and
then
for
a
customer.
A
They
have
existing
workflows,
so
I'm
gonna
adapt
those
workflows
to
lsat3
using
the
designer.
I
already
did
that
for
the
engine
as
a
proof
concept
and
that
worked
pretty
well.
But
of
course
the
real
challenge
is
having
the
designer
and
as
discussed
before,
the
initial
version
will
be
similar
to
elsa
designer
2
and
elsa
designer
1.
B
A
A
bit
of
a
mix,
but
the
flowchart
model
remains.
But
we
did
discuss
about
how
easy
it
is
to
explode
your
workflow
into
a
huge
diagram,
because
there
there's
no
nesting
in
the
designer
and
that's
what
we
want
for
elsa
3
as
a
an
additional
type
of
designer,
where
you
have
nesting,
for
example,
for
sequence.
So
diagram.
A
At
right
now
is,
is
a
flowchart
diagram,
doesn't
have
nesting,
but
let's
say
we
add
another
flowchart,
because
a
flowchart
in
elsa
3
is
just
another
activity.
Let's
say
we
now
want
to
execute
this
flowchart.
I
imagine
the
user
should
be
able
to,
let's
say
double
click
on
this
one
have
another
tab
open
or
some
trail,
some
breadcrumb
trails
with
a
new
designer
for
this
flowchart,
and
the
same
goes
for
sequence,
which
would
have
its
own
designer,
where
you
have
a
simple
top
to
bottom
or
left
to
right
sequence
of
activities
and
the.
A
If
activity
has
two
two
branches,
but
you
would
only
add
a
single
activity
to
it,
which
itself
could
be
a
container
activity
like
a
flow
chart
like
a
sequence.
Well,
we
showed
this
last
time
it
would
behave
similar
to
windows,
workflow
foundation.
That's
one
of
the
first
things
I
want
to
focus
on
after
elsa.
3
is
stable
and
released
to
to
the
main
brands,
also
just
as
an
fyi
that.
A
C
A
Know
what
you
mean
yeah,
so
what
I
thought
of
doing
was
to
give
the
name
a
sequential
suffix.
So
let's
say
untitled
one
untitled
two,
the
other
idea
would
be
to
have
the
name
field
be
required,
so
initially
it's
just
empty
and
it
forces
you
to
provide
a
name
personally,
I'm
not
a
fan
of
that.
I
always
find
it
annoying,
but
this
could
be
a
personal
preference
that
could
be
maybe
configured
on
the
web
component
itself
or
maybe
on
the
server
side.
C
Think,
while
publishing
it
may
be
required
to
be
incumbent
battery
to
give
a
name.
Otherwise,
if
you
publish
multiple
workflows
to
give
them
the
name,
they
all
become
as
unfighted,
and
then
you
don't
know
which
one
is
which
so
maybe,
while
working
with
the
workflow,
you
can
remain
empty
until
you
are
about
to
publish,
then
when
you
publish
media
will
come
and
make
sure
that
you
have
a
name
yeah.
A
That
could
work
and
then
maybe
when
you
do
a
new
workflow,
maybe
it
will
show
pop-up
as
well,
where
it
prompts
you
to
enter
name
or
not,
and
then
we
do
it.
As
you
say,
as
soon
as
you
publish
then
either
this
turns
red
or
a
pop-up
appears
where
you
are
prompted
to
enter
a
name
and
the
default
value
could
still
be
untitled,
1,
2,
three
etc.
But
then
it's
it's
more
explicit
yeah.