Worklist stores and their 'GetStrategy'

A worklist is composed of one or more stores. Two strategies are attributed to eache store, one invoked upon incoming workitems (PutStrategy) and one invoked when a worklist user browses the store (GetStrategy). This is done within the etc/worklist/worklist-configuration.xml, for example :


    <service
        name="Store.alpha"
        class="openwfe.org.worklist.impl.store.SimpleWorkItemStore"
    >
        <param>
            <param-name>participants</param-name>
            <param-value>role-alpha, notif-alpha</param-value>
        </param>
        <param>
            <param-name>putStrategyClass</param-name>
            <param-value>openwfe.org.worklist.impl.store.DefaultPutStrategy</param-value>
        </param>
        <param>
            <param-name>getStrategyClass</param-name>
            <param-value>openwfe.org.worklist.impl.store.UserGetStrategy</param-value>
        </param>
    </service>

In that XML configuration snippet, the Store alpha has a 'DefaultPutStrategy' and a 'UserGetStrategy'.

The 'DefaultGetStrategy'

This is the strategy attributed by default to stores (i.e. when the parameter 'getStrategyClass' is not set). It simply returns every workitem (header within the store).

The 'UserGetStrategy'

The UserGetStrategy returns workitems whose field '__username__' contains as value the name of the requesting user.

By passing a parameter named 'usernameField', one can tell a UserGetStrategy to look for the name of the user in another workitem field. This strategy also has a 'adminUsernames' parameter which can contain a list of usernames separated by commas. Those user are considered as admins of the store and may see all the workitems.


    <service
        name="Store.alpha"
        class="openwfe.org.worklist.impl.store.SimpleWorkItemStore"
    >
        <param>
            <param-name>participants</param-name>
            <param-value>role-alpha, role-bravo</param-value>
        </param>
        <param>
            <param-name>getStrategyClass</param-name>
            <param-value>openwfe.org.worklist.impl.store.UserGetStrategy</param-value>
        </param>
        <param>
            <param-name>usernameField</param-name>
            <param-value>__user</param-value>
        </param>
        <param>
            <param-name>adminUsernames</param-name>
            <param-value>Toto, Edgard</param-value>
        </param>
    </service>

This workitem store will accept workitems for the participants 'role-alpha' and 'role-bravo'. It will return workitem whose field '__user' value will be equal to the requesting user's name. Users Toto and Edgard will see all the workitems.

If the parameter 'ignoreCase' is set to true,


        <param>
            <param-name>ignoreCase</param-name>
            <param-value>true</param-value>
        </param>

comparison of usernames will be performed without respecting the case. Thus, 'user-TEST' will match 'user-test' and vice versa.

The 'ParticipantGetStrategy'

When this strategy is attached to a workitem store, a worklist user, when requesting the headers for the workitems in that store, will only see those that were delivered for a participant whose name is equal to his [username]. This strategy may prove very useful if the organization directly uses worklist usernames for its human participants.

The ParticipantGetStrategy understands the same parameters 'ignoreCase' and 'adminUsernames' that were explained in the 'UserGetStrategy' documentation.

Using the strategy in conjunction with a 'regex user'

Since OpenWFE 1.7.1, having users with regular expressions as names in passwd.xml is possible.


    <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>

In this snippet of passwd.xml, every user whose name starts with "user-" is allowed in the system with the shared password "user". They all get access to the store "store.u" and have to opportunity to launch the flows listed in the grant "launch.more" (grant definitions haven't been included here).

The idea is to have all the workitems for participant whose name begins with "user-" dispatched to our "Store.u"


    <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>

It's then easy to state that store "store.u" should use a ParticipantGetStrategy :


    <service
        name="Store.u"
        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>
    </service>

All the workitems for "user-" participants will be delivered into the "Store.u" store. The ParticipantGetStrategy makes sure that a user may only see workitems whose participant name are equal to his username.

This technique brings lots of flexibility, instead of having 1 'system user', 1 'generic user' could be configured. No need to create a profile for each user. New participant - user 'pairs' can be added to process definitions without further configuration.


<process-definition name="demo" revision="x">
    <sequence>
        <participant ref="user-alfred" />
        <participant ref="user-bernard" />
        <participant ref="user-carrie" />
    </sequence>
</process-definition>

There's no limitation, the technique may also apply with other prefixes than "user-". This example prefix was used in order to show this loose link thus established between participants and users.

Prev	Up	Next
OpenWFE as a service	Home	Logging