Process definition examples - 2

Here are a few examples taken from replies to forum posts.

You might also want to check the documentation about OpenWFE's implementation of the workflow control patterns of Prof. Van Aalst.

Order approval example

The organization model underlying this example is very simple : * unit1 * cto * cfo * ceo

The flow is generally launched by someone in the unit1, the first step leads to unit1 once again (last check), it then goes to the cto and to the cfo.

They both decide wether they agree with the purchase as planned by unit1, and they each produce a decision field ("cto_decision" and "cfo_decision").

If their decisions do not match, the 'dossier' (workitem) will arrive in the hands of the ceo, who will decide.

The workitem then goes back to unit1 for execution of the purchase.

<?xml version="1.0"?>

<process-definition
    name="it_approval"
    revision="0.02"
>

    <description>
IT approval budget
    </description>

    <sequence>

        <participant ref="unit1" />

        <concurrence
            sync="generic"
            merge="last"
            merge-type="mix"
        >
            <participant ref="cto" />
            <participant ref="cfo" />
        </concurrence>

        <if>
            <not>
                <equals field-value="cto_decision" other-field-value="cfo_decis
ion" />
            </not>
            <!-- then -->
            <participant ref="ceo" />
        </if>

        <participant ref="unit1" />

    </sequence>

</process-definition>

Change request tracking

An example with subprocesses.

The organizational model is very simple : each employee has a user (and a workitem store) in the workflow system.

All the participants in this example are referenced through field-ref. It means that the engine will find the participant names in the field of the workitem named after field-ref. It means that the fields 'developer', 'account_manager', 'configuration_manager',... have to be filled with the name of the employee in this role. This is usually done at launch time, but of course, the field value may be changed during the course of the flow instance, leading to the delivery of the workitem to someone else in further steps.

This example contains a loop : while the project manager has not approved the 'change_fix' the developer will have to re-do its job.

<?xml version="1.0"?>

<process-definition
    name="software_change_request"
    revision="0.02"
>

    <description>
A change request process
    </description>

    <!-- body -->

    <sequence>
        <subprocess ref="development-fix" />
        <subprocess ref="configuration-fix" />
        <subprocess ref="deployment" />
    </sequence>

    <!-- sub processes -->

    <process-definition name="development-fix">
        <loop>
            <sequence>
                <participant field-ref="developer" />
                <participant field-ref="project_manager" />
            </sequence>
            <until>
                <equals
                    field-value="project_manager_approved"
                    other-value="true"
                />
            </until>
        </loop>
    </process-definition>

    <process-definition name="configuration-fix">
        <sequence>
            <participant field-ref="configuration_manager" />
            <participant field-ref="project_manager" />
        </sequence>
    </process-definition>

    <process-definition name="deployment">
        <participant field-ref="account_manager" />
    </process-definition>

</process-definition>