Troubleshooting

The Past_Termination_Offset parameter can be used to limit the aggregation of termination records based on offset days provided in the application. If there are multiple termination records for a worker, however, the user might experience a problem of the incorrect termination record getting picked up during aggregation.

Resolution: If the problem persists even after using the Past_Termination_Offset parameter to extend or reduce the past termination date offset, then add the splitPastTerminationOffsetBy parameter to the application debug page which will split the terminated workers aggregation into two steps.

For more information on the ‘Past_Termination_Offset’ parameter, refer Aggregation Settings.

For example:

• Today's Date: 31May2019
  Past_Termination_Offset: 60
  splitPastTerminationOffsetBy: 30
  First iteration would bring terminated accounts from 1 May 2019 to 31 May 2019 Second iteration would bring terminated accounts from 30 Apr 2019 to 1 Apr 2019.

• Today'sDate: 31May2019
  Past_Termination_Offset: Not specifiedsplitPastTerminationOffsetBy: 30
  First Iteration will bring terminated accounts from 1 May 2019 to 31 May 2019 Second Iteration will bring terminated accounts from 30 Apr 2019 to 1 Jan 1970.

The splitPastTerminationOffsetBy parameter is optional and fetches the latest record for multiple termination record for a file number in short span of time. This would ensure that correct record is fetched and no multiple records are toggled during aggregations.

Workday aggregation is failing with the following exception after initiating account aggregation:

Aggregation failed in one or more thread execution:: exception :

openconnector.ConnectorException: [ ConnectorException ] [ Error details ]

Exception : javax.net.ssl.SSLException: Read timed out

Or

java.net.SocketTimeoutException: Read timed out

Resolution: Include the above error as a "retryable" error on the source. Additionally, you may need to increase the retryCount.

To increase the retry count and add the error to the list of retryable errors, complete the following:

1. Increase the retryCount attribute using the v1 API.

   Copy

   POST https://{orgName}.api.identitynow.com/cc/api/source/update/{workdaySourceID}
   
   Form-Data:
   
   key: connector_retryCount
   value: 5

   Note
   Increase the retryCount to 10 if 5 does not work.

2. Add the following errors to the list of retryable errors

   Copy

   PATCH https://{orgName}.api.identitynow.com/beta/sources/{workdaySourceGuid}
   
   [
       {
   "op": "replace",
   "path": "/connectorAttributes/retryErrors",
   "value": [
   "Connection reset",
   "503 Service Unavailable",
   "javax.net.ssl.SSLException: Read timed out",
   "java.net.SocketTimeoutException: Read timed out"
           ]
       }
   ]

   Note
   By default, Connection reset and 503 service unavailable are in the retryable errors list.

3. Set the connection timeout parameter to 2 or 3 on the Connection Settings page of the Workday connector.

The following error is received when testing the connection for the Workday connector:

Processing error occurred. PermGen space

This message is a Workday error that indicates the Workday server has run out of memory.

For example, the server may be processing a report that is consuming the server’s available memory. You need to work with your Workday team to resolve the server memory issues.

Resolutions: The following lists the possible exceptions and their solution:

• Test Connection Failed

• UnknownHostException

• FileNotFoundException

• HTTP response code: 500

Ensure that the Workday URL is correct and is case sensitive.

Test connection fails with the following error message due to Weblogic Server not using standard SUN HTTPS implementation provided by jdk:

openconnector.ConnectorException: javax.net.ssl.SSLKeyException: FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received

The Weblogic Server uses the weblogic.net.http.SOAPHttpsUrlConnection class instead of the javax.net.ssl.HttpsUrlConnection class.

Resolution: Start the Weblogic Server with the following argument so that it will use SUN HTTPS default handler:

-DUseSunHttpHandler=true jvm

Complete the following steps:

1. Open WebLogic Sever installed directory and go to \user_projects\domains\base_domain\bin directory.

2. Edit the startManagedWebLogic.cmd file and set JAVA_OPTIONS=-DUseSunHttpHandler=true%JAVA_OPTIONS%

3. Save the startManagedWebLogic.cmd file.

4. Edit the startManagedWebLogic.sh file and set JAVA_OPTIONS="-DUseSunHttpHandler=true" ${JAVA_OPTIONS}"

5. Save the startManagedWebLogic.sh file.

6. Start the Managed Server.

While provisioning the PHONE_HOME, PHONE_WORK, ADDITIONAL_PHONE_HOME, and ADDITIONAL_PHONE_WORK attributes the following error message is displayed:

not Valid ID value for type="Phone_Device_Type_ID"

The above error message appears as the Workday connector uses the default phone device reference ID. The phone device reference ID varies according to the tenant. The Workday connector contains a ReferenceIDMap that contains phone device type id map.

Resolution: To change the reference ID of a specific phone device type, modify the Phone_Device_Type_ID map as follows using the IdentityNow REST API:

Note
For more information on IdentityNow APIs, refer to Best Practices: IdentityNow REST API Authentication and IdentityNow REST API - Update Source (Partial) in the SailPoint Developer Community.

PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID}

[
    {
        "op": "add",
        "path": "/connectorAttributes/ReferenceIDMap",
        "value":  {"Phone_Device_Type_ID":{"Mobile":"1063.1","Telephone":"1063.5","Fax":"1063.4","Pager":"1063.6"}}
    }
]

Complete the following to find Phone_Device_Type_Reference_Id:

1. Search View Workday ID report.

2. Enter Phone Device Type as class name in the report and select OK.

3. Select Related action of phone device type > Integration IDs > View Reference IDs.

   The Reference ID values of Phone Device type ID are listed.

If the EMPLOYEE_TYPE value for any contingent worker is not correct, for example, 382.2 which is the ID of the EMPLOYEE_TYPE.

Resolution: The application contains a default map as follows for mapping the incorrect IDs with employee type:

Note
For more information on IdentityNow APIs, refer to Best Practices: IdentityNow REST API Authentication and IdentityNow REST API - Update Source (Partial) in the SailPoint Developer Community.

PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID}

[
    {
        "op": "add",
        "path": "/connectorAttributes/ReferenceIDMap",
        "value":  {"Employee_Type_ID":{"382.1":"Consultant","382.2":"Contractor","382.3":"Vendor"}}
    }
]

The above default map, would map 382.2 key with Contractor string. For numeric value issues in EMPLOYEE_TYPE account attribute in IdentityNow, if the actual Contractor string is not obtained then copy the value of the appropriate reference id of that employee type from the Workday managed system and add it in Workday application Employee_Type_ID map.

For example, in IdentityNow for a value of 382.2 in EMPLOYEE_TYPE complete the following steps:

1. In Workday managed system search for Contingent Worker Type and select it.

2. For each row a related action option exists. Open Related action > Integration ID > View IDs and find the type of contingent worker assigned to 382.2.

3. After finding the correct value of the contingent worker type, add the value to the Employee_Type_ID map in the application XML page.

   For the correct changes to be reflected perform full aggregation task.

While updating contingent worker data for existing applications, the following error message is displayed:

Invalid ID value. '21430' is not valid ID value for type='Employee_ID

Resolution: If the provided Employee_ID belongs to the contingent worker, add the following map using the IdentityNow REST API:

Note
For more information on IdentityNow APIs, refer to Best Practices: IdentityNow REST API Authentication and IdentityNow REST API - Update Source (Partial) in the SailPoint Developer Community.

PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID}

[
    {
        "op": "add",
        "path": "/connectorAttributes/EmployeeTypeMap",
        "value":  {"EmployeeTypes":["Regular","Casual","Fixed Term Contract","Seasonal","Temporary"],"ContingentWorkerTypes":["Contractor","Consultant","Vendor"]}
    }
]

Note
This map is present for new connectors.

Complete the following to find the supported employee type:

1. In Workday managed system, search for reports of type Employee Types.

2. In the displayed report, verify if any additional employee type is listed on the Workday managed system. If a new employee type is listed, add it in EmployeeTypeMap > EmployeeTypes.

   For example, if an additional employee type is found in Trainee then add the following entry under EmployeeTypeMap > EmployeeTypes:

   <String>Trainee</String>

Complete the following to find supported contingent worker types:

1. In Workday managed system, search for reports of type Contingent worker Types.

2. In the displayed report, verify if any additional contingent worker type is listed on the Workday managed system. If a new contingent worker type is listed, add it in EmployeeTypeMap > ContingentWorkerTypes.

   For example, if additional employee type is found in Trainee Consultant then add the following entry under EmployeeTypeMap > ContingentWorkerTypes:

   <String>Consultant</String>

While updating the Workday account email or phone attribute, the following error message is displayed:

The task submitted is not authorized

Resolution: The error message indicates that user is not authorized with some permission. The Workday administrator must verify if the specific integration security group is added to Maintain Contact Information (Web Service).

By default, the connector retrieves BenefitEligibility data while retrieving the workers.

Resolution: To exclude retrieving BenefitEligibility data, add the following using the IdentityNow REST API:

Note
For more information on IdentityNow APIs, refer to Best Practices: IdentityNow REST API Authentication and IdentityNow REST API - Update Source (Partial) in the SailPoint Developer Community.

PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID}

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

By default, the connector does not retrieve Supervisory Organization data while retrieving the workers.

Resolution: To retrieve Supervisory Organization data, add the following using the IdentityNow REST API:

Note
For more information on IdentityNow APIs, refer to Best Practices: IdentityNow REST API Authentication and IdentityNow REST API - Update Source (Partial) in the SailPoint Developer Community.

PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID}

[
    {
        "op": "add",
        "path": "/connectorAttributes/Exclude_Supervisory_Organizations",
        "value":  {"excludeBenefitEligibility":"false"}
    }
]

Resolution: When Reference IDs are updated in Workday, you must complete the following:

1. Delete the ReferenceIDMap entry from the application XML page.

2. Delete the following relevant entries from the XpathAttributesMap:

   • (Phone Reference IDs) WORK_MOBILE, WORK_TELEPHONE, HOME_MOBILE, and HOME_TELEPHONE

   • (Employee Type Reference ID) EMPLOYEE_TYPE

   • (Contingent Worker Type Reference ID) Contingent_Worker_Type

3. Perform aggregation.

   The Workday connector updates the latest IDs in the application along with latest Xpath for the attributes listed in Step 2 above.

When access token expires, an error message appears. The Workday connector checks the following strings in error messages in order to generate new access token:

• 400

• 401

• Unknown Error

• Invalid access token

Resolution: In cases where the error message does not contain any of the above mentioned strings, then configure the oauth2Errors attribute to accommodate the additional error sub-strings as follows:

Key: connector_oauth2Errors

Value: ["Token expired","MY_CUSTOM_ERROR"]

During aggregation, due to network load or tenant/server connectivity issues, intermittent errors are displayed. By default the Workday connector displays the following error:

Connection reset, 503 Service Unavailable

Resolution: Set the following attributes using the IdentityNow REST API to add this error to the retryable errors list:

retryErrors: The list of error strings. This can be configured in the source xml file. The default value is Connection reset and more error strings can be added.

• Key: connector_retryErrors

• Value: ["Connection reset", "failed to respond"]

retryCount: This is the count of retrying the failed request. Default value is 1 and this can be edited.

• Key: connector_retryCount

• Value: 1

Note
For more information on IdentityNow APIs, refer to Best Practices: IdentityNow REST API Authentication and IdentityNow REST API - Update Source (Partial) in the SailPoint Developer Community.

The Workday connector correctly aggregates custom attributes for converted workers and future dated workers, in both full aggregation and delta aggregation.

Note
In the Workday managed system the effective dated custom attributes are not transferred from contractor to converted employee. You must manually re-enter the details for the worker.

Resolution: To fetch rescinded past hires data for a worker, their hire date must be in the Past Rescinded Offset range. Make sure to provide the appropriate number of days in the Past Rescinded Offset field.

Resolution: Make sure Effective Date Offset is either empty or a non-zero integer value per the requirement. Do not set it to 0.

Resolution: The Workday connector requires the following schema attributes and associated XPaths for aggregation:

• HIREDATE - Required for Aggregating Active Worker

• TERMINATION_DATE - Required for Aggregating Terminated Worker

• CONTRACT_END_DATE - Required for Aggregating Contract Terminated Worker

• FILENUMBER - Unique Identity of the Worker

  Do not remove these attributes and their XPaths from the application XML.

Resolution: This only occurs if Daylight Saving Time is in sync with NTP server and time zone is other than PST. PST is the default time zone which is handled by Workday APIs. Whenever daylight savings occurs, make sure that the installed VA server (if additional proxy configuration) is in sync with NTP server and NTP server has applied daylight savings.

Example: A new hire’s identity is removed during a Workday aggregation that occurs the day before the new hire starts. When the next Workday aggregation occurs, the identity is added once more.

This behavior is caused by a mismatch between the Workday connector’s Effective Time Zone configuration value within IdentityNow and the timezone in which the HR data (Hire, Termination, Re-hire, and Conversion) is processed.

Within IdentityNow, the Workday connector's Effective Time Zone must be set to the same timezone in which the HR data (Hire, Termination, Re-hire, and Conversion) is processed.

For example, if the HR data is processed in the Central timezone, then the Effective Time Zone field (on the Connection Settings page) must be set to America/Chicago.

All valid time-zones are supported for the Effective Time Zone field. The following are some of the examples:

• America/New_York

• America/Los_Angeles

• America/Chicago

• PST

• HST

• Asia/Dubai

• CET

• GMT

• ACT

• Australia/Melbourne

Note
If the Effective Time Zone field is left blank, the timezone defaults to UTC.

Resolution:

1. Go to Admin > Connections > Sources.

2. Open your Workday connector.

3. On the Connection Settings page, locate the Effective Time Zone field.

4. Set the Effective Time Zone value to the timezone in which the HR data is processed.

5. Save the change.

During the initial aggregation the connector dynamically updates the source configuration with the ID to name mapping based on the Workday configuration.

Resolution: If some mappings have not been updated and the account is being populated with an ID, you can run a non-optimized aggregation. If needed, remove the following entries from the source config using the API and then run a non-optimized aggregation for a clean start.

• ReferenceIDMap

• Entries from the XpathAttributesMap:

  • (Phone Reference IDs) WORK_MOBILE, WORK_TELEPHONE, HOME_MOBILE, and HOME_TELEPHONE

  • (Employee Type Reference ID) EMPLOYEE_TYPE

  • (Contingent Worker Type Reference ID) Contingent_Worker_Type

It is observed that some of the tenant has the Phone Device Type ‘Telephone’ is defined on the workday manage system as ‘Landline’ due to which the mapping in the application forms as below.

This is incorrect as the connector will specifically look for ‘Telephone’ key which is not in the list and will use default device ID-1063.5 to update the land-line number which is not present and will throw the error.

Resolution Change the mapping for ‘Landline’ as below:

"Phone_Device_Type_ID": {
"Telephone": "Landline",
"Mobile": "Mobile",
}

By default, the connector adds below the business in delta event list while preparing the request. Hence, there is no need to add below business process in the <Delta_Event_List> additionally.

• Hire Employee

• Terminate Employee

• Contract Contingent Worker

• End Contingent Worker Contract

Explanation:The above error message appears as the Workday connector uses the default phone device reference ID. The phone device reference ID varies according to the tenant. The Workday connector contains a ReferenceIDMap that contains phone device type id map.

Resolution: To change the reference ID of a specific phone device type, modify the Phone_Device_Type_ID map as follows using the IdentityNow REST API:

PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID}[ { "op": "add", "path": "/connectorAttributes/ReferenceIDMap", "value": {"Phone_Device_Type_ID":{"Mobile":"Mobile","Telephone":"Landline"}} }]

Below steps mentioned the way to check and retrieve the Phone_Device_Type_Reference_Id:

1. Search Maintain Reference IDs Task.

2. Select Business Object as - “Phone Device Types” → select None of the above.

3. Select OK The Reference ID values of Phone Device type ID are listed.

For more information on IdentityNow APIs, refer to Best Practices: IdentityNow REST API Authentication and IdentityNow REST API - Update Source (Partial) in the SailPoint Developer Community.