| 2012-11-16 22:05:30 utc | chongyu123 | can you use ruote as service like? meaning interact via some defined interface? |
| 2012-11-16 22:06:15 utc | jmettraux | chongyu123: hello, welcome to #ruote |
| 2012-11-16 22:06:52 utc | jmettraux | chongyu123: yes, it's a library, it has an interface |
| 2012-11-16 22:07:50 utc | jmettraux | or do you mean something like a web service? |
| 2012-11-16 22:09:17 utc | chongyu123 | when workflow step requires a user approval, can another application ask the user for required approval and somehow let ruote know to continue? |
| 2012-11-16 22:10:24 utc | jmettraux | yes, you can implement a participant that queries an external application |
| 2012-11-16 22:11:09 utc | chongyu123 | how about the other way around? can external application query (and participate) in ruote's workflow? |
| 2012-11-16 22:11:36 utc | jmettraux | yes, the usual way to do that is to use a StorageParticipant |
| 2012-11-16 22:12:07 utc | chongyu123 | you mean using storage as a communication point? |
| 2012-11-16 22:12:11 utc | jmettraux | then other application query ruote for such workitems, then can update them and, at some point, "proceed" them so that they get back into the process |
| 2012-11-16 22:12:33 utc | jmettraux | no, using the Ruote::Dashboard's interface |
| 2012-11-16 22:13:05 utc | jmettraux | but it's also possible to implement a storage participant variant that watches the storage / db / etc for a "proceed" flag |
| 2012-11-16 22:13:21 utc | jmettraux | it's just a few lines of Ruby code away |
| 2012-11-16 22:16:10 utc | chongyu123 | I see. that makes sense. thanks! |
| 2012-11-16 22:16:39 utc | jmettraux | you're welcome |