a variation on users and participants
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.
The technique displayed in this blog post uses a new feature requested (and heavily tested) by Sebastian (thanks). This feature permits the usage of regular expressions instead of plain usernames in passwd.xml :
<principal name="user-.*" class="openwfe.org.auth.BasicPrincipal" password="-18+17-53-79-112+82-28+11+7-86-64-54+6+12+35-18" > <grant name="store.u" /> <grant name="launch.more" /> </principal>
With this configuration, any user named ‘user-toto’ or ‘user-whatever’. This ‘set’ of users all share the same password (in this example, it’s “user”).
The initial advantage is reduced administration burden. You might reply that having one system user was already minimizing the administration burden, but this ‘generic user’ feature is a variation on that ‘system user’ theme. New participant names may appear in process definitions without any configuration modification.
Read further to see how it could get leveraged along with the ParticipantGetStrategy.
We have to make sure that any workitem for a participant whose name begins with “user-” gets dispatched to our classical worklist (by tweaking participant-map.xml) :
<participant name="user-.*"> <param> <param-name>dispatcherClass</param-name> <param-value>openwfe.org.engine.impl.dispatch.SocketDispatcher</param-value> </param> <param> <param-name>host</param-name> <param-value>127.0.0.1</param-value> </param> <param> <param-name>port</param-name> <param-value>7008</param-value> </param> <param> <param-name>workItemCoder</param-name> <param-value>xmlCoder</param-value> </param> </participant>
Next, (as could be found in etc/worklist/worklist-configuration.xml), we define a store named “Store.users” which ‘collects’ the workitem for participants whose name starts with “user-” :
<service name="Store.users" class="openwfe.org.worklist.impl.store.SimpleWorkItemStore" > <param> <param-name>participants</param-name> <param-value>user-.*</param-value> </param> <param> <param-name>getStrategyClass</param-name> <param-value>openwfe.org.worklist.impl.store.ParticipantGetStrategy</param-value> </param> <param> <param-name>adminUsernames</param-name> <param-value>admin-.*, user-admin</param-value> </param> </service>
Note the parameter ‘adminUsernames’, the matching users see all the workitems in Store.users, no filtering for those “admins”.
A typical flow would look like :
<process-definition name="demo" revision="0.1"> <sequence> <participant ref="user-alfred" /> <participant ref="user-bernard" /> <participant ref="user-corwen" /> </sequence> </process-definition>
Finally : no need to add users to the system, any username starting with user- is valid and there’s a corresponding participant name. The ParticipantGetStrategy is here to make sure that “user-toto” only sees workitem dispatched for the participant “user-toto”.
It’s simple and very effective (but may seem non-intuitive to some of OpenWFE ‘consumers’, who won’t understand the “one password for a set of users” thing)
This technique is documented in the OpenWFE manual.