processi

about processes and engines

Activity-Based Costing (a hint)

Should I call that a ‘hint’ or a ‘small step towards a part of a solution’ ? What’s the problem to solve then ?

These days my eyes are stuck into “BPM3“, I like that book. I won’t review it here though. On page 94, they mention Activity-Based Costing. I’ve seen this enabled within some commercial workflow engines.

I won’t explain what hides behind this concept, I won’t provide any full solution for it, I’ll just give a hint on how a cost statistic could get gathered within a process definition. It will also demonstrate a bit how expressive OpenWFE can get.

So here is a process definition, in OpenWFE lingo :

<process-definition name="abc-process" revision="0.99">

    <sequence>
        <set field="total-cost" value="0" />

        <activity aname="activity-a" acost="100" />
        <activity aname="activity-b" acost="200" />

        <if test="${f:need-more}" >
            <!-- then -->
            <activity aname="activity-c" acost="100" />
            <!-- else -->
            <activity aname="activity-d" acost="50" />
        </if>

        <participant ref="gather-stats" />
    </sequence>

    <process-definition name="activity">
        <sequence>
            <set field="total-cost" inc="${acost}" />
            <participant ref="${aname}" />
        </sequence>
    </process-definition>

</process-definition>

The body of the process definition is just a sequence with 4 participants involved. The last participant in the sequence is less vague than the ‘activity-*’ ones, it’s meant to dump the field ‘total-cost’ somewhere (within a db ?) for further mining.
The others (activity-*) are maybe webservice calls or human participants. The engine doesn’t care, its participant-map knows, it could change, at its own pace, following its own rules.

In the [sub]process-definition, you can see that two variables, ‘acost’ and ‘aname’, are involved, and you perhaps noticed that they are in fact attributes of the newly available ‘activity’ expression pointing to our subprocess, which conveniently hides the detail of the ‘cost gathering’ from the body of the process definition.

This ‘costing’ tool (our ‘activity’ process) could be advantageously at use within a process definition with a cursor within which a flow rides back and forth :

    <cursor>
        <activity aname="activity-a" acost="100" />
        <activity aname="activity-b" acost="200" />
        <activity aname="activity-c" acost="50" />
    </cursor>

OpenWFE comes with a library service within its engine. This service’s task is to interpret engine-wide process definitions that are then made available to all the process definitions within that engine. The subprocess definition ‘activity’ would happily fit there, providing ‘costing’ to all the process definitions within the engine.

Out of the box, the library service read to engine-wide process definitions from the etc/engine/library.xml file.

Written by John Mettraux

May 17, 2006 at 7:50 pm

Posted in books, bpm, openwfe, workflow

%d bloggers like this: