As I see it, this workflow engine will be an excellent platform on which to build any kind
of organizationally oriented system. A case in point is a typical retail online commerce
scenario, which runs like this:
- Customer submits order (the process of building the order, i.e. the shopping cart, is
separate from the order process itself.)
- Merchant processes payment. Notifies customer when payment clears, and places order(s)
with supplier or suppliers of the items in the customer's order.
- Suppliers fulfill line items from orders. Each shipment causes notification of the
customer with tracking information.
- Upon order completion, the merchant is notified and the customer is notified that the
order is complete.
(2/21/00) XML process definition here.
This is a pretty straightforward workflow, but it differs from previous scenarios in that
there are multiple line items for the suppliers to fill. For instance, consider a merchant
who sells T-shirts made by one supplier and mugs made by a different supplier. A customer
comes along to the storefront and orders three T-shirts and a mug. Notifications go out
to both suppliers. When the goods are ready to ship, each supplier goes to a shipping
update screen and submits tracking information. The T-shirt supplier could even ship the
T-shirts separately, if two are in stock and the third one on backorder, resulting in three
notifications. (The online bookstores do the same thing, if you've ever placed a large
book order combining items in stock and on order.)
My point with this scenario is that iteration is necessary, in other words, the notion that
a particular phase of the process isn't complete until all line items are accounted for.
This may require multiple passes through some tasks. Another way of looking at this is that
the (partial) fulfillment of a task (supply three T-shirts, and I've only shipped two) may
result in the creation of a new task to represent the completion of the original (supply that
last shirt and you're off the hook). A decision is made when the shirt supplier
submits the first time as to whether the recorded action fulfills the task or not.
As I was writing this one up, I was reading about Petri nets and their application to workflow
systems. The author maintained that representation of workflow in terms of Petri nets
allowed a great deal of analysis to be performed automatically, and so I drew up a Petri
net to represent this process. It really didn't convey any more information than the
RAD, though. I think that if we want to get into analysis at some later date, then whatever
description we use can just as well be transformed into a Petri net and then analyzed.
Summary:
- Iteration is necessary.
- Partial fulfillment of tasks seems a reasonable option.
Note that partial fulfillment of tasks will result in a list of enactments which reflects
exactly what happened: two shirts supplied on 12/12, one more on 12/15. This part was one
which I had a great deal of trouble with in my own ecomm implementation, and this is one
of the reasons I will probably rewrite the whole system on top of the wftk.
|
