Troubleshooting

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.

TLS certificates can be imported and configured in WebSphere's trust stores through SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore.

However, the Web Services Connector depends on the trust store of the JDK during TLS communication and does not respect the WebSphere's trust stores. This results in TLS communication failure.

Resolution – An additional configuration is required to override and set the default trust store as WebSphere’s trust store.

1. Go to Servers > Application Servers > _ server_name_ > Process Definition > Java Virtual Machine > Custom Properties > New.

2. Add the following properties with your organization's information filled in for the property values, minus the < and > characters.

   Copy

   javax.net.ssl.trustStore="<WebSphere truststore file path>"
   javax.net.ssl.trustStorePassword="<Truststore Password>"

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:

1. 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

2. 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$" }

Beginning with IIQ 8.0p2, the way the connector handles HTML/XML entities has been updated to support multiple content types. As a result, characters such as <, >, ", and & don't require HTML encoding anymore. For example, if you need to represent a greater-than symbol (>) in your HTML/XML body, you can simply enter ">" instead of "<".

Resolution – Remove HTML-encoded escape entities from attribute values which contain HTML /XML code, and replace them with the intended characters.

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.

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 config file:

[
    {
        "op": "add",
        "path": "/connectorAttributes/skipEncodingDecodingUrl",
        "value": "true"
    }
]

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 Operation-Specific Configuration Parameters.

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.