Troubleshooting
If you encounter any of the following issues or errors, SailPoint recommends that you follow the guidance provided below to resolve the error before contacting SailPoint Support.
Connector classes are not visible in the beanshell rule, therefore connector class file changes cause before/after Provisioning rules to fail with the following error:
sailpoint.tools.GeneralException: Class: EndPoint not found in namespace
Resolution – Implement before/after operation rules to have direct access to connector APIs.
Web services connector will check for Retry-After response in the response header. If Retry-After is not present it checks for limit, remaining, and reset. If none of the above are present in the response header it dumps the below log in the debug file, "RateLimit headers not received."
Resolution – Ensure the limit, remaining, and rest are present in the response header.
The Web Services Connector enforces the secure communication. As a result, this may cause Test Connection to fail with the following error if used with IBM JDK 1.8:
[ConnectorException] [Possible suggestions] Ensure configuration parameters are correct with a valid format, Ensure active network connectivity between Source and Target system. [Error details] javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Resolution – Perform the following to add the com.ibm.jsse2.overrideDefaultTLS
property in the Java properties:
-
Go to Servers > Java and Process Management >Process Definition > JVM > Custom?Properties and add the following property:
com.ibm.jsse2.overrideDefaultTLS
OR
Add in jvm.options file. For more information, refer to the following the link:
https://www.ibm.com/support/pages/overriding-default-jvm-ssl-properties-force-use-tlsv12
-
Restart the server.
Resolution – Manually set the attribute path value so it includes the period (.). For example, the JSON response of "Attribute.Name" should be set as ["Attribute.Name"].
{
"result": {
"manager.user_name": "Test"
}
}
JSON Path: $.result.["manager.user_name"]
Resolution – Remove the quotation marks from the multivalued attribute in the request body.
For example, the following request body may produce an error. The bold text is a multivalued attribute with quotation marks.
{ "username":"$plan.nativeIdentity$", "Group":"$plan.Group$", "email":"$plan.email$" }
To solve the error, remove the quotation marks so the request body is as follows:
{ "username":"$plan.nativeIdentity$", "Group":$plan.Group$, "email":"$plan.email$" }
If you have a custom After Provisioning rule in place, this is likely a result of having the throwProvAfterRuleException attribute enabled on your Web Services source. As a result, you may receive the following error during account provisioning:
Exception occurred while performing 'Create' operation on identity 'null': The application script threw an exception: java.lang.ClassCastException: Cannot cast java.lang.String to int BSF info: {Rule Name} at line: 0 column: columnNo
Resolution – Review the Web Services Source Configuration Reference Guide for steps on disabling the throwProvAfterException attribute using the source API.
The create account operation fails even though the recommended attribute mappings are used in the Account Policy.
Resolution – Ensure that the managed system is enabled to set the account attributes used by the Account Policy, then try the Create account operation again.
Aggregation processes are automatically retried when the connector experiences a HTTP error 429. You may see the following error:
HTTP error 429: Too many requests or rate limit exceeded
Resolution – Configure a valid Retry-After
response header attribute.
The aggregation is implicitly retried on the basis of the Retry-After
response header attribute. The allowed Retry-After
value range is from 1
to 180
seconds. If the response header has no Retry-After
value, then the connector retries a failed process after one second. If the response header has a Retry-After
value higher than the maximum 180
seconds (three minutes), then the connector retries a failed process after 180 seconds. If the response header has an accepted Retry-After value (three minutes or less), then the retry will take place after that time duration.
The connection to the source is timing out. This may be caused by an incorrect Base URL within the source's configuration in SailPoint. You may see the following messages as well:
java.lang.RuntimeException - com.sailpoint.pipeline.PipelineException: An internal error occurred handling stream response from the server.
- java.lang.RuntimeException: com.sailpoint.pipeline.PipelineException: An internal error occurred handling stream response from the server.
Caused by: java.lang.InterruptedException: Timeout waiting for response to message 63 from client
Resolution – Ensure that the Base URL is correct.
-
In SailPoint, go to Admin > Connections > Sources.
-
Select the appropriate Web Services source.
-
Go to Edit Configuration > Connection Settings.
-
Ensure the Base URL within the Server Host section is correct.
If not, provide the correct URL.
-
Save any changes you make.
The context URL used for the test connection contains a ">" character so it's not encoded properly.
Exception occurred in Test Connection.Url: {URL}, Message: java.lang.IllegalArgumentException:
Illegal character in query at index 79: {URL}, HTTP Error Code: 0
Resolution – Update the URL to include the encoded character should resolve the issue.
-
In Identity Now, go to Admin > Connections > Sources.
-
Select the Web Services source.
-
Go to Edit Configuration > HTTP Operations.
-
Find the HTTP Operation used for the test connection.
-
Select General Information.
-
Within the Context URL field, replace any ">" characters with "%3E".
-
Save the changes and test the connection.
Note
There may be other characters that aren't being encoded properly. If the URL contains other characters, try replacing them with their ASCII-encoded value equivalents as well.
Error message:
sailpoint.connector.ConnectorException: Url: <Configured URL> Message: 400 : Bad Request, HTTP Error Code: 400
Special characters that may cause issues with the context URL may include, but aren't limited to; commas (,
), open and close parentheses or brackets (()
, []
, and {}
), or pound signs (#
).
Resolution – If the context URL contains certain special characters, you may need to disable the skipEncodingDecodingUrl
key.
You can disable the skipEncodingDecodingUrl
key by adding the following to your
[
{
"op": "add",
"path": "/connectorAttributes/skipEncodingDecodingUrl",
"value": "true"
}
]
See the Update Source (Partial) article in the SailPoint Developer Community for more information on adding this command to your API.
$
character
Resolution – If the SOAP Body contains $
as a value in the request body, such as with $Role
, pass the following attribute into the plan as an AttributeRequest
:
Note
These examples use $Role
as the value placeholder. Substitute your own as required.
<AttributeRequest name="RoleNm" op="Add" value="$Role"/>
In the Web Services Operation > Raw Body configuration, use $plan.RoleNm$
as a placeholder the desired location as was done in the following example:
<ns1:RoleKeykey://2/$plan.RoleNm$/4484</ns1:RoleKey>
By making these suggested changes, the SOAP Body should be created in the required format. Refer to the following example:
Example:
For a provisioning plan with $Role
the attribute request will be as follows:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE ProvisioningPlan PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<ProvisioningPlan nativeIdentity="test@myorg.com" targetIntegration="WS-Test" trackingId="XXXXXXXXXXXXXXXXXXXXXXXXXXXX">
<AccountRequest application="WS-Test" nativeIdentity="XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" op="Create">
<AttributeRequest name="Full_Name" op="Add" value="Roger Benny"/>
<AttributeRequest name="RoleNm" op="Add" value="$Role"/>
<AttributeRequest name="email" op="Add" value="Roger.benny@myorg.com"/>
<AttributeRequest name="username" op="Add" value="Roger"/>
</AccountRequest>
</ProvisioningPlan>
Based on the example attribute request, you can expect the request body to be as follows:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<ns:Create>
<ns:dtos>
<ns1:UserDto>
<ns1:Email$plan.email$</ns1:Email>
<ns1:EnableEmailNotificationstrue</ns1:EnableEmailNotifications>
<ns1:FullName$plan.Full_Name$</ns1:FullName>
<ns1:RoleKeykey://2/$plan.RoleNm$/4484</ns1:RoleKey>
<ns1:UserKeykey://3/$plan.nativeIdentity$</ns1:UserKey>
</ns1:UserDto>
</ns:dtos>
</ns:Create>
</soapenv:Body>
</soapenv:Envelope>
The Oracle HCM target system may not be sending the data in the correct order. This reordering of the data may skip data which has been previously aggregated causing the aggregation process to delete it.
Resolution – Add the orderBy
attribute into the Context URL field in the account aggregation configuration to get the data in a properly sorted order. For more information on how to configure the Context URL field, refer to General Information.
Note
For more information on how to appropriately configure the orderBy
attribute, refer to Sort in the REST API for Oracle Fusion Cloud HCM documentation.