Initial presentation of Ruote 2.0. Those slides were presented by Nando Sola during the first "Ruedas y Cerverzas" meeting in Abstra.cc Madrid office on 2009-10-08. The first part enumerates reasons for the move to 2.0 while the second details the enhancement made to the ruote process definition language.

1. ruote 2.0
2009/10/07

2. warning :
these slides pre-suppose you
have some familiarity
with ruote (0.9.x)

3. ‣ recap : ruote
‣ is a ruby workflow engine
‣ ruby makes it easy to tinker and try
‣ workflows should be easy to tinker
and try
‣ with some discipline, you might
even end up doing BPM with it

4. agenda

5. agenda

7. ruote 2.0 engine

8. ‣ ruote engine : historically
‣ middleware/backend-ish
‣ not for your big front web 2.0 app
‣ cheap workflow engine
‣ 1 engine per business unit

9. ‣ ruote engine : core requirements
‣ has to run multiple processes
‣ with multiple branches
‣ and/or subprocesses
‣ can be stopped / restarted
(if running with persistent storage)
‣ can run multiple versions of any
process
‣ has to allow in-flight modifications
to processes

10. ‣ ruote 2.0 engine
‣ multi ruby process resilient :(
‣ complete rewrite
with a cleaner interface

11. ‣ multi-process
‣ the average user wants to put ruote
in his rails app
‣ the rails app is
in a ‘multi-process’ ruby web server
‣ ruote 0.9 is
in trouble...

12. ‣ multi-process resilience
‣ ruote 2.0 knows it could run in a
multi-process env
‣ it has defense mechanisms
things like ‘tickets’ and ‘locks’
‣ they have a cost :-(
‣ suggestions
‣ avoid mp envs for ruote
(the engine is idle most of the time)
‣ run ruote as a webservice
in a 1p env
‣ (ruote in 1p can use “caching”
and be faster)

13. ‣ our favourite env these days
‣ ruote-{kit|http}
workflow as an http service
‣ ruote-amqp
‣ remote participants
as amqp (daemons)
http://github.com/kennethkalmer/daemon-kit
‣ load on ruote itself is low

14. ‣ anyway...
‣ 1 engine that scale
for everything ?
‣ why not 1 engine
per domain / unit ?
‣ why not a separation between
tactical and technical engines ?
‣ why not engines that talk to each
other ?
‣ scale the business
or scale the tools ?

15. ‣ engine workqueue
‣ where each operation is performed
‣ only 1 op at a time
‣ by default, uses Thread/Queue
‣ uses EventMachine if present
‣ future work :
‣ fibers ?
‣ it’s an implementation away
‣ anyway, engine is idle most of the
time (usually waiting for those slow
humans)

16. cleaner interface

17. cleaner interface

19. ruote 2.0 process definitions

20. ‣ AST is JSON friendly
‣ attributes common to all expressions
‣ :if / :unless
‣ :timeout, :on_timeout
‣ :on_cancel / :on_error
‣ :forget
‣ directed commands
‣ break :ref => ‘tag’
‣ jump :to => ‘tag’
‣ concurrent_iterator enhancements
‣ subprocesses and apply
‣ ...

21. AST is JSON friendly

22. XML is still here

23. ‣ common attributes
‣ can be given to any expression

24. :if / :unless

25. :timeout

26. :on_timeout

27. ‣ :on_error
‣ much like begin / rescue...
‣ occurs when error is triggered
‣ error is thus not logged in
error_journal

28. :on_error

29. :on_error

30. ‣ :on_cancel
‣ subprocess or participant
triggered
when expression gets cancelled
‣ unlike :on_error
trigger happens when cancel is
complete

31. :on_cancel

32. :forget

33. ‣ cursor / jump
‣ can now jump to
a tag,
a participant name or
a subprocess name
‣ almost that
‘cursors as state machines’
feeling
‣ works with repeat (loop)
as well

34. cursor / jump

35. ‣ directed commands
‣ cursor/repeat has
jump/rewind/break/... commands
‣ until now these commands were
only meant for the enclosing cursor/
repeat
‣ now with :tag and :ref,
more precision is possible
‣ works with the iterator expression
as well

36. rewind :ref => ‘tag’

37. skip :ref => ‘tag’

38. ‣ concurrent_iterator
‣ :times / :branches
‣ add_branches partner expression

39. concurrent_iterator

40. concurrent_iterator

41. ‣ ruote 0.9.x had the ‘eval’ expression
‣ evaluating segments of process
‣ ruote 2.0 has ‘apply’
‣ same mission
‣ and more (yield)

42. vanilla apply

43. yield like apply

44. set ‘v:x’ => ‘y’

45. ‣ engine variables
‣ can be read from processes
‣ cannot be set from processes
‣ are thus on the same foot as
participants
(which are registered at the engine
level)

46. engine vars

47. engine vars

48. ‣ more about
process definitions and
expressions
http://ruote.rubyforge.org/expressions.html
http://ruote.rubyforge.org/patterns.html

50. 2.0 projects

51. ‣ ruote-dm
datamapper persistence
http://github.com/jmettraux/ruote-dm
‣ ruote-ar
activerecord persistence
http://github.com/kennethkalmer/ruote-activerecord
‣ ruote-couch (coming soon)
couchdb persistence
http://github.com/kennethkalmer/ruote-couch

52. ‣ ruote-kit
full blown ruote-rest evolution
http://github.com/kennethkalmer/ruote-kit
‣ ruote-http
tiny sinatra ruote webservice
http://github.com/jmettraux/ruote-http

53. ‣ ruote-amqp
amqp participants and listeners
http://github.com/kennethkalmer/ruote-amqp
‣ ruote-fluo
still in the run
http://github.com/jmettraux/ruote-fluo

55. ‣ ruote [2.0] website
http://ruote.rubyforge.org
‣ ruote mailing list
http://groups.google.com/group/openwferu-users
‣ freenode.net IRC
#ruote

56. many thanks
to everyone in the community
especially to the “ruedas y cervezas”
participants ;-)