Use the following information to help solve problems relating to
staff assignments of people to authorization roles.
- 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:
- Create a new staff plug-in provider configuration, providing your own
version of the XSL file
- 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 processesRoles 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 escalationsRoles 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 escalationsRoles 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:
- Check that WebSphere security is enabled. In the administrative console,
go to and make sure the Enable global security check
box is selected.
- Check that the user registry is configured. In the administrative console,
go to and check the Active user registry attribute.
- 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.