wftk -- Process definition example -- ecommerce

Topic: wftk -- Process definition example -- ecommerce

[ wftk home ] [ process definition ] [ discussion ]

This is an attempt at the basic process outlined in the retail electronic commerce scenario. I found that the ability of <data> tags to talk to databases leaves this one pretty easy.

<?xml version="1.0"?>

<workflow name="Ecomm order" author="Michael: michael@vivtek.com">
  <role name="Merchant"></role>
  <role name="Supplier"></role>

  <data name="customer" type="record" storage="database:something"></data>
  <data name="order" type="record" storage="database:something"></data>

  <sequence>
     <if expr="${order.payment_processed} = false">
        <task label="Process payment" role="Merchant">
           <data name="order">
           </data>
        </task>
        <data name="order.payment_processed" value="true"></data>
        <alert type="email" to="${customer.email}">
           Your payment has been processed and your order will be shipped soon.  Blah, blah.
        </alert>
     </if>
     
     <data name="suppliers" readonly="yes"
           storage="select distinct(supplier) from order_detail where order_number='${order.order_number}'">
     </data>

     <parallel foreach="supplier" values="${suppliers}">
        <task label="Fulfill" role="Supplier" agent="${agent}">
           <data name="order items"
                 storage="select * from order_detail where order_number='${order.order_number} and supplier='${agent}'">
           </data>
        </task>
     </parallel>
     <alert type="email" to="${customer.email}">
        Your order has been shipped.  Blah, blah with link to order status.
     </alert>
  </sequence>
</workflow>

Whoops, another sort of iteration
This one brought up something new. When I send notification to my suppliers, I am actually doing two things. First, I'm creating a task for each supplier based on the order data, and second, I'm already assigning the agent to the task! Both of these are new ideas. So you'll see that I've decorated the parallel tag with a "foreach" modifier. The foreach names the data item which each new task will see, and the "values" modifier on that is a list of values used to create the task.

This feels to me like another almost-ad-hoc kind of situation. It's not precisely ad-hoc, but it's a case where the actual tasks to be performed depend on the situation and can't be specified 100% in advance.

Oy, another weird <data> tag
You'll notice the "suppliers" data item. The type of data is a collection of text values, but the source of the data is an SQL query. A normal value assignment could use a value= modifier, but there's no straightforward way to represent a whole query situation in one string. This seems like a good way to represent this.

Note that this is not the same as defining a query as a data item. I would consider that to work like this:
<data name="suppliers" type="sql" database="something" query="select ..."></data> I would consider a query data item to be (1) readonly and (2) re-run each time it was used in the process. What I'm getting at is simply a perfectly normal list of strings which is retrieved once from the database using a query. (In this particular case I could use either one with the same result, as the item is referred to only once anyway.)

${customer.email}
I'm also using a dotted form to specify a field of a record. This is easy to understand, but I think the rule for parsing will have to be that the name of the item extends to the first non-alphanum character. That name is then used to retrieve the appropriate data item, the type of that item is discovered at that point, and then that is used to determine which data adapter gets to figure out the value. Make sense? It does to me.