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

For issues or errors that are not addressed in this connector guide, refer to the following resources for troubleshooting information:

- [SailPoint Identity Services Documentation](<https://documentation.sailpoint.com/saas/help/index.html>)
- [SailPoint Support Knowledge Base](<https://support.sailpoint.com/csm?id=kb_view2&amp;kb_id=05ff44289f011200550bf7b6077fcfa3>)
- [SailPoint Developer Community](<https://developer.sailpoint.com/>)

## Failure Status for Identity Access Requests

When the SAP GRC system is unreachable during the connector's polling cycle, identity access requests remain in the GRC queue as pending and can still be processed once the system becomes available. However, the SailPoint incorrectly reports these requests as failed due to a `SocketTimeoutException` or `UnknownHostException` issue, but are actually still actionable within GRC.

**Resolution**: To prevent the connector from prematurely reporting a failure status when the GRC system experiences a timeout during the polling cycle, add the `ignoreTimeoutOnStatusCheck` attribute to the source configuration using the REST API:

```json
[
    {
        "op": "add",
        "path": "/connectorAttributes/ignoreTimeoutOnStatusCheck",
        "value": "true"
    }
]
```

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community.

## SAP GRC - AC12 SP19 and above considerations

SAP has introduced significant modifications in its SAP GRC version AC 12.0 SP19 and above in inactive users and sync job processes, which has affected our SAP GRC connector functionality adversely.

### Details about the issues and fixes

#### Disable Operation

- **Issue**: With the upgrade of GRC from AC12 SP19 and above, you may see **System attribute on account schema** as **INACTIVE\_USER** for the aggregated accounts which are disabled only on the highest priority system on SAP GRC.
- **Resolution**: This issue is observed due to the Repository sync job changes introduced by SAP for updating their table values. For resolution, ensure the changes on GRC and the source configuration are as follows:

  1. Ensure that the Repository sync job is scheduled on your SAP GRC instance.
  2. The option for `Disable only Master` system has been removed from the source config UI without impacting existing customers configuration. SailPoint highly recommends, however, that you revisit your source configuration for `Disable` operations. The changes have been documented in [Enable and Disable Account](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/connecting.html#enable-and-disable-account>).
  3. Provide additional permissions required on the SAP tables for GRC 12 SP19 and above for aggregation and disable operations. For more information, refer to the [Configuration Table for SAP GRC](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/connecting.html#configuration-table-for-sap-grc>).

#### Modify Operations

- **Issue**: SAP has introduced a new process where any modifications in the user profile reflect in GRC tables only after completing the repository sync job. This has adversely affected our connector operations.
- **Resolution**: The following steps must be performed sequentially for a successful modify operation:

  1. Configure the Attribute Sync request on the user in SailPoint for the GRC source. To configure the attribute sync request, refer to [Synchronizing Attributes - SailPoint Identity Services](<https://documentation.sailpoint.com/saas/help/provisioning/attr_sync.html>).
  2. Run the Repository Object Sync job on your GRC system.
  3. Execute the User Aggregation on your GRC source to get the updated values of the user attributes.

## System attribute value is showing INACTIVE\_USER \[For SAP GRC - AC12 SP19 and above\] in SailPoint

For SAP GRC - AC12 SP19 and above, the connector column in the GRACUSER table shows '\<\#INACTIVE\_USER\#\>' for accounts that are disabled on the highest priority data source.

With GRC12 SP19 and above, SAP has introduced changes in the GRACUSER table and sync job. Users will now see \<\#Inactive\_User\> as the connector value for the disable operation in the following cases if the full sync job has not completed:

1. If an account is disabled only on a GRC-connected master system (highest priority system).
2. If an account is disabled on all the GRC-connected systems including the master system.

For more details, refer to SAP KBA 3251717. Due to the above, the SailPoint platform will show 'INACTIVE\_USER' in the `System` attribute until the full sync job is completed successfully before aggregation.

## Provisioning fails with Invalid request type error

**Resolution**: Ensure the request type is configured correctly. Follow the steps in [Verify the Request Type and Configuration](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/index.html#verify-the-request-type-and-configuration>), and confirm the BRF + MSMP workflow is configured correctly for the request type.

> [!NOTE]
>
> **Screenshot**
>
> [![BRF MSMP](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/img/brf_msmp.png>)](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/img/brf_msmp.png>)

If it isn't, provide the correct permissions for the service account created for authorization object **GRAC\_REQ**, by providing a correct value for **GRAC\_RQTYP**.

## usertype attribute causes changes on all connected systems

When the usertype attribute is passed in the provisioning plan for an account, the changes are reflected on all the systems connected to that account.

**Resolution**: Add the following attribute using [Rest API for updating a source](<https://developer.sailpoint.com/docs/api/v3/update-source/>) in SailPoint.

- Key=`supportSystemUpdate` Value=`true`
- `supportSystemUpdate` is a boolean attribute

The flag must be set to true, so that when the userType attribute is passed in the provisioning plan, only the system passed in the plan will be sent in the GRC API.

## Entitlement count mismatch (SAP GRC vs SailPoint)

If the number of roles (entitlements) in SailPoint does not match what you see in SAP GRC Access Control, the connector usually reads incomplete or non-production-ready role data from GRC backend tables.

The SAP GRC connector aggregates entitlements from GRC repository tables (such as `GRACROLE` and `GRACRLCONN`). If a role is not fully synchronized, not in production status, or not requestable in the GRC portal, it might exist in the connected SAP system but not appear in SailPoint.

1. Confirm that the role is requestable in the SAP GRC portal.
2. Verify that role synchronization jobs completed successfully.
3. Confirm that the role status is **Complete** in Role Maintenance.

   Go to **SAP GRC \> Role Management**. Open the role under the current phase on the **Role Maintenance** tab.

   Verify:

   | Check | Required Value |
   | --- | --- |
   | Role exists in current phase | Yes |
   | Role maintenance status | **Complete** |
   | All required role maintenance steps | Finished for current phase |
4. Confirm provisioning settings on the **Provisioning** tab.

   Open the same role in GRC and go to the **Provisioning** tab.

   Verify:

   | Field | Required Value |
   | --- | --- |
   | **Production status** | Set to **Production** |
   | **Role Exists** | **Yes** |
   | **Provisioning Allowed** | **Yes** |

## SAP source config test connection fails when the VA is configured with secure tunnel, or when the VA and manage system are on a different network

```text
"sailpoint.connector.ConnectionFailedException: Server is DOWN or Connection parameters are incorrect.
```

OR

```text
ERROR       hostname 'sailpoint-va' unknown\nTIME
```

OR

```text
JCO_ERROR_COMMUNICATION: Connect to SAP gateway failed
```

**Resolution**: There are three possible options to solve this error.

**Option 1**: One of the reasons for the issue to occur is the IP address of the VA is not recognized by the connector. To resolve this, you must make an entry in hosts.yaml with the IP address of the VA as well as the managed source (SAP server).

> [!NOTE]
>
> For information on creating a hosts.yaml file, refer to [Configuring a Hosts.yaml File](<https://documentation.sailpoint.com/saas/help/va/config_va.html#configuring-a-hostsyaml-file>).

For example:

```text
hosts:
10.200.80.60: -SAPSER4
10.22.131.14: -sailpoint-va
```

Where `10.200.80.60` is the IP and `SAPSER4` is the hostname of the SAP server, and `10.22.131.14` is the IP of the VA and `sailpoint-va` is the default name of the VA. Ensure that SAP is installed with JCO enabled.

Similarly, add the IP and hostname of the VA being used in the file. Restart CCG/ Reboot VA after the update.

**Option 2**: Add Route entry in static.network file to persist routing table entry of the VA hostname. To do so, perform the following steps:

1. In your VA, go to ../etc/systemd/network/static.network
2. Add the following entry:

   ```text
   [Route]
   Gateway=<10.0.0.1>
   Destination=<public_ip>/<netmask>
   ```
3. Run `sudo systemctl restart systemd-networkd` to apply the configuration.
4. Run `route -n` to show routes.
5. Restart CCG/ Reboot VA and check if the entry still persisted.

**Option 3**: Update DNS entries for VAs on your network so that FQDN resolves for each VA. To do so, perform the following steps:

1. Run `sudo hostnamectl set-hostname <hostname of your choice>` to set the VA hostname.
2. Run the `hostname` command to validate.
3. Run `sudo reboot` to reboot the VA.

The VA should reflect the new hostname.

## Could not initialize class com.sap.conn.jco.rt.JCoRuntimeFactoryError during test connection and aggregations

```text
Could not initialize class com.sap.conn.jco.rt.JCoRuntimeFactory
```

**Resolution**: The host value must be updated on VA with the FQDN of the SAP server. Re-upload the `sapjco` and `libsapjco` jars on the UI.

## ASSIGN\_TYPE\_CONFLICT exception occurs on UI during connector operations

The following error message is displayed when using Function Module /SAILPOIN/SAIL\_READ\_TABLE and /SAILPOIN /SAIL\_READ\_TABLE\_LEG:

```text
Exception during aggregation. Reason: java.lang.RuntimeException: ASSIGN_TYPE_CONFLICT while querying table *Table_Name*. One of the fields queried (field1,field2,field3… ) may have incorrect COLUMN_LENGTH set in /SAILPOIN/CONF table. Please refer ASSIGN_TYPE_CONFLICT in troubleshooting section of documentation for more details.
```

**Resolution**: Ensure COLUMN\_LENGTH is correctly configured for the fields of `Table_Name` in /SAILPOIN/CONF table. This can be validated through the t-code "SE11" while viewing the table details, under "Fields" tab.

## TABLE\_ACCESS\_NOT\_ALLOWED error gets logged in log file and WARN level while executing account aggregation

```text
connector.sapgrc.service.SAPGRCConnectorService:302 - Exception while getting system info from CVERS and PRDVERS tables
sailpoint.connector.ConnectorException: Caused by class com.sap.conn.jco.AbapException: (126) TABLE_ACCESS_NOT_ALLOWED: Message 000 of class null type : . SAP_QUERY_TABLE_NAME:CVERS
```

**Resolution**: Provide the correct permissions to service account user on CVERS and PRDVERS tables and ensure you have both of the following:

- CVERS/PRDVERS is added S\_TABU\_NAME authorization object.
- CVERS/PRDVERS added in SAILPOIN/CONF table.

## SAP GRC Access Control 12.0 - Requests approved by GRC are displayed as rejected in SailPoint

**Resolution**: Ensure that the following SAP Note is implemented in the SAP GRC Server:

```text
2698051 - AC12 - GET_REQUEST_DETAILS is returning empty line items
```

## SAP GRC Access Requests Fail

The access requests fails with the following message:

```text
Invalid Request No.
```

**Resolution**: Add the `numberOfRetries` and `retryWaitTime` parameters to configure polling requests retries.

Add the following entry keys to the SAP GRC connector:

```text
<entry key="numberOfRetries" value="3"/>
<entry key="retryWaitTime" value="5"/>
```

> [!NOTE]
>
> The following are the default values for the parameters:
>
> - `numberOfRetries` is 3 retries.
> - `retryWaitTime` is 5 seconds.
>
> You can update these values as required.

## Test connection fails with 307 error

When attempting a test connection it fails with the following error:

```text
HttpException errorCode=307
```

The 307 error is for URL redirects. This error is observed when the SAP GRC managed system is configured for HTTPS URLs and the source XML is configured with HTTP URLs.

**Resolution**: Update the source XML with the HTTPS URLs and the correct HTTPS port number.

## Access Request Status displayed as Incomplete

**Resolution**: Ensure that the **Repository Object Synchronization** task is executed in GRC.

## Role owner details are not aggregated

**Resolution:** Refer to and apply the following SAP note in the SAP GRC managed system:

```text
https://launchpad.support.sap.com/#/notes/3043243 :WS: GRC Role owner is not getting fetched in Search roles web service.
```

## The Valid From and Valid To dates are not configured during provisioning operation

**Resolution:** Refer to and apply the following SAP note in the SAP GRC managed system:

```text
2970855 - IDM GRC Request creation date: https://launchpad.support.sap.com/#/notes/2970855
2958851:2958851 - User Valid from date is not updating correctly: https://launchpad.support.sap.com/#/notes/2958851
```

## User ID and Email of Requester is mandatory

**Resolution:** Follow the steps to add the requester and email to the source config as documented in [Configuring Provisioning Settings](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/connecting.html#configuring-provisioning-settings>).

## Missing data in Account aggregation when the slash (/) character is used in the user ID

**Resolution**: If GRC users that have the slash (/) character in their user ID are not getting aggregated during account aggregation, perform the following:

1. Modify the source XML using the following REST API:

   ```text
   POST https://{orgName}.api.identitynow.com/cc/api/source/update/{source ID}
   ```

   In the body of the POST, use the form-data as follows:

   - Key: `grc_delimiter`
   - Value: `~`

   You can replace the value with other special characters (for example, \#, $, @, etc.) that are not part of any of the user data fields like FirstName, LastName, UserId, Department, Email, etc.

   > **Note**
   >
   > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community.
2. Execute an Account aggregation.

   > **Note**
   >
   > This configuration is only application in cases where you're using the `SAILPOIN/SAIL_READ_TABLE` function module.

## Provisioning of SAP profiles fails

SAP profiles are aggregated as entitlements during account aggregation if some accounts have standard profiles assigned to them (like SAP\_ALL or A\_ALL). The provisioning for these profiles fails.

```text
sailpoint.connector.ConnectorException: Object not found
```

**Resolution**: Import the SAP profiles into the GRC BRM module using the following procedure:

1. In the GRC Portal, go to **Role Mass Maintenance \> Role Import**.
2. In **Role Selection**, select **Technical Role**.
3. In **Import Source**, select **Role Attribute Source** as **File on Desktop** and **Role Authorization** as **Skip**.
4. In **Role Selection Criteria**, in the **Role From** field, enter profile name and set **Methodology Status** to **Complete**.
5. Download the attribute file template.
6. Enter the profile details in the file template.
7. Import the file template.
8. Once you have successfully imported the file then you can provision the profiles.

## System From date is getting updated to today's date when the provisioning plan contains only system To date

**Resolution**: Add the following attribute using [Rest API for updating a source](<https://developer.sailpoint.com/docs/api/update-source-v-1>) and then, try modifying the system to date of a user.

Key=`updateValidFrom` Value=`true`

`updateValidFrom` is a boolean attribute.

When this flag is true, the already existing From date (for the system in which the To date has passed) will be fetched for the account and set in the API. If there is no existing FromDate then today's date will be used as the From date.

## Invalid configuration exception during Test Connection

**Resolution**: To resolve configuration related errors, try the following:

- Verify that the configurations are valid and align with the requirements of your environment.
- Ensure the user is active with the correct set of permissions and credentials.

## Unable to find valid certification path to requested target

The following error appears:

```text
javax.net.ssl.SSLHandshakeException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
```

**Resolution**: Follow these steps to resolve the `SSLHandshakeException` error caused by the inability to find a valid certification path:

Option 1:

1. Open the URL `https://{host}.com` in a web browser
2. Export the SSL certificate.

   Follow the wizard's instructions and select the `.cer` format for the exported certificate.
3. Place the exported certificate file under the `/home/sailpoint/certificates` directory on the Virtual Appliance (VA).

Option 2 :

1. Login to Virtual Appliance (VA).

   Run the following command to initiate an SSL/TLS connection:

   ```text
   openssl s_client -connect {host}:{port}
   ```
2. Once the connection is established, locate the certificate block in the response, which starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----.

   Copy the entire certificate content, including the begin and end lines, and save it to a file with a `.cer` extension.
3. Place the exported certificate file under the `/home/sailpoint/certificates` directory on the Virtual Appliance (VA).

Restart the CCG service and perform the test connection.

## Development roles are not aggregated; only production roles are aggregated

During role or group aggregation, only production roles are returned. Development roles are not aggregated in SailPoint.

This is standard behavior of the `GRAC_SEARCH_ROLES` web service. The web service returns roles that have a role status marked as production status in SAP GRC.

**Resolution**: To include development roles in aggregation results, enable the development role status as production status in SAP GRC and verify role-level provisioning settings.

1. Go to **SPRO \> SAP Reference IMG \> Governance, Risk and Compliance \> Access Control \> Role Management \> Maintain Role Status**.
2. Select the development role status for your environment (for example, `DEV`).
3. Select the **Production Status** checkbox for the development role status.
4. Save your changes.
5. For each development role you want to aggregate, verify the following in role management:

   - On the **Role Maintenance** tab, the role status is **Complete** for the current phase.
   - On the **Provisioning** tab, set **Role Exists** to **Yes**, set **Provisioning Allowed** to **Yes**, and ensure the role is set for production status.
6. Run the role sync job on your SAP GRC system if the role is available in the `GRACRLCONN` and `GRACROLE` tables.
7. Run group or entitlement aggregation again in SailPoint.

> [!NOTE]
>
> SAP typically recommends `PRD` or `PRO` as production role statuses. You can also enable `DEV` or `TST` as production status based on your testing environment requirements.

## skipSystemItem attribute is not honored during Modify operations when user type and company attributes are present

During the Modify (Add Entitlement) operation, the `skipSystemItem` attribute is not honored when the `usertype` and `company` attributes are present in the provisioning request. The system gives precedence to these attributes, which prevents it from skipping the SYS request line item as expected.

**Resolution**: Add the following entry to the source XML to skip the SYS request line item from the GRC access request during update or modify user operations:

```text
<entry key="skipSystemItemForUpdateUser" value="true"/>
```

> [!NOTE]
>
> - After this key is added, the connector skips the SYS request line item irrespective of attributes requested for the modify provisioning operation.
> - This key is applicable only for update or modify user operations.

## SAP GRC ticket shows a truncated source UUID in Submitted by when Credential Provider is enabled

When Credential Provider is enabled on the SAP GRC source, the SAP GRC access request ticket displays a truncated source UUID (for example, `7245aec0899`) in the Submitted by field instead of the configured requester ID (for example, `SAIL_IGA_GRC`). The connector `requesterId` attribute is temporarily overwritten with the source UUID for credential retrieval and is submitted to SAP GRC.

**Resolution**: Add the following attributes to the source configuration using SailPoint's REST API so the connector uses a separate static value for the SAP GRC ticket requester when Credential Provider is enabled:

```json
[
    {
        "op": "add",
        "path": "/connectorAttributes/useConfiguredGrcRequesterId",
        "value": "true"
    },
    {
        "op": "add",
        "path": "/connectorAttributes/configuredGrcRequesterId",
        "value": "{requesterID}"
    }
]
```

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community.
>
> `useConfiguredGrcRequesterId` is honored only when Credential Provider is enabled on the source. Otherwise, connector behavior is unchanged.

## Valid from and Valid to dates are not getting set during provisioning operation

**Resolution**: Apply the following SAP Notes:

- 2970855 :IDM GRC Request creation date: [https://launchpad.support.sap.com/\#/notes/2970855](<https://launchpad.support.sap.com/#/notes/2970855>)
- 2958851:2958851 - User Valid from date is not updating correctly: [https://launchpad.support.sap.com/\#/notes/2958851](<https://launchpad.support.sap.com/#/notes/2958851>)

## Group aggregation fails with an error message

When running the group aggregation task to aggregate SAP GRC Roles the following error appears:

```text
25 Mar 2021 17:33:50,628 196554352 [QuartzScheduler_Worker-2] ERROR ExecutionMediator [] - Exception while executing request for URL https://urldefense.com/v3/__https://dggdb.absa.co.za:8201/sap/bc/srt/rfc/sap/grac_search_roles_ws/200/grac_search_roles_ws/grac_search_roles_ws__;!!MsNKLpFGsw!b_c3uRmriMN5_S9zF7rZyUtSDGHENCJNtKK_yyuonrPxT_gU5F9qMcQ2_ubmdEQQ$ connector.common.http.exception.HttpException: java.net.SocketTimeoutException: Read timed out
```

**Resolution**: To increase the timeout values, add the `apiTimeout` attribute to the application debug page as follows:

```text
<entry key="apiTimeout" value="240"/>
```

## RequestStatus Map is empty

**Resolution**: Add the following to the source configuration using SailPoint's REST API.

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community.

```xml
<entry key="firstRetry">
    <value>
        <Boolean>true</Boolean>
    </value>
</entry>
```

## Group aggregation fails with a read timeout error

**Issue:** When running group aggregation, the following error appears:

```text
java.net.SocketTimeoutException: Read time out
```

**Resolution:** Configure group aggregation by System or by Connector group. When you enable this option, the connector sends iterative calls for each System or Connector group. This avoids the `TIMEOUT` error. Add the following to the source configuration using SailPoint's REST API.

For System:

```text
<entry key="gracRoleServiceFilter" value="System"/>  for System OR
```

For Connector Group:

```text
<entry key="gracRoleServiceFilter" value="ConnectorGroup "/>
```

> [!NOTE]
>
> Ensure to have required permission for service account and on /SAILPOIN/CONF table as per the connector permission section. Ensure to have parameter 'apiTimeout' with value 10 and above as per [Timeout Errors and Settings](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/troubleshooting/timeout_errors.html>). This will aggregate roles per system/connector group calls to SAP GRC.

## FireFighterID and Owner Name Are Not in Sync

**Resolution**: Ensure that you have added the authorization object to the roles assigned to the user. For more information, refer to [FireFighterID Permissions](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/index.html#firefighterid-permissions>).

Refer to [Troubleshooting IAG Bridge](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/troubleshooting/iag_bridge.html>) and [Support for Custom Workflow](<https://documentation.sailpoint.com/connectors/sap/grc/va/help/troubleshooting/support_for_custom_workflow.html>) for more troubleshooting information.
