Workflow problems
This section describes problems with workflow processes.
Activities might be delayed when submitted in a batch through Identity Service Center
The Identity Service Center workflows process requests serially. After submitting a batch request, a particular request might not be displayed because it must wait until another request in the batch is completed. For example, a high priority role request might be delayed by a low priority account or group approval. This condition is a known limitation.
Create nine or more service instances for a password policy causes an error condition
An error occurs after nine or more service instances are associated with a password policy. Tune the DB2 stmtheap attribute for the maximum number of service instances. This table provides guidelines:Change the statement heap size with the DB2 update command.
Maximum service instances Statement heap size attribute value 12 4096 17 8192 24 16384
- Set db2instance to one of these instances:
- db2admin
- IBM Security Directory Server instance
- Run db2 from a command line to start the DB2 command-line interface.
- Run an update command and specify the appropriate value as the size variable:
update db cfg for db_name using STMTHEAP size- Stop and start IBM Security Directory Server.
Requests timeout before reaching the escalation period
One or more pending requests timeout before completion. The timeout stamp indicates that the escalation period was not reached. Modify the LIMIT values for requests in the IBM Security Directory Server operation objects. Specify a value of -1 to set the operation to unlimited.
- Set the LIMIT value for operation objects corresponding to operations, such as adding an account
- Ensure that the user ID for connecting to the directory server has the necessary permissions to modify LDAP entries.
- Using an LDAP client, connect to the directory server with ISIM data.
- Browse to the appropriate operation definition. The operation definitions are located under this Distinguished Name:
DN:ou=operations,ou=itim,tenant,root suffixExample: The tenant is ou=org. The root suffix is dc=com. The operations are in ou=operations,ou=itim,ou=org,dc=com.- Edit and set LIMIT to the appropriate value in the tag of the erXml attribute of the process definition entry. For example:
- To set the timeout of the account add operation to four days, edit the erXml attribute on erglobalid=00000000000000000022,ou=operations,ou=itim, ou=tenant,root suffix.
- Change LIMIT="43200000" to LIMIT="345600000" in the <PROCESSDEFINITION...> tag.
- To set LIMIT to unlimited, specify LIMIT="-1".
- Set the LIMIT value for operation objects for workflows
- Browse to the appropriate workflow definition. All the operation definitions for workflows are under this DN:
DN:ou=workflow, erglobalid=00000000000000000000, tenant,root suffixExample: The tenant is ou=org. The root suffix is dc=com. The workflow definitions are in:DN:ou=workflow,erglobalid=00000000000000000000,ou=org,dc=com- Select the workflow entry under the Distinguished Name to change.
- Set the LIMIT value for changing the LIMIT value for operations. See Set the LIMIT value for operation objects corresponding to operations, such as adding an account.
Create or modifying a workflow design, a form, or a policy takes longer than the timeout interval
Create or modifying a workflow design, a form, or a policy might take longer than the session timeout interval. To avoid interruption, the timeout value in the web.xml file is ignored. The session never times out while the Workflow Designer, Form Designer, or Policy applet is running.
Ensure that you complete each activity to create or modify a workflow design, a form, or a policy.
A workflow UNTIL loop behaves like a DO...WHILE loop
A workflow UNTIL loop behaves like a DO...WHILE loop. Instead of ending when a specified loop condition is met, the loop continues until a specified condition fails. We must restate the condition as the negative of the specified loop condition. For example, this condition requires restating as follows:
- a<b
- Needs to be restated as:
- a>=b
Approval workflow not initiating
You defined an access with an approval workflow for a group. The workflow is not initiated when we add members to the group with the group management function.
Therefore, it is possible for unauthorized users to gain access to groups.
Workflow or operation cannot be created or updated
We created or updated a workflow or operation, but the changes did not take effect. The administration console indicates a successful operation, but the changes were not saved when the workflow designer exited. This problem occurs only when we are running the administration console on localhost. For example.
http://localhost:9080/isim/consoleWhen the problem occurs, check to see whether this exception is shown in the Java™ console window.
java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:9080 connect,resolve)If we do not see the Java console window on your desktop when the browser loads the workflow designer applet, configure it from the Java control panel.Workaround.
Select one of these workarounds.
- Do not use localhost. Instead, use the actual IP address or the host name to access the console. When we use an IP address or host name, the problem does not occur. For example:
http://testserver.subnet.example.com:9080/isim/console http://1.1.1.1:9080/isim/console- Modify a policy file to enable localhost. We can successfully use localhost by specifying a grant statement in a .java.policy file in your home directory. If we do not have an existing .java.policy file, create a text file. Add this statement:
grant { permission java.net.SocketPermission "127.0.0.1:9080", "connect,resolve"; };We must restart your browser after we create or modify the .java.policy file.Parent topic: Troubleshooting ISIM Server problems