Hello John, thanks for the quick reply! Hopefully it won't be another million years before Ruote can support some of this ;)
>Now I realize you want something a bit different, in fact you want this filtering but you also >want the "subprocess signature enforcement", am I right ? Yes what I'm thinking is a mechanism by which a sub-process could specify what its 'inputs'/'output' are and a process could then map the current workitem fields to these inputs and map back the 'outputs' to the current workitem field. To take a concrete example: imagine a process used to launch servers in the cloud. That process requires a list of server ids 'server_ids' and a cloud id 'cloud_id'. This process would be used in many other processes - anytime servers need to be launched. However how that list of server ids could be retrieved in many different ways. In one process it may be an initial field but in another it may be the result of looking up servers using a 'lookup' process which would set that list in e.g. the __result__ field. We would want that 'launch_servers' process to clearly state what the required initial fields are and enforce that the fields are indeed there before handing it off to it (or have a participant check it right at the beginning). I think a difference with the use case you linked to is that we would like this definition to be explicit in the workflow, a sort of 'contract' that is defined by the sub-process. The FieldsDefinitionParticipant was an attempt at defining such a contract. We can implement this validation today but the one piece we would be missing is the scoping, that is making sure the sub-process has its own workitem. >I guess the launch call would immediately fail. Patrice, in that thread, really wants the process >to fail immediately (not asynchronously). >What is your take ? That makes sense to me, at some level this would be an error in the workflow definition itself rather than an error in the execution so the earlier the failure the better. >Via a participant is right. >What happens when the expected fields are not here ? Error ? Yes, it's a contract violation. The filtering mechanism you describe could help 'reuse' the contract definitions for multiple sub-processes but we would want the definition to be explicit in the workflow rather than embedded in a participant. The filtering would give some of the scoping too. I'm wondering: where would the fields "filtered out" be stored so that they can be merged back after the participant replies? -- Raphael. On Thu, Jan 27, 2011 at 4:08 PM, John Mettraux <[email protected]>wrote: > > On Thu, Jan 27, 2011 at 03:35:34PM -0800, Raphael Simon wrote: > > > > In terms of validation of fields I also could not find anything readily > > available. I put a FieldsValidationParticipant > > <https://gist.github.com/799298>together, wonder if that's going in the > > right direction? > > Hello Raphael, welcome back. > > Back a million year ago, when ruote was OpenWFE, a Java workflow engine, > participants could be tied to filters. Those filters controlled which fields > went to the real participant and then handled the merge when the workitem > came back. > > When I moved to Ruby, I wanted (maybe still want ( > https://github.com/jmettraux/ruote/blob/7675a47da31485fffd6d160ab2f5592a08a0affe/TODO.txt#L290-291)) > to have this feature in ruote, but I realized people built very smart > participant implementations, very quickly (it's Ruby), and they all had > slightly different needs. > > Now I realize you want something a bit different, in fact you want this > filtering but you also want the "subprocess signature enforcement", am I > right ? > > > so to summarize: > > > > 1. How does one validate workitem fields in ruote (e.g. the initial > workitem > > fields)? > > Ah validation at launch time... I've been resisting this feature for a > while : > > > http://groups.google.com/group/openwferu-users/browse_thread/thread/4ea83ccfbc1caa87 > http://groups.google.com/group/openwferu-users/msg/8504cf9e065a4607 > > I guess the launch call would immediately fail. Patrice, in that thread, > really wants the process to fail immediately (not asynchronously). > > What is your take ? > > > 2. How would a sub-process define the fields it expects and how would the > > parent process do the mapping? > > Via a participant is right. > > What happens when the expected fields are not here ? Error ? > > > I could be that I'm completely missing the 'philosophy' being ruote, > please > > let me know if that's the case... > > The philosphy on that, is more like trying to delay the implementation > decision until it's really needed. > > So let's look at the current 'way' : > > ---8<--- > Ruote.define do > define 'y' do > filterTwoIn > participany 'z' > filterTwoOut > end > sequence do > filterOneIn > participant 'x' > subprocess 'y' > filterOneOut > end > end > --->8--- > > Quite verbose. > > One thing we could do is introduce a :filter attribute (on any expression), > that would trigger a participant upon applying an yet another upon leaving > (replying to the engine). > > ---8<--- > sequence :filter => 'one' do > # ... > end > > class LevelOneFilter > def consume(workitem) > # filter (and keep original) > end > def on_reply(workitem) > # unfilter (merge incoming and original) > end > end > > engine.register_participant 'one', LevelOneFilter > --->8--- > > Maybe it's "perverting" participants a bit too much, but it could shorten > our process definitions : > > ---8<--- > Ruote.define do > define 'y' do > participany 'z', :filter => 'two' > end > sequence :filter => 'one' do > participant 'x' > subprocess 'y' > end > end > --->8--- > > What do you think ? > > Best regards, > > -- > John Mettraux - http://jmettraux.wordpress.com > > -- > you received this message because you are subscribed to the "ruote users" > group. > to post : send email to [email protected] > to unsubscribe : send email to > [email protected]<openwferu-users%[email protected]> > more options : http://groups.google.com/group/openwferu-users?hl=en -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
