In some scenarios it is necessary to assign a piece of work to a group of users, or to grant a particular privilege to a group of users. A well-known way to implement this behavior is to define appropriate groups in the staff repository and use appropriate people assignment criteria in the component which assigns tasks and authorizations to particular users.
The WPS offers 3 different people assignment criteria definitions which can be used to take advantage of groups predefined in the underlying staff repository. These verbs are:
Scenario : Here the group name 'sellers' which has 2 users 'SellerA' & 'SellerB'. In real time when this task is created the Potential Owners in the Details tab of the task would be SellerA ,SellerB.
The Group Search verb offers a more advanced version of group resolution. Besides specifying the group id of the group to be resolved, the user of this verb may use other attributes of the group instead, like Manager of the group, Geographic Location, Business Category, etc. In addition, this verb allows to use wildcard symbols in parameters. For example, by using the pattern us012* as group id, this verb will create a query which, at runtime, will concatenate the users of all groups where the group id starts with "us012". Like the Group Members verb described above, at runtime the Group Search verb triggers a lookup operation in the underlying staff repository and generates the explicit list of userids that are members of the specified group.
The Group people assignment criteria definition uses a different approach to realize group resolution. This verb takes advantage of the WebSphere mechanism performed during login: Whenever a user authenticates against WebSphere, for example, by entering userid and password in a login dialog, all groups are automatically determined of which the user is a member, and this information is associated safely with the actual session.
In this case Potential Owners in the Details tab of the task would be cn=sellers,o=defaultWIMFileBasedRealm.
In contrast to the two verbs described above, no access to the underlying staff repository is performed at runtime for the Group verb, and no explicit list of userids is generated at any time. This allows to specify huge groups containing a large number of users without performance impact.
The WPS offers 3 different people assignment criteria definitions which can be used to take advantage of groups predefined in the underlying staff repository. These verbs are:
- Group Members
- Group Search
- Group
Scenario : Here the group name 'sellers' which has 2 users 'SellerA' & 'SellerB'. In real time when this task is created the Potential Owners in the Details tab of the task would be SellerA ,SellerB.
The Group Search verb offers a more advanced version of group resolution. Besides specifying the group id of the group to be resolved, the user of this verb may use other attributes of the group instead, like Manager of the group, Geographic Location, Business Category, etc. In addition, this verb allows to use wildcard symbols in parameters. For example, by using the pattern us012* as group id, this verb will create a query which, at runtime, will concatenate the users of all groups where the group id starts with "us012". Like the Group Members verb described above, at runtime the Group Search verb triggers a lookup operation in the underlying staff repository and generates the explicit list of userids that are members of the specified group.
The Group people assignment criteria definition uses a different approach to realize group resolution. This verb takes advantage of the WebSphere mechanism performed during login: Whenever a user authenticates against WebSphere, for example, by entering userid and password in a login dialog, all groups are automatically determined of which the user is a member, and this information is associated safely with the actual session.
In this case Potential Owners in the Details tab of the task would be cn=sellers,o=defaultWIMFileBasedRealm.
In contrast to the two verbs described above, no access to the underlying staff repository is performed at runtime for the Group verb, and no explicit list of userids is generated at any time. This allows to specify huge groups containing a large number of users without performance impact.
No comments:
Post a Comment