Troubleshooting the staff service, staff plug-ins, and staff resolution

Use the following information to help solve problems relating to staff assignments of people to authorization roles.

Why and when to perform this task

Topics covered are:

You can also search for additional information in the Technical support search page.

Errors during staff verb deployment
If you are using the LDAP staff plug-in, deployment might fail due to incorrect values of the plug-in configuration parameters. Make sure that all mandatory parameters are set. To set the BaseDN parameter to the root of the LDAP directory tree, specify an empty string; set the BaseDN parameter to two apostrophe (') characters ("). Do not use double quotation marks ("). Failure to set the BaseDN parameter results in a NullPointerException exception at deployment time.
Entries in the staff repository are not reflected in work item assignments
The maximum number of user IDs retrieved by a staff query is specified by the Threshold variable, which is defined in the XSL transformation file in use. The XSL transformation file used for the LDAP staff plug-in is, for example, LDAPTransformation.xsl, which is located in install-root/ProcessChoreographer/Staff on Linux and UNIX platforms and in install-root\ProcessChoreographer\Staff on Windows platforms. The default Threshold value is 20. To change this value:
  1. Create a new staff plug-in provider configuration, providing your own version of the XSL file
  2. Adapt the following entry in the XSL file according to your needs:
     <xsl:variable name="Threshold">20</xsl:variable>
Note: If you specify a large Threshold value, it might result in a decrease in performance. For this reason, do not specify a value greater than 100.
Unexpected staff assignments for tasks or process instances
Default staff assignments are performed if you do not define staff verbs for certain roles for your tasks, or if staff resolution fails or returns no result. These defaults might result in unexpected user authorization; for example, a process starter receives process administrator rights. In addition, many authorizations are inherited by dependent artifacts. For example, the process administrator may also become the administrator of all inline tasks.

The following tables illustrate which defaults apply for which situation:

Table 1. Roles for business processes
Roles for business processes If the role is not defined in the process model ... If the role is defined in the process model, but staff resolution fails or does not return proper results ...
Process administrator Process starter becomes process administrator The following exception occurs and the process is not started:

EngineAdministratorCannotBeResolvedException

Process reader No reader No reader
Table 2. Roles for inline human tasks and their escalations
Roles for inline human tasks and their escalations If the role is not defined in the task model ... If the role is defined in the task model, but staff resolution fails or does not return proper results ...
Task administrator Only inheritance applies Only inheritance applies
Task potential instance creator Everybody becomes potential instance creator Everybody becomes potential instance creator
Task potential starter Everybody becomes potential starter Everybody becomes potential starter
Task potential owner Everybody becomes potential owner Administrators become potential owners
Task editor No editor No editor
Task reader Only inheritance applies Only inheritance applies
Escalation receiver Administrators become escalation receivers Administrators become escalation receivers
The following inheritance rules apply for inline tasks:
  • Process administrators become administrators for all inline tasks, their subtasks, follow-on tasks, and escalations.
  • Process readers become readers for all inline tasks, their subtasks, follow-on tasks, and escalations.
  • Task administrators become administrators for all subtasks, follow-on tasks, and escalations of all these tasks.
  • Task readers become readers for all subtasks, follow-on tasks, and escalations of all these tasks.
  • Members of any task role become readers for this task's escalations, subtasks, and follow-on tasks
  • Escalation receivers become readers for the escalated task.
Table 3. Roles for stand-alone human tasks and their escalations
Roles for stand-alone human tasks and their escalations If the role is not defined in the task model ... If the role is defined in task model, but staff resolution fails or does not return correct results ...
Task administrator Originator becomes administrator The exception AdministratorCannotBeResolvedException is thrown and the task is not started
Task potential instance creator Everybody becomes potential instance creator Everybody becomes potential instance creator
Task potential starter Originator becomes potential starter The exception CannotCreateWorkItemException is thrown and the task is not started
Potential owner Everybody becomes potential owner Administrators become potential owners
Editor No editor No editor
Reader Only inheritance applies Only inheritance applies
Escalation receiver Administrators become escalation receivers Administrators become escalation receivers

The following inheritance rules apply for stand-alone tasks:

  • Task administrators become administrators for all subtasks, follow-on tasks, and escalations of all these tasks.
  • Task readers become readers for all subtasks, follow-on tasks, and escalations of all these tasks.
  • Members of any task role become readers for this task's escalations, subtasks, and follow-on tasks
  • Escalation receivers become readers for the escalated task.
Note: When a method is invoked via the Business Flow Manager API, members of the J2EE role BPESystemAdministrator have administrator authorization, and members of the J2EE role BPESystemMonitor have reader authorization.
Note: When a method is invoked via the Human Task Manager API, members of the J2EE role TaskSystemAdministrator have administrator authorization, and members of the J2EE role TaskSystemMonitor have reader authorization.
Stopped staff activities
If you encounter one or more of the following problems:
  • Human tasks cannot be claimed, even though the business process started navigating successfully.
  • The SystemOut.log file contains the following message: CWWB0057I: Activity 'MyStaffActivity' of processes 'MyProcess' has been stopped because of an unhandled failure...

This message indicates that WebSphere Application Server security might not be enabled. Human tasks and processes that use people authorization require that security is enabled and the user registry is configured. Take the following steps:

  1. Check that WebSphere security is enabled. In the administrative console, go to Security > Global Security and make sure the Enable global security check box is selected.
  2. Check that the user registry is configured. In the administrative console, go to Security > User Registries and check the Active user registry attribute.
  3. Restart the activity, if stopped.
Changes to the staff repository are not immediately reflected in work-item assignments

Business Process Choreographer caches the results of staff assignments evaluated against a staff directory, such as a Lightweight Directory Access Protocol (LDAP) server, in the runtime database. When changes occur in the staff directory, these are not immediately reflected in the database cache.

The Administration guide describes three ways to refresh this cache:

  • Refreshing staff query results, using the Administrative Console. Use this method if you have major changes and need to refresh the results for almost all staff queries.
  • Refreshing staff query results, using administrative commands. Use this method if you write administration scripts using the wsadmin tool, or if you want to immediately refresh only a subset of the staff query results.
  • Refreshing staff query results, using the refresh daemon. Use this method to set up a regular and automatic refresh of all expired staff query results.
Note: None of these methods can refresh the group membership association of a user for the Group verb. This group membership is cached in the user's login session (WebSphere security LTPA token), which by default expires after two hours. Also note that the group membership list of the process starter ID that is used for process navigation, is never refreshed.
Error and warning messages relating to staff resolution
Some common errors can occur when accessing a staff repository during staff resolution. To see details for these errors, you can enable tracing with the following trace settings: com.ibm.bpe.*=all: com.ibm.task.*=all:com.ibm.ws.staffsupport.ws.*=all

The following common error situations are indicated by warning or error messages:

  • Could not connect to LDAP server in the trace.log file indicates failure to connect to the LDAP server. Check your network settings, the configuration (especially the provider URL) for the staff plug-in provider you use, and verify whether your LDAP server requires an SSL connection.
  • javax.xml.transform.TransformerException: org.xml.sax.SAXParseException: Element type "xsl:template" must be followed by either attribute specifications, ">" or "/>" in the System.out or System.err files indicates that the LDAPTransformation.xsl file cannot be read. Check your staff plug-in provider configuration and the configured XSLT file for errors.
  • LDAP object not found. dn: uid=unknown,cn=users,dc=ibm,dc=com [LDAP: error code 32 - No Such Object] in the trace.log file indicates that an LDAP entry cannot be found. Check the task model's staff verb parameters and the LDAP directory content for mismatches in the task model.
  • Requested attribute "uid" not found in: uid=test222,cn=users,dc=ibm,dc=com in the trace.log file indicates that an attribute cannot be found in the queried LDAP object. Check the task model's staff verb parameters and the LDAP directory content for mismatches in the task model. Also check the XSLT file of your staff provider configuration for errors.
Issues with group work items and the "Group" verb
When using the Group verb, some special situations can occur:
  • Group members are not authorized, although the group name is specified:
    • Specify the group short name when using the Local OS registry for WebSphere security, and the group dn when using the LDAP registry.
    • Make sure that you respect the case sensitivity of the group name.

    One possible reason for this situation is that you have configured the LDAP user registry for WebSphere security and selected the Ignore case for authorization option. If so, either deselect the option, or specify LDAP group dn in all uppercase.

  • Changes in group membership are not immediately reflected in authorization. This might happen, when the affected user is still logged on. The group membership of a user is cached in her login session, and (by default) expires after two hours. You can either wait for the login session to expire (default is two hours), or restart the application server. The refresh methods offered by Human Task Manager do not apply for this verb. Note that the group membership list of the process starter is never refreshed.

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