About the staff service

With Business Process Choreographer you can separate the logic of your business processes and human tasks from the staff resolution. Staff queries are resolved using a plug-in that is specific to the directory service. Some examples of using the staff service are described here:

For detailed information on the staff resolution plug-ins, refer to the Process Choreographer: Staff Resolution Architecture, the Process Choreographer: Programming Model for Staff Resolution, and the Process Choreographer: Staff Resolution Parameter Reference White papers in WebSphere Business Process Choreographer

Staff queries using the staff support service

You can use WebSphere Integration Developer to define staff queries for the staff support service. Staff queries are templates that define how to retrieve the list of users authorized for a certain work item. You can use the abstract query templates (staff verbs) when you model business processes and human tasks. These staff verbs are transformed during deployment into a set of queries that can be run on a staff repository.

Before the staff query verbs in the process editor and the parameterized verbs in the process models can be run as queries on a specific staff repository, they must be translated into executable queries using an XSL transformation. The result of a transformation (mapping) can be run by staff resolution plug-ins that provide access to specific directories, such as Lightweight Directory Access Protocol (LDAP) or the user registry. At run time, the plug-in runs the query by invoking the staff repository APIs and by creating the list of authorized user IDs for the corresponding work item.

During process or task deployment, the staff support service is invoked to deploy the staff query. The staff service retrieves the staff plug-in provider configuration with the corresponding Java Naming and Directory Interface (JNDI) name. The JNDI name is set in WebSphere Integration Developer, the default is the user registry. The staff support service then converts the parameterized staff query verb into a query run by a specific staff resolution plug-in defined in the configuration for the Extensible Stylesheet Language transformation (XSLT) verb mapping file and the staff resolution plug-in. All of the staff query verbs belonging to a process template must use the same provider configuration.

The following example illustrates a snippet as generated by the process editor to retrieve the manager of the employee that started the process:
  <verb>
    <id>Manager of Employee by user ID</id>
    <name>Manager of Employee by user ID</name>
    <parameter id="EmployeeUserID">
      %wf:process.starter%
    </parameter>
  </verb>

Staff query verb set

The staff support service accepts queries in an abstract form that is independent of the directory infrastructure used. Both the process editor and the task editor have a set of predefined staff query verbs that can be used when you model processes and tasks. These verbs are contained in the VerbSet.xml file. This file is installed with WebSphere Integration Developer.

The individual staff resolution plug-ins and the XSLT mapping files do not support all of the verbs. The Manager of Employee verb, for example, is not available if you use the user registry or the system plug-in. You can modify the set of staff query verbs. Make your changes to a copy of the file. Ensure that the copied file has a different file name.

The following predefined set of verbs is available. For information on the parameters that you can use with each of the verbs, see Predefined staff verbs and their parameters.

Department Members
Use this verb to define a query to retrieve the members of a department. The retrieved users belong to any of the specified departments (DepartmentName, AlternativeDepartmentName1, or AlternativeDepartmentName2). This verb is supported by the LDAP plug-in.
Everybody
Use this verb to assign a work item to every user authenticated by the WebSphere Process Server. This verb is supported by the system, user registry, and LDAP plug-ins.
Group Members
Use this verb to define a query to retrieve the members of up to three groups. The retrieved users belong to any of the specified groups (GroupName, AlternativeGroupName1, or AlternativeGroupName2). This verb is supported by the user registry and LDAP plug-ins.
Group Members without Named Users
Use this verb to define a query to retrieve the members of a group except for explicitly named users of that group. One or more members can be specified for exclusion as a comma separated list. This verb is supported by the user registry and LDAP plug-ins. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.
Group Members without Filtered Users
Use this verb to define a query to retrieve the members of a group except for a set of users defined by an LDAP search filter. This verb is supported by the LDAP plug-in. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.
Group Search
Use this verb to search for a group based on an attribute match and to retrieve the members of the group. This verb is supported by the user registry and LDAP plug-ins.
Manager of Employee
Use this verb to retrieve the manager of a person using the person's name. This verb is supported by the LDAP plug-in. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.
Manager of Employee by user ID
Use this verb to retrieve the manager of a person using the person's user ID. This verb is useful in combination with context queries. This verb is supported by the LDAP plug-in. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.
Native Query
Use this verb to define a native query based on directory-specific parameters. This verb is supported by the user registry and LDAP plug-ins. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.
Nobody
Use this verb to deny normal users access to the work item; For inline tasks, only the business process administrator and business process system administrator have access. For standalone tasks, only the human task administrator and human task system administrator have access. This verb is supported by the system, user registry, and LDAP plug-ins.
Person Search
Use this verb to search for a person based on an attribute match. This verb is supported by the user registry and LDAP plug-ins. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.
Role Members
Use this verb to retrieve the users associated with a business process role. The retrieved users belong to any of the specified roles (RoleName, AlternativeRoleName1, or AlternativeRoleName2). This verb is supported by the LDAP plug-in. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.
Users
Use this verb to define a staff query for a user who is known by name. It is not recommended that you hard code user names in process templates. This verb is useful for testing processes. This verb is supported by the system, user registry, and LDAP plug-ins. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.
Users by user ID
Use this verb to define a staff query for a user whose user ID is known. Even though it is not recommended that you hard code user IDs in process templates, this verb is useful in combination with context queries, for example:
User [username='%wf:process.starter%']
This verb is useful for testing processes. This verb is supported by the system, user registry, and LDAP plug-ins. You might need to customize the default mapping XSLT file to match the LDAP schema of your organization.

E-mail verb set

Use the e-mail verb set in WebSphere Integration Developer is used for e-mail notifications for task escalations. These e-mail verbs are transformed during modeling and deployment into a set of queries that can be run on a staff repository. E-mail verbs are defined for the most common staff verbs supported by the LDAP plug-in. The following e-mail verbs are available:

For the other LDAP staff verbs, the user identifiers retrieved by the staff verbs are used as input to the Email Address for Users by User ID verb.

Before the e-mail verbs can be run as queries on a specific staff repository, they must be translated into executable queries using an XSL transformation. The result of a transformation (mapping) can be run by the LDAP staff resolution plug-in. At run time, the query returns a set of e-mail addresses, for example, user1@mycomp.com, user2@mycomp.com, and so on.

Explicit staff assignments using the system staff plug-in

The system staff plug-in does not require any configuration parameters; it is preinstalled and ready for use. Using this plug-in, you can hard code user names in your business process. This practice is not normally recommended, but it can be useful for testing if you are using context variables or special queries, as illustrated by the following examples:
<sur:staffQueries>
    <staff:userID name="%wf:process.starter%">
    <staff:userID name="%wf:process.administrators%">
</sur:staffQueries>
<sur:staffQueries>
    <staff:everybody>
</sur:staffQueries>
<sur:staffQueries>
    <staff:nobody>
</sur:staffQueries>

The following XML snippet explicitly retrieves the WebSphere user ID smith:

<staff:staffQueries>
    <staff:userID name="smith">
</staff:staffQueries>

Staff queries transformed for the user registry staff plug-in

Using this plug-in, staff queries can refer to users and groups that are known to the WebSphere Process Server user registry. This plug-in does not require any configuration parameters, comes preinstalled and is ready for use.

The following XML snippet retrieves the user IDs of all the members of the Administrators group:

<sur:staffQueries>
    <sur:usersOfGroup groupName="Administrators"/>
</sur:staffQueries>

This XML snippet is an example of the transformation output.

Staff queries transformed for the LDAP staff plug-in

If you want to use the LDAP plug-in, you probably need to create a customized version of the LDAP XSL transformation to match the LDAP schema of your organization. The standard XSLT provided for LDAP is located:

Make your changes to a copy that has a different file name. When you have made your changes:

  1. Configure a staff plug-in provider that points to the new transformation file.
  2. Ensure that when you deploy the EAR file, you use the JNDI name of the new staff plug-in provider.
The following XML snippet illustrates the results of the LDAP transformation for a search:
<sldap:staffQueries>
  <sldap:search baseDN="ou=mydivision, o=mycompany, c=us" filter="cn=*"
               searchScope="onelevelScope" recursive="no"> 
     <sldap:attribute name="uid" objectclass="person" usage="simple"/>
  </sldap:search>
</sldap:staffQueries>

Terms of use | | Broken links

Last updated: Mon Mar 27 18:01:21 2006

(c) Copyright IBM Corporation 2005.
This information center is powered by Eclipse technology (http://www.eclipse.org)