wftk -- Process definition example -- trade show organization

Topic: wftk -- Process definition example -- trade show organization

[ wftk home ] [ process definition ] [ discussion ]

This is an attempt at the basic process outlined in the trade show scenario. Note that some of the tasks here must be regarded as subprocesses, but that the "subprocess nature" of these is not visible to this level. (This won't always be the case, but I think it is in this scenario. Doubtlessly some of you people will disagree.)

This XML doesn't correspond perfectly with the scenario. You've been warned.

Another thing I feel impelled to mention at the outset is that for some reason it seems right to me to include the organizer (i.e. the initiator) in the process for this example. I think that this is because in this case, the organizer has a lot more ownership of the process than in the chair purchase example.


<?xml version="1.0"?>

<workflow name="Tradeshow org" author="Michael: michael@vivtek.com">
  <role name="Organizer"></role>
  <role name="Hotel person"></role>
  <role name="Schedule person"></role>
  <role name="Catering person"></role>
  <role name="Floor layout person"></role>
  <role name="Brochure person"></role>

  <data name="Show name" type="text"></data>
  <data name="Planned date" type="text"></data>

  <sequence>
    <parallel>
      <sequence>
        <task label="Book hotel" role="Hotel person">
          <data name="Hotel booking record" type="something"/>
        </task>
        <parallel>
          <task label="Plan floor layout" role="Floor layout person">
            <data name="Floor layout" type="document"/>
          </task>
          <task label="Rough schedule" role="Schedule person">
            <data name="Schedule" type="document"/>
          </task>
        </parallel>
      </sequence>
      <task label="Book caterer" role="Catering person">
        <data name="Catering service" type="text"/>
      </task>
    </parallel>
    <task label="Create brochure" role="Brochure person">
      <data name="Floor layout" readonly="yes"></data/>
      <data name="Schedule" readonly="yes"></data>
      <data name="Brochure" type="document"></data>
    </task>
  </sequence>
</workflow>

Oddly, this process worked out cleaner than the chair. Probably because I didn't clutter it up with explicit alerts, among other things.

Data tag
Note that I've used the <data> in the "Create brochure" task in two different ways, to see whether this makes sense. Everywhere else, the data is being elicited during that task, but in this task I also included two readonly references to data elicited during other tasks. This should have the effect of highlighting those pieces of data for the person doing that task -- other data about the process shouldn't be considered hidden by this, it's just kind of a documentation thing more than anything else.

Document data type
Remember that data types are to be considered as supplied by adapter, so that the specific data types I'm talking about here aren't too important. However, in the case where the data is effectively a standalone document (a deliverable, really) then I'm using the data type "document" to indicate that the document in question is stored in the deliverable repository. Maybe really using a data type "deliverable" would be more appropriate.

That hotel booking record
OK, I'm getting sloppy there. It seems that I really want to consider something like records -- but I haven't figured out the most parsimonious way of doing it yet. So I'm kind of considering the booking record as something structured which would include a hotel name, contact there, reservation number, who knows? It would presumably be stored in a database, but it could be a little XML document. All in all, the whole data-association thing needs work.

Well, that's all I got from this example. On this level it's just not that interesting -- the whole point of the scenario was to show how useful decentrally defined subprocesses could be, and since they're all distributed, there's nothing much to see.