about processes and engines

wrapping a timeout behaviour

I often have questions like that one.

I replied to it with a quick rtfm… Well I was courteous and played kindly my role of search engine and posted the link to the documentation about participants and timeout.

If you have to wrap a timeout behaviour for a participant you could write a subprocess like that one :

    <tparticipant tref="Alice" timeout="3d12h" />
    <tparticipant tref="Bob" timeout="1d" />

<subprocess name="tparticipant">
        <participant ref="${tref}" timeout="${timeout}" />
        <if test="${f:__timed_out__}">
            <email-notification />

<subprocess name="email-notification">

In this example, a subprocess named “tparticipant” is used to wrap a standard behaviour for our process. Upon timeout, an email notification (the details of that subprocess are left). Each time a timeout occurs, the field “__timed_out__” is set to ‘true’ in the workitem, that’s what we use to determine if email notification is required.

Alice has 3 days and twelve hours to complete her task before it times out and an email notification is sent. Bob has only one day.

By using a subprocess we make the core flow lighter and more easily readable.

Written by John Mettraux

December 20, 2006 at 4:58 am

Posted in bpm, openwfe, workflow

4 Responses

Subscribe to comments with RSS.

  1. It would be nice to define a business layer concept to actually hide the trick done to achieve the same effect as subprocess calling on timeout.
    What do you think ?


    December 21, 2006 at 1:01 am

  2. Hi Niko,

    I don’t understand your idea of “business layer concept”. You’d like to have an expression wrapping that behaviour ?

    adding subprocesses is adding abstraction layers. Everyone’s business is slightly different than others’ business [layer].

    In OpenWFE, you can define processes at the engine level or within ‘external’ process definition files. It’s easy then to share those subprocesses among multiple core / top level processes.

    OpenWFE tries to provide a set of basic expressions and ways to build more powerful abstractions on top of them. We cannot go all the way, the final specialization is left to integrators.

    Best regards,


    John Mettraux

    December 21, 2006 at 1:26 am

  3. My thought was not very clear, sorry.

    Maybe it’d be nice to be able to access those “samples” subprocesses easily.
    Seems to me that the timeout participant, could be used, and contributed by other people and then being re-used.
    This would eventually create a set of sub-process definitions accessible and ready to use and thus, first, simplify the work for integrator (through reuse) and, second, extend the usage of OpenWfe through easier adoption.

    Again, I may be wrong, those are just suggestions.


    December 21, 2006 at 2:13 am

  4. If I had time, I’d love to start something like, where sample processes would be available online… Maybe I should really take that time…

    I have to say that I haven’t yet received any two similar requests about timeout behaviours, it’s rather like “ah, this is cool, may I have exactly the same but in pink with snow tires ?” (look at the thread mentioned in the blog post), so I haven’t formalized anything about timeouts.

    If you take a closer look at OpenWFE’s history (5 years), you’ll see that we have tried hard to come up with common solutions to common problems. Be assured that your ideas will be taken into account.

    Best regards,


    John Mettraux

    December 21, 2006 at 2:22 am

Comments are closed.

%d bloggers like this: