processi

about processes and engines

ParticipantGetStrategy

OpenWFE has 3 main components : engine, worklist and apre (Automatic Participant Runtime Environment).

The worklist features workitem stores and each of these stores has a ‘GetStrategy’ implementation dictating which workitem it should hand back when requested.

There is no ‘user’ concept in the process definitions, only ‘participants’. The engine and the worklist (and other components) share a ‘participant map’ which tells them how and where to dispatch workitem back and forth to participants. One interesting thing to note is that OpenWFE components are participants. With the engine as a participant (thus registered in the participant map), it’s easy for the worklist to lookup the engine’s name to know how to get workitem back to it.

I just implemented a ParticipantGetStrategy (upon Sebastian’s request). This is useful for configuration where participant names are mapped 1:1 with user names. This GetStrategy implementation simply takes care of returning matching workitems (the engine sets a field ‘participantName’ in outgoing workitems).

You could thus have one big store where all your workitems [for human participant] go and have them automatically filtered per username.

A bit of a dry post maybe…

Written by John Mettraux

March 3, 2006 at 3:15 pm

Posted in bpm, coding, openwfe, workflow

2 Responses

Subscribe to comments with RSS.

  1. […] This post complements that one on ParticipantGetStrategy. […]

  2. […] The OpenWFE worklist relies on two main concepts : workitem stores and users. Users are granted access rights to each store. By default a read access right allows to read any workitem in a given store. But you can swap the strategy a store uses to filter workitems presented to each users. I already blogged about the UserGetStrategy and the ParticipantGetStrategy. […]


Comments are closed.

%d bloggers like this: