processi

about processes and engines

Search Results

listen

I’ve been playing with that idea for a while. Participants in business processes are just channels, workitems are just messages.

OpenWFEru 0.9.11 will add a new ‘listen’ expression, for listening to those channels (instead of simply emitting messages to them).

listening to participant "alpha"

Listening to participant ‘alpha’, notifying participants ‘bravo’ and ‘charly’ with a copy of the next workitem dispatched to ‘alpha’.

Switching to a Ruby process definition, it feels lighter…

listening to participant "alpha" (specific customer)

This time, participants bravo and charly are interested by a copy of the next workitem coming back from participant alpha concerning customer “Acme”.

The scope of this listen expression is not limited to a single process instance, it thus opens up easy (looser ?) correlation points among process instances. Possibilities are for another blog post.

It should have been part of OpenWFE[ru] sooner, but I never could make up my mind on how to do it right (a little bit).

There are more options, they are documented in the expressions documentation page.

Written by John Mettraux

May 29, 2007 at 10:37 am

Posted in bpm, openwfe, openwferu, workflow

syndicating workitems

I’ve just added a few lines of code to OpenWFE. They leverage Rome to create workitem feeds.

A few posts ago I wrote : “workitems are messages, participants are channels” to map OpenWFE to process calculus (especially pi-calculus).

I’ve also shown in ‘when and more’ that the <when>, <save> and <restore> expressions could be used to implement a channel/message system inside of an OpenWFE process engine.

Now, with the inclusion of syndicated dispatchers into OpenWFE, the idea of participants as channels takes its full meaning. External participants may subscribe to an engine feed. The model is simple, lots of libraries are available to parse those feeds, it’s just around, ready to get piggy-backed.

I currently see two kinds of clients to those engine feeds : engines and applications.
Engines as clients, to fully implement the process calculus concept : incoming messages (workitems) trigger processes.
Applications, until now, only consumed workitems upon push, now integrators have an opportunity to pull workitems within their applications.

Feed notification will become a serious alternative to email notification.

Dispatching of workitems per feed will be part of the upcoming OpenWFE 1.7.2 release.

(I’ll have to blog about practical examples of this technique, this first post is a bit shallow but I’m sure part of my audience will fully grasp the idea)

Written by John Mettraux

August 13, 2006 at 9:13 pm

Posted in bpm, openwfe, workflow

when and more

There’s an expression in OpenWFE that’s not much known but that yields some power, it’s the <when> expression.

It’s been used to implement some of the workflow patterns, especially those requiring a strong touch of process calculus.

I had forgotten in the documentation to mention the ‘whenFrequency’ parameter of the expression pool, which sets how frequently the engine (well, its expression pool service) checks for the validity of a when expression. This lack of documentation got fixed.

So why bringing ‘process calculus’ on the table ? <when> can be used to receive messages whereas <set> is used to send them.

<process-definition name="flow1" revision="0.1">
    <sequence>
        <set variable="//channel_z" value="the message" />
    </sequence>
</process-definition>

<process-definition name="flow2" revision="0.1">
    <when>
        <defined variable-value="//channel_z" />
        <sequence>
            <set field="message" variable-value="//channel_z" />
            <participant ref="someone" />
        </sequence>
    </when>
</process-definition>

In this small example, a process ‘flow1’ sends a message to process ‘flow2’ via a variable set at the engine level (hence the ‘//’ in front of its name).

Well, passing only a String message is constraining. By using the <save> expression, you could pass a whole workitem as the message :

<process-definition name="flow1" revision="0.2">
    <sequence>
        <save to-variable="//channel_z" />
    </sequence>
</process-definition>

<process-definition name="flow2" revision="0.2">
    <when>
        <defined variable-value="//channel_z" />
        <sequence>
            <restore from-variable="//channel_z" />
            <participant ref="someone" />
        </sequence>
    </when>
</process-definition>

The workitem sent to participant ‘someone’ will be a copy of the workitem saved by ‘flow1’.

This ‘via variable’ channel mechanism is limited to an engine. A new mechanism is currently in inception that will bring cross-engine channels.

Written by John Mettraux

August 6, 2006 at 11:43 am

Posted in openwfe, workflow