Workflow problems

This section describes problems with workflow processes.

Activities might be delayed when submitted in a batch through Identity Manager Service Center

The Identity Manager Service Center workflows process requests serially. After you submit 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.

Creating 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:

Table 1. Tuning the DB2 statement heap attribute
Maximum service instances	Statement heap size attribute value
12	4096
17	8192
24	16384

Change the statement heap size with the DB2 update command.

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 the IBM Verify Identity Governance data.
Browse to the appropriate operation definition. The operation definitions are located under this Distinguished Name:
```
DN:ou=operations,ou=itim,tenant,root suffix
```
Example: 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 suffix
```
Example: 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 that you want 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.

Creating or modifying a workflow design, a form, or a policy takes longer than the timeout interval

Creating 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. You 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 you 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

You 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 you are running the administration console on localhost. For example:

http://localhost:9080/isim/console

When 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)

Note: If you 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 you 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. You can successfully use localhost by specifying a grant statement in a .java.policy file in your home directory. If you 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";
};
```
Note: You must restart your browser after you create or modify the .java.policy file.