Dynamic workflows with ruote and open workflow repositories ...
kedar mhaswade
John Mettraux
Hello Kedar,
welcome to the ruote mailing list.
On Fri, Feb 03, 2012 at 10:53:41AM -0800, kedar mhaswade wrote:
>
> 0- For my Rails app, what should I be using -- ruote-kit+quaderno or ruote
> is to be used directly along side my application models/resources?
It depends on your needs.
Ruote-kit brings you a free admin interface.
Some people go directly for ruote.
Quaderno is nice but it perhaps doesn't fit your requirements or the tastes
of your designer.
Use what you understand (and understand you need).
> 1- Is it possible that a particular process is modified after a few
> instances of it are created? In other words, let's say a process
> administrator who is a user of my application wants to change the course of
> a process after a particular state has been achieved, will that be possible
> for me to provide using ruote?
Yes.
You should look at
http://ruote.rubyforge.org/process_administration.html#re_applying
it explains how to re_apply an expression. That technique is useful for
modifying process instance "in-flight".
> 2- How do we import/export a particular workflow/process definition?
Internally ruote stores them as JSON strings. When passing them around, any
format understood by ruote is OK.
* Ruby: https://github.com/jmettraux/ruote/blob/14bbe62447585164ea8b016185999c5804285703/test/unit/ut_0_ruby_reader.rb#L22-36
* XML: https://github.com/jmettraux/ruote/blob/14bbe62447585164ea8b016185999c5804285703/test/unit/ut_9_xml_reader.rb#L17-31
* radial: https://github.com/jmettraux/ruote/blob/14bbe62447585164ea8b016185999c5804285703/test/unit/ut_24_radial_reader.rb#L177-193
> Is there a repository where people share such definitions?
> I suppose these
> can't be standard, but since several processes are "typical", there should
> be a way of consuming them in an open manner and formats (XML, JSON)?
Sorry, there is no such repository, it would indeed be very easy to do. We
could start a git repository for that.
Anyone here could mail me interesting processes, and I'll start a github
repository for it.
IIRC, XML isn't used by anyone. Processes in their Ruby or radial
representations are much easier to read than XML or JSON. Ruote just adapts.
Best regards,
--
John Mettraux - http://lambda.io/processi
kedar mhaswade
Hello Kedar,
welcome to the ruote mailing list.
It depends on your needs.
On Fri, Feb 03, 2012 at 10:53:41AM -0800, kedar mhaswade wrote:
>
> 0- For my Rails app, what should I be using -- ruote-kit+quaderno or ruote
> is to be used directly along side my application models/resources?
Ruote-kit brings you a free admin interface.
Some people go directly for ruote.
Quaderno is nice but it perhaps doesn't fit your requirements or the tastes
of your designer.
Use what you understand (and understand you need).
Yes.
> 1- Is it possible that a particular process is modified after a few
> instances of it are created? In other words, let's say a process
> administrator who is a user of my application wants to change the course of
> a process after a particular state has been achieved, will that be possible
> for me to provide using ruote?
You should look at
http://ruote.rubyforge.org/process_administration.html#re_applying
it explains how to re_apply an expression. That technique is useful for
modifying process instance "in-flight".
Internally ruote stores them as JSON strings. When passing them around, any
> 2- How do we import/export a particular workflow/process definition?
format understood by ruote is OK.
* Ruby: https://github.com/jmettraux/ruote/blob/14bbe62447585164ea8b016185999c5804285703/test/unit/ut_0_ruby_reader.rb#L22-36
* XML: https://github.com/jmettraux/ruote/blob/14bbe62447585164ea8b016185999c5804285703/test/unit/ut_9_xml_reader.rb#L17-31
* radial: https://github.com/jmettraux/ruote/blob/14bbe62447585164ea8b016185999c5804285703/test/unit/ut_24_radial_reader.rb#L177-193
* JSON: https://github.com/jmettraux/ruote/blob/14bbe62447585164ea8b016185999c5804285703/test/unit/ut_24_radial_reader.rb#L187-189
Sorry, there is no such repository, it would indeed be very easy to do. We
> Is there a repository where people share such definitions?
> I suppose these
> can't be standard, but since several processes are "typical", there should
> be a way of consuming them in an open manner and formats (XML, JSON)?
could start a git repository for that.
Anyone here could mail me interesting processes, and I'll start a github
repository for it.
IIRC, XML isn't used by anyone. Processes in their Ruby or radial
representations are much easier to read than XML or JSON. Ruote just adapts.
John Mettraux
On Fri, Feb 03, 2012 at 12:31:23PM -0800, kedar mhaswade wrote:
>
> I see. Does it mean I can plug in the admin interface provided by ruote-kit
> in my web application?
Yes.
You can, for example, add this to your config/routes.rb:
---8<---
# routes to RuoteKit
match '/_ruote' => RuoteKit::Application
match '/_ruote/*path' => RuoteKit::Application
--->8--
> Can I configure views so that there is a consistency
> across the app?
Yes, it's doable, it's Haml + CSS (and Ruby).
Generally people use ruote-kit's interface as a special admin only zone. When
they want to integrate in their core webapp, they look at ruote-kit for
inspiration and build their own views and controllers.
> Yeah, trying to understand the choices that I should make. I do need to
> give (some of) my users an ability to modify process definitions, so an
> admin interface is required, I believe.
Do you mean "modify process instances"? If you need to modify process
definitions, only a text editor is required.
The admin interface is handy for administering the system, not really to
design process definitions.
Maybe you meant modifying process instances and in that case, yes, the admin
interface offered by ruote-kit is handy (for process administrators).
> But then, I am assuming that I will
> do that using ruote abstractions. Additionally, Kenneth's blogpost gave me
> an impression that making a commitment to implementing workflows in your
> application is a fairly heavy-weight decision and I was not sure if I
> should do that, given that at least initially, most of the decisions are
> going to be made by other users logging in to my application (there are no
> multiple applications/services involved). Looks like I have deliberated
> enough and am leaning toward using ruote.
It's still OK for you to go with simpler abstractions, business objects and
plain controllers that modify their states, simple business rules and no
workflow engine problems.
It's true that ruote is heavy-weight. You shouldn't dive directly into
building something with it. Take the time to do a prototype, then you can
make the right decision.
I'm not selling anything to you. As a fellow developer, it's my duty to tell
you not to use ruote if it leads to too convoluted a sytem.
kedar mhaswade
Thank you for your response!
>Yes.
> I see. Does it mean I can plug in the admin interface provided by ruote-kit
> in my web application?
You can, for example, add this to your config/routes.rb:
---8<---
# routes to RuoteKit
match '/_ruote' => RuoteKit::Application
match '/_ruote/*path' => RuoteKit::Application
--->8--
Yes, it's doable, it's Haml + CSS (and Ruby).
> Can I configure views so that there is a consistency
> across the app?
Generally people use ruote-kit's interface as a special admin only zone. When
they want to integrate in their core webapp, they look at ruote-kit for
inspiration and build their own views and controllers.
Do you mean "modify process instances"? If you need to modify process
> Yeah, trying to understand the choices that I should make. I do need to
> give (some of) my users an ability to modify process definitions, so an
> admin interface is required, I believe.
definitions, only a text editor is required.
The admin interface is handy for administering the system, not really to
design process definitions.
Maybe you meant modifying process instances and in that case, yes, the admin
interface offered by ruote-kit is handy (for process administrators).
It's still OK for you to go with simpler abstractions, business objects and
> But then, I am assuming that I will
> do that using ruote abstractions. Additionally, Kenneth's blogpost gave me
> an impression that making a commitment to implementing workflows in your
> application is a fairly heavy-weight decision and I was not sure if I
> should do that, given that at least initially, most of the decisions are
> going to be made by other users logging in to my application (there are no
> multiple applications/services involved). Looks like I have deliberated
> enough and am leaning toward using ruote.
plain controllers that modify their states, simple business rules and no
workflow engine problems.
It's true that ruote is heavy-weight. You shouldn't dive directly into
building something with it. Take the time to do a prototype, then you can
make the right decision.
I'm not selling anything to you. As a fellow developer, it's my duty to tell
you not to use ruote if it leads to too convoluted a sytem.
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en
John Mettraux
On Fri, Feb 03, 2012 at 04:32:40PM -0800, kedar mhaswade wrote:
>
> Well, I meant process definitions. And that is the confusion I have. My
> understanding with dynamic workflow was that it is a process that is not
> fully determined at the time of initial creation and instead is defined (at
> least partially) at run-time. For instance, the user who created the
> process determines next steps after a checkpointing step has been reached.
> And it is this user who I termed as process administrator. I guess my
> terminology is wrong. Does such an interpretation of "workflow" make sense?
> Or does the process definition have to be usually determined a priori?
Maybe this might interest you:
http://jmettraux.wordpress.com/2010/01/29/barley/
Maybe "process owner" or "process initiator" is better. On the other hand, if
you like "process administrator", you could rename the guy who plays with
ruote-kit the "ruote administrator" or simply the "system administrator".
> > The admin interface is handy for administering the system, not really to
> > design process definitions.
>
> I see. But since some of my users need to be given a web interface to
> create/modify the processes, it is important for me to do more than text
> editor?
Unfortunately, I'm sure you'll find the process editor included in (and
extractable from) ruote-kit very limited, it will certainly set off your
users.
On the other hand, if you go for very dynamic workflows, process edition can
be limited to "choose who comes next" and there is no need for a text area or
graphical process editor for that.
> > Maybe you meant modifying process instances and in that case, yes, the
> > admin
> > interface offered by ruote-kit is handy (for process administrators).
>
> Process instances are modified by the actions taken by participants is what
> I thought I read, e.g. in the "getting started" example (which I ran), the
> state of process instance was modified when :alpha got a message and then
> passed it on to :bravo via the workitem. The process definition itself was
> fully determined -- a sequence of two participants, :alpha and :bravo.
>
> Am I not understanding it right?
Makes sense, I would rather say "handling a workitem" or "performing a task"
in those cases, but you are right, it modifies the process instance.
I was thinking you were still referring to "in-flight process modification".
> That's what I am trying to assess. And though the complexity seems to
> increase with the use of ruote, what I am doing seems to be modeled
> corrected as a "process" or "business process". And going back and forth
> between ruote and state_machine confuses me even further.
A business process orchestrates business objects. When there is no
orchestration (nothing wrong with that), the objects synchronizes their
states with each other, hopefully letting a useful choreography emerge.
> To make it somewhat more concrete, what I am trying to do is model a hiring
> process. Every company seems to have a process for it (e.g. phone screen(s)
> followed by technical interviews followed by HR interview, followed by
> background check and a negotiation phase ... and some of these are
> optional). Any applicant applying for a job at such a company would need to
> pass through this process. The process creator needs to assign actual users
> to certain roles (e.g. interviewer), schedule the interviews etc. And this
> is a typical process or it may needs to be modified from company to company
> (and that's why I need a proper user interface for the users who do that).
> My gut tells me that using workflow to model such a situation is the right
> way to go.
Yes, it feels right to have a "pattern" to follow.
> Would you disagree? Is a state_machine (or a few of them) in a better
> position to capture the essence of this?
Quick concept:
---8<---
define 'hiring process' do
cursor do
applicant :task => 'fill in initial details'
hr_clerk :task => 'initial screening'
stop :if => '${bad}'
rewind :if => '${not_enough_info}'
cursor do
concurrence do
hr_manager :task => 'interview'
tech_lead :task => 'interview'
end
rewind :if => '${not_enough_info}'
end
applicant :task => 'decision notification'
end
end
--->8---
With a state machine, you'd flag the "application" business object with "in
progress", "doing this", "doing that", and ... Well you know.