ruote tmp/log_2012-07-29.html

2012-07-29 12:51:00 utc anon Hi all, is anyone here?
2012-07-29 13:12:57 utc jmettraux anon: hello, welcome to #ruote
2012-07-29 13:26:00 utc anon hi :)
2012-07-29 13:26:09 utc anon I wanted to have a short chat
2012-07-29 13:26:31 utc anon to get some light on a couple of questions
2012-07-29 13:26:46 utc jmettraux ok
2012-07-29 13:27:22 utc anon My company is building a system
2012-07-29 13:27:37 utc anon based on rails web apps
2012-07-29 13:27:51 utc anon that interact between them
2012-07-29 13:28:15 utc jmettraux (sometimes, the mailing list is more responsive )
2012-07-29 13:28:27 utc jmettraux so, more like web services than web apps?
2012-07-29 13:28:29 utc anon the system is meant to handle a medium-mig ammount of data daily
2012-07-29 13:28:33 utc anon yeah web services
2012-07-29 13:28:51 utc anon The thing is that we were considering using ruotes
2012-07-29 13:28:58 utc jmettraux medium-mig == ?
2012-07-29 13:29:23 utc anon the actual datebase is about 100GB
2012-07-29 13:29:41 utc anon you get the idea
2012-07-29 13:29:52 utc jmettraux vaguely
2012-07-29 13:30:04 utc anon hmmm, I can't really go into details
2012-07-29 13:30:32 utc jmettraux what kind of workflow do you want to run?
2012-07-29 13:30:52 utc anon well, I just started looking at it today
2012-07-29 13:31:01 utc anon not even sure
2012-07-29 13:31:06 utc jmettraux what's your use case?
2012-07-29 13:31:23 utc anon there are a lot of them, but that's not even what I wanted to ask today :)
2012-07-29 13:31:28 utc jmettraux ok
2012-07-29 13:31:55 utc anon The question is, I see that ruotes is is a workflow system that some people have used on rails
2012-07-29 13:32:12 utc anon but wasn't meant to be run on rails initially
2012-07-29 13:32:22 utc jmettraux it's a ruby library
2012-07-29 13:32:26 utc jmettraux rails doesn't matter
2012-07-29 13:32:49 utc anon yeah, I mean it wasn't specifically made to be used on web services
2012-07-29 13:33:14 utc jmettraux well, Rails isn't specifically made to implement web services...
2012-07-29 13:33:42 utc anon I'm just afraid we will have to make a lot of tuning to make it work properly on a distributed web service with multiple rails applications
2012-07-29 13:34:00 utc anon wanted to know first hand if we're looking on the proper direction with ruotes
2012-07-29 13:34:08 utc anon before even trying it
2012-07-29 13:34:28 utc jmettraux if you don't know what you want / can do with it, then yes, don't use it
2012-07-29 13:34:35 utc jmettraux don't even bother thinking about tuning it
2012-07-29 13:34:49 utc jmettraux what do you use usually for background processing?
2012-07-29 13:35:35 utc anon plain ruby
2012-07-29 13:36:12 utc jmettraux do you make the heavy work running in the Rails request cycle? You don't push it on some backburner?
2012-07-29 13:36:30 utc jmettraux no queuing system in your architecture?
2012-07-29 13:36:48 utc anon no
2012-07-29 13:37:02 utc jmettraux ok
2012-07-29 13:37:11 utc anon there's no heavy processing at all
2012-07-29 13:41:50 utc anon so, I'm not sure what you meant with "yes, don't use it", I know what we want, but after spending a couple of hours through your documentation, I'm not sure ruotes will be able to escalate the way we need it to
2012-07-29 13:42:20 utc jmettraux so don't use it
2012-07-29 13:42:32 utc jmettraux follow your instinct
2012-07-29 13:43:07 utc anon well, my instinct is nothing after just 2 hours compared to someone from inside, that's why I came lol
2012-07-29 13:43:17 utc anon if I was to follow my instinct I would have never asked
2012-07-29 13:43:34 utc jmettraux I don't know what you mean by escalate
2012-07-29 13:43:43 utc jmettraux I know zero from your architecture
2012-07-29 13:43:51 utc jmettraux I don't know what workflows you want to run
2012-07-29 13:43:59 utc jmettraux you have no goal
2012-07-29 13:44:06 utc jmettraux I'm sorry I cannot answer
2012-07-29 13:44:21 utc anon ok, ok, I'll throw in more details
2012-07-29 13:46:54 utc anon about 2000 employees using the system daily, we have one rails app for each "division", but they interact together for part of the work, some of the workflows this employees would have to follow would involve jumping from one application to another and interacting with multiple rails applications
2012-07-29 13:47:11 utc anon our idea was to use a "central workflow" system to put some order to all this mess
2012-07-29 13:47:15 utc anon if you know what I mean
2012-07-29 13:47:37 utc jmettraux please define "jumping from one application to the other"
2012-07-29 13:48:16 utc anon " and interacting with multiple rails applications" -> interacting with multiple other employees
2012-07-29 13:48:23 utc anon and about your question
2012-07-29 13:48:23 utc anon hmmm├ž
2012-07-29 13:49:34 utc jmettraux does each application have an API?
2012-07-29 13:49:37 utc anon yes
2012-07-29 13:50:09 utc jmettraux what about developing a centralized front web app, that talks to each specific service via its API?
2012-07-29 13:51:13 utc anon well, our idea was to use a central workflow system that would take users from one web app to another in a kind of "transparent" way
2012-07-29 13:51:32 utc jmettraux sounds like web navigation
2012-07-29 13:51:55 utc anon yeah, but web navigation means
2012-07-29 13:52:02 utc anon I have to "hard code"
2012-07-29 13:52:07 utc anon this links into each app
2012-07-29 13:52:29 utc anon we want to abstract the navigation logic into centralized system
2012-07-29 13:52:49 utc anon that's what we thought the workflow engine would do
2012-07-29 13:53:08 utc jmettraux ok
2012-07-29 13:53:35 utc anon so, are we looking in the right direction? :)
2012-07-29 13:53:52 utc jmettraux no, I'm sorry, ruote is not meant for this kind of "work flow"
2012-07-29 13:54:32 utc anon could you please elaborate a bit on this? I'd like to be able to explain them why
2012-07-29 13:54:44 utc jmettraux ruote is about orchestration
2012-07-29 13:54:57 utc jmettraux you launch a workflow and it does A then B then C
2012-07-29 13:55:12 utc jmettraux sometimes one of this steps involves a human participant
2012-07-29 13:55:31 utc jmettraux that usually materializes as a workitem appearing in the inbox of the user
2012-07-29 13:55:47 utc jmettraux the rest of the time the activity is a piece of Ruby code that gets executed
2012-07-29 13:56:24 utc jmettraux things happen asynchronously, outside of the request-response cycle of typical web applications
2012-07-29 13:56:49 utc jmettraux the kind of work flow you want is totally synchronous
2012-07-29 13:57:49 utc anon hmmm
2012-07-29 13:58:17 utc anon I see what mean,
2012-07-29 13:58:39 utc anon but now I don't understand in which circumstances people use ruotes in real life
2012-07-29 13:58:50 utc anon could you give me a simple example?
2012-07-29 14:00:14 utc jmettraux ok
2012-07-29 14:02:21 utc anon so?
2012-07-29 14:02:39 utc jmettraux hey, it's sunday evening here, 2255
2012-07-29 14:02:44 utc jmettraux cut me some slack
2012-07-29 14:02:59 utc jmettraux ok,, first piece of code top left
2012-07-29 14:03:47 utc jmettraux it's a workflow that describes a review process
2012-07-29 14:03:57 utc jmettraux there are three persons involved
2012-07-29 14:04:21 utc jmettraux reviewer1 and 2 and editor
2012-07-29 14:04:44 utc jmettraux the editor can force the flow to rewind if he's not happy with the review work
2012-07-29 14:04:51 utc jmettraux the two editors have to redo the work
2012-07-29 14:05:06 utc jmettraux note that the two reviewers work concurrently
2012-07-29 14:05:31 utc jmettraux once they have both emitted a review, the editor gets involved (he receives a workitem)
2012-07-29 14:06:06 utc jmettraux the last step of the workflow is "publish", since it's a verb, we know it's an automated action (not a human participant)
2012-07-29 14:06:36 utc jmettraux the engine pushes work to participant and fetches their replies, it's orchestrating their workflow
2012-07-29 14:06:46 utc jmettraux ok, that's a small example
2012-07-29 14:07:16 utc jmettraux on the left side there is a graphical representation of the flow
2012-07-29 14:09:49 utc anon but it seems like it's totally sinchronous to me,
2012-07-29 14:09:57 utc anon I mean, yeah, it gets published
2012-07-29 14:10:06 utc anon because the last guy presses accept
2012-07-29 14:10:28 utc anon but just like in my system some actions make things go into a datebase
2012-07-29 14:10:35 utc anon just that in my case rails is taking care of that already
2012-07-29 14:10:57 utc jmettraux cool
2012-07-29 14:11:06 utc anon and yeah sorry about the sunday disturbing :S
2012-07-29 14:18:30 utc jmettraux well, ruote has a queue-worker architecture, it queues pieces of work for execution by one or more workers
2012-07-29 14:18:41 utc jmettraux so it has difficulties being synchronous
2012-07-29 14:19:36 utc jmettraux for example when the editor will press "accept", the answer will get queued, it won't be processed immediately, in the same runtime and same thread that receives the HTTP request
2012-07-29 14:19:59 utc jmettraux you guys seem to want something that links immediately to the "next screen"
2012-07-29 14:20:06 utc jmettraux so ruote is not for you
2012-07-29 14:20:28 utc anon ok, now I totally see what you mean
2012-07-29 14:20:38 utc jmettraux great :-)
2012-07-29 14:22:40 utc anon is this a problem with all workflows engines or just the way ruotes is implemented?
2012-07-29 14:23:06 utc jmettraux all workflow engines tend to be such "orchestration engines"
2012-07-29 14:23:43 utc jmettraux I think you want something that is more like a state machine
2012-07-29 14:24:06 utc jmettraux because you go through a series of state and at any time, you're only in one state
2012-07-29 14:24:47 utc jmettraux but somehow, well, it's just a web thing
2012-07-29 14:25:00 utc jmettraux you go from one URI to the next
2012-07-29 14:25:10 utc anon yeah but you know, for instance
2012-07-29 14:25:15 utc anon say I have this form
2012-07-29 14:25:23 utc jmettraux you could have a small DSL that enumerates the screens and describe the transition between them
2012-07-29 14:25:40 utc jmettraux ok, listening
2012-07-29 14:25:47 utc anon ok
2012-07-29 14:25:49 utc anon say I have this form
2012-07-29 14:25:55 utc anon that is used on multiple places
2012-07-29 14:26:12 utc anon (just a stupid example)
2012-07-29 14:26:16 utc anon I'd have to
2012-07-29 14:26:25 utc anon pass into the form some hidden parameters
2012-07-29 14:26:39 utc anon that indicate where the user came from and where he goes next
2012-07-29 14:27:20 utc anon we thought a workflow engine would take care of all that, in such a way that the when you submit this form the user always is redirected to the central workflow engine center
2012-07-29 14:27:28 utc anon engine*
2012-07-29 14:27:44 utc anon and then that engine decides where he is going next
2012-07-29 14:27:54 utc anon depending on what he was doing before
2012-07-29 14:28:04 utc jmettraux the usual workflow engine provides with a task list
2012-07-29 14:28:11 utc jmettraux you log in and you see a list of tasks
2012-07-29 14:28:19 utc jmettraux the usual task is a set of forms
2012-07-29 14:28:34 utc jmettraux you fill them and press proceed or push back or cancel
2012-07-29 14:28:41 utc jmettraux and that's it
2012-07-29 14:29:18 utc jmettraux I've never seen a workflow engine that does what you do
2012-07-29 14:29:22 utc jmettraux but it makes sense
2012-07-29 14:29:39 utc jmettraux your screens/forms could always redirect to the central "controller"
2012-07-29 14:30:04 utc jmettraux that would pick the cookie in the request, look at the flow instance and redirect to the next screen
2012-07-29 14:30:54 utc jmettraux sounds fun
2012-07-29 14:31:01 utc anon well, I think you're starting to see why I came here, by looking at all this it kind of seems like "it has something to do with my problem"
2012-07-29 14:31:12 utc anon but it also seems like what I exactly need hasn't been really explored before
2012-07-29 14:31:18 utc anon not with workflow engines at least
2012-07-29 14:31:31 utc anon that's why I wanted to know someone from inside opinion
2012-07-29 14:31:33 utc anon :)
2012-07-29 14:31:41 utc jmettraux there's another take on your situation
2012-07-29 14:31:50 utc jmettraux make APIs for all the apps
2012-07-29 14:31:56 utc jmettraux and then have a central app
2012-07-29 14:32:09 utc jmettraux unified front end
2012-07-29 14:32:23 utc jmettraux the controllers would simply make HTTP calls
2012-07-29 14:32:43 utc jmettraux your situation sounds a bit of legacy
2012-07-29 14:33:02 utc anon well, the problem is that
2012-07-29 14:33:09 utc anon we have started thinking about workflows
2012-07-29 14:33:14 utc anon a bit late
2012-07-29 14:33:17 utc jmettraux but well, whatever, if there is a way to "jump between screens" then it's cool
2012-07-29 14:33:54 utc jmettraux at least you're not stuck with a single monolithic Rails application
2012-07-29 14:34:29 utc anon but to me, this unified front ned
2012-07-29 14:34:42 utc anon sounds like if at the end we were implementing our own workflow engine
2012-07-29 14:34:55 utc anon just that you move the views to the central app too
2012-07-29 14:35:10 utc jmettraux somehow yes
2012-07-29 14:35:24 utc jmettraux "webflow engine"
2012-07-29 14:36:22 utc anon just out of curiosity
2012-07-29 14:36:34 utc anon are you the ruote creator?
2012-07-29 14:36:39 utc jmettraux yes
2012-07-29 14:36:48 utc anon ok, great
2012-07-29 14:37:58 utc jmettraux maybe you can have more luck if you search for a "wizard" (defining a flow of screen/forms)
2012-07-29 14:39:28 utc jmettraux anon: have to go to bed now
2012-07-29 14:39:35 utc jmettraux have a good day
2012-07-29 14:39:46 utc anon have good night
2012-07-29 14:39:50 utc anon and thanks a lot
2012-07-29 14:39:51 utc jmettraux thanks!
2012-07-29 14:39:57 utc anon :)