Known behaviors and limitations

The following behaviors and limitations are known to exist in the operation of the Salesforce.com Adapter.

Email address change of a Salesforce user

When IBM® Security Privileged Identity Manager changes an email address for a Salesforce.com account, it updates the email address in its directory store as soon as the request is successfully sent to Salesforce.com. However, the change is not immediately reflected in Salesforce.com. Salesforce.com requires users to verify the email address change request at the inbox of the new email address. Therefore, a period exists when IBM Security Privileged Identity Manager contains the updated email address, while Salesforce.com contains the old email address. During this period, one of these behaviors can occur:

The email address is verified by the user.: The email address is synchronized between IBM Security Privileged Identity Manager and Salesforce.com. No further action is needed.
The email address is not verified by the user.: The email address in IBM Security Privileged Identity Manager reverts to the old email address at the next reconciliation operation.
The user verifies that the email address after reconciliation occurs.: IBM Security Privileged Identity Manager reverts to the old email address with the reconciliation operation. Salesforce.com updates IBM Security Privileged Identity Manager with the new email address at the next reconciliation operation.

Set up a reconciliation policy with sufficient frequency to help keep email addresses consistent between Salesforce.com and IBM Security Privileged Identity Manager.

Account deletion from the Salesforce.com Service

Salesforce.com does not delete users. Therefore, the Salesforce.com Adapter marks a user account as Inactive when it receives a request to delete the account from IBM Security Privileged Identity Manager. If a Salesforce.com administrator reactivates a user from the Salesforce.com user interface, the user is returned as an orphan account at the next reconciliation.

Timeout issues

A network socket timeout might occur if the Salesforce.com connector is unable to complete a network-related operation with the Salesforce.com server within the timeout period specified. The timeout period can be affected by many settings:

Adapter configuration
IBM Security Identity server configuration
Dispatcher configuration
Java VM configuration
Operating system configuration
Network equipment configuration such as switches or firewalls.

Refer to the corresponding documentation for the default settings of the vendors.

To resolve timeout issues that are related to the Salesforce.com Adapter:

Edit the default socket timeout value for the Salesforce.com connector in the service.def file. Change the SFSocketTimeout value. By default, it is set to 600 seconds or 10 minutes. This setting corresponds to the default Dispatcher SearchALUnusedTimeout setting. Increase both of these values, if the reconciliation operation takes longer than 10 minutes. See the Dispatcher documentation for instructions about setting the SearchALUnusedTimeout value.
The adapter might timeout when it communicates with Salesforce.com because of network issues. To have the connector reestablish a connection to the Salesforce.com server and try the operation again, edit the ITDI_HOME\timsol\etc\reconnect.rules file. Add the line:
```
com.ibm.di.connector.salesforce.SalesforceConnector:
:com.ibm.di.connector.salesforce.SalesforceConnector
Exception:reconnect:
```
The line is a generic rule for the connector to reconnect when any exception is encountered.

Session handling

You might receive an INVALID_SESSION_ID exception that is logged in your Security Directory Integrator logs. When an INVALID_SESSION_ID exception is encountered, the connector automatically tries to establish a new connection to Salesforce.com before it tries the API call again. Otherwise, a failure might occur because of a timeout in the session.

You can ignore INVALID_SESSION_ID warnings that are followed immediately by logs that display RECOVERING FROM INVALID SESSION ID.

Login Rate Exceeded error

Salesforce.com has a default limit for the number of login attempts per hour.

To address this limit, the adapter is designed to use sessionID to authenticate operations after first login. You must enable Assembly Line Caching. Otherwise, if you perform operations that exceed 3600 within an hour, you might see a Login Rate Exceeded error from Salesforce.com.

To enable Assembly Line Caching:

Select Enable AL Caching on the service form.
Verify that the AL Caching is enabled in the dispatcher setting.
Verify the itim_listener.properties in the TDI folder and ensure that the ALCacheSize value is set to greater than 0. For example, 100.
Restart the dispatcher service to apply the changes.