Topic: wftk -- Process definition example -- SourceXchange

wftk home ] [ process definition ] [ discussion ]
This is an attempt at the basic process outlined in the SourceXchange development scenario. This is probably the most complex scenario of the ones I did.
<?xml version="1.0"?>

<workflow name="SourceXchange project" author="Michael:">
  <role name="Proposer"></role>
  <role name="Sponsor"></role>
  <role name="Reviewer"></role>
  <role name="SourceXchange"></role>

  <data name="SourceXchange project number" type="integer"></data>
  <data name="Proposing party" type="record">
     <!-- Just a thought: for non-database records, we should be able to define the record here... -->

     <task label="Submit proposal" role="Proposer" agent="${Proposing party}">
     <task label="Accept proposal" role="Sponsor">
        <task label="Plan project" role="Proposer">
           <data name="Detailed project plan" type="document"></data>
        <task label="Assign reviewer" role="SourceXchange"></task>
        <task label="Ready project record (milestones, lead, etc.)" role="SourceXchange"></task>
     <start name="${Detailed project plan}" location="deliverable" mode="merge" completion="Signoff">
        <task label="Accept project" role="Sponsor"></task>
        <task label="Accept project" role="Reviewer"></task>
     <task label="Make source code available" role="SourceXchange"></task>

  <subprocess name="Signoff">
    <data name="Milestone" type="task"></data>
    <if expr="${} not like 'Milestone%'">
      <data name="Milestone.status" value="accept"></data>
          <task label="Accept milestone" role="Sponsor">
            <data name="Sponsor's answer" type="choose(accept, reject)"></data>
          <task label="Accept milestone" role="Reviewer">
            <data name="Reviewer's answer" type="choose(accept, reject)"></data>

        <if expr="${Sponsor's answer} = accept">
          <data name="Milestone.status" value="accept"></data>
          <elseif expr="${Reviewer's answer} = reject"/>
          <data name="Milestone.status" value="reject"></data>
          <situation name="Milestone dispute"><data name="Milestone"></data></situation>


Milestone signoff
About the only really surprising thing here is the assignment of a subprocess as the signoff procedure for a task in the project plan. I'm not entirely happy with the ad-hoc syntax I used to express this, as it feels too off-the-cuff. As you can see, I simply used a modifier completion= and specified a subprocess. The subprocess then expects as its parameter a task. (Note the use of a "task" data type for this. I like that.)

The subprocess checks its called task by name to see whether it's a milestone. I don't like that either, but to impose the ability on the process design tool to decorate tasks with flags and things that I could check for this sort of purpose might also be a bit complicated. So -- something else to think about.

Once the subprocess has come to a conclusion, it sets the task's status to "accept" or "reject". Again, I like this.

Remember that we want the ability to do this sort of thing across the board for administrative tasks: for any system task, we should have the ability to specify a workflow to be used to accomplish it. This includes things like task signoff, role assignment, user maintenance, and so on. Using it for task signoff in this case, therefore, should be pretty straightforward. I can fairly well guarantee I won't stick with this syntax, though. Ugh. I'd welcome any suggestions. (Thomas?)

like 'Milestone%'
I guess I just can no longer live without pattern-matching facilities for strings. I've borrowed SQL syntax here, but it would probably make more sense to use regexp for pattern matching, as it's already written under GNU license and it's far more powerful. Opinions?

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.