Topic: wftk -- Usage scenarios: E-commerce purchase

wftk home ] [ usage scenarios ] [ discussion ]
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:
  1. Customer submits order (the process of building the order, i.e. the shopping cart, is separate from the order process itself.)
  2. Merchant processes payment. Notifies customer when payment clears, and places order(s) with supplier or suppliers of the items in the customer's order.
  3. Suppliers fulfill line items from orders. Each shipment causes notification of the customer with tracking information.
  4. 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.


    • 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.

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