wftk -- Process definition example -- closed source project

Topic: wftk -- Process definition example -- closed source project

[ wftk home ] [ process definition ] [ discussion ]

This is an attempt at the basic process outlined in the closed source software development scenario. This scenario is the first one which involves creation of a project plan which is then executed as a subprocess. (2/24/00) Revised to conform to the new data-tag structures I thought out yesterday.

<?xml version="1.0"?>

<workflow name="Closed source release project" author="Michael: michael@vivtek.com>">
  <role name="Analyst"></role>

  <data name="Description" type="text"></data>
  <data name="Mailing list">
    <list><data type="text"></data></list>
  </data>

  <sequence>
     <task label="Analyze" role="Analyst">
        <data name="changesource" storage="database/select * from changerequests where status='open'" readonly="yes"></data>
        <data name="changes" type="structure" value="${changesource}"></data>
     </task>
     <data name="changes.status" value="in progress"></data>
     <data name="changes.project" value="${Current process}"></data>
     <task label="Plan" role="Analyst">
        <data name="Project plan" type="document:application/xml-workflow"></data>
     </task>
     <start name="${Project plan}" location="deliverable" mode="merged"></start>
     <data name="changes.status" value="complete"></data>
  </sequence>
</workflow>

More data type shenanigans
This time I tossed in a collection of records. I'm thinking that if a data item is a collection of something, then the way you fill that collection is to select from a universe of items. So you should be able to specify the universe that can be selected from, and that is what I'm doing with that record select statement. All in all, there will certainly be a lot of interaction with databases, so it makes sense to have rich ways of specifying that interaction.

Another aspect I just tossed in is the setting of data values by the system, not merely by agents during tasks. And of course I did it rather weirdly, by setting the value of one field in each record of a set. It seems to me that collections need to be smart enough to pass actions on to their elements, and that records need to be smart enough to figure out how to select and update field values as necessary. I think it's obvious what these data tags are doing there, and it feels like a natural consequence of the syntax we're working out. Comments are welcome.

${Current process}
For those times when you just have to make reference to the current process, you pretty much have to have a way to get its identifier. This seems like a natural way of doing it. There will probably be a whole list of values that should be defined by default.

Different modes of <start>
You'll notice when starting the project plan, I introduced a couple of new modifiers: location specifies where to obtain the named process definition when starting a new plan (default is the process definition repository, but this plan isn't in the process definition repository, it's in the deliverable repository). I also figure we need different modes of start: default would be as a separate namespace, but "merged" would be nice if the points in the plan are to be considered part of the parent process (which also allows a single datasheet, which is very convenient). Then the subprocess also gets to introduce new roles, and the old (already-assigned) roles are conveniently inherited by the parent process. Another convenient start mode would be "independent" -- which would simply start a new process and go on with the present one.

Another modifier that we'll eventually need for start would be something like data="something", which would save the workflow identifier for later interaction.

Coming back to the default start mode... It should be "task" and would show in the parent process as a single task, but would appear in the list of active processes as an independent process, as long as it's a named workflow. If it's an anonymous subprocess, then I guess its tasks would have to appear in the parent process. Meaning it's merged? I guess this needs some more thought, too.