Workday

This connector exports users and groups from a Workday instance.

This page is about ERP/Workday.

Prerequisites

Implementing this connector requires:

• using Workday Web Services (WWS) Directory v34.2 or later;

  For example, the Human Resources Web Service contains operations that expose Workday Human Capital Management Business Services data, including Employee, Contingent Worker and Organization information.

• access to the Web Services you plan to use;

• the XPath syntax to configure and select the attributes to export.

Export

This connector exports any entity available in WWS.

Configuration

Configure this process through a connection in the UI and/or the XML configuration, and in the appsettings.agent.json > Connections section:

appsettings.agent.json
{
  ...
  "Connections": {
    ...
    "<ConnectionIdentifier>": {
      ...
    }
  }
}

The identifier of the connection and thus the name of the subsection must:

• be unique.
• not begin with a digit.
• not contain <, >, :, ", /, \, |, ?, * and _.

The following example connects Usercube to Workday and exports Worker_ID and User_ID from the entity Workers returned in Get_Workers_Response:

appsettings.agent.json
{
  ...
  "Connections": {
    ...
    "WorkdayExport": {
        "InputFilePath": "C:/identitymanagerContoso/Temp/bodies.json",
        "Login": "USERCUBE@contoso",
        "Password": "contoso1996",
        "Server": "https://workday.com/ccx/service/contoso"
    }
  }
}

Setting attributes

Name	Details
InputFilePath required	Type String Description Path of the JSON file defining which entities and attributes to export. For the file structure, see InputFilePath.
Login required	Type String Description Login used to authenticate to Workday.
Password required	Type String Description Password used to authenticate to Workday.
Server required	Type String Description URL of the targeted Workday instance. Syntax:https://####.workday.com/ccx/service/tenantName (without the Web Service part).

InputFilePath

The file specified in InputFilePath must have a specific structure, with a section for each entity to export.

For example:

bodies.json
{
  "Requests": [>     {
      "XmlBody": "<soapenv:Body> <bsvc:Get_Workers_Request> </bsvc:Get_Workers_Request> </soapenv:Body>",
      "EntityName": "workers",
      "IncrementalTag": "Transaction_Log_Criteria_Data",
      "WebService": "Human_Resources/v34.2"
    }
]
}

Name	Details
XmlBody required	Type String Description Request to send to the Web Service. Syntax: "XmlBody": "<soapenv:Body> <bsvc:Get_Entity_1_Request> ... </bsvc:Get_Entity_1_Request> </soapenv:Body>" - the request body must begin with <soapenv:Body> and end with </soapenv:Body>; - inside the body, the entity request must use the namespace bsvc; - the body must fit on a single line. Tip: write the body in a separate XML file, then replace each line break with a space. You can use your text editor's find-and-replace or a third-party tool of your choice. Tip:see an example.
XPaths optional	Type String Pair List Description One or several key-value pairs, where: - the key is the attribute name that will be the column name in the output CSV file; - the value is the XPath used in the response to get the attribute value. Info: useless most of the time because entity type mappings and entity association mappings provide the information. Still useful when using the exe directly. Note: NETWRIX recommends using an XPath to the property WID, because it helps logs (in Trace mode) find entities with multi-valued properties. Syntax: "XPaths": { "Attribute_1_Name": "XPath 1", ... "Attribute_N_Name": "XPath N" }
EntityName required	Type String Description Name of the entity, which conditions the name of the output file. See the Output details section.
IncrementalTag optional	Type String Description XML tag associated with the incremental request. Note: in the xml request, <bsvc:IncrementalTag> must be the parent of <bsvc:Transaction_Date_Range_Data> which is the parent of <bsvc:Updated_From> and <bsvc:Updated_Through>. Note: when not specified, the connector always exports this entity in complete mode. Warning: don't add the IncrementalTag part manually in XmlBody because the connector adds it automatically when exporting in incremental mode.
WebService required	Type String Description Name and version of the Web Service.

Output details

This connector generates the following to the ExportOutput folder:

• one CSV file for each entity, named <connectionIdentifier>_<entityName>.csv, with the following columns:

  • Command: used for PrepareSynchronizationTask;
  • one column for each XPath found in the entity type mappings' connection columns and entity association mappings' columns. See Workday's documentation to compute XPaths.

  <connectionIdentifier>_<entityName>.csv
  
  Command,Key_XPath_1,Key_XPath_2,...,Key_XPath_N
  Add,value1,value2,...,valueN

• a cookie file named workday_<connectionIdentifier>_cookie.bin, containing the time of the last export to perform an incremental export.

  You can run most exports in complete mode, where the CSV files contain all entries, or in incremental mode, where CSV files contain only the entries modified since the last synchronization.

  A task can use the IgnoreCookieFile boolean property, and a command line (with an executable) can use the option --ignore-cookies.

For example, with the following configuration:

<EntityTypeMapping Identifier="Workday_Worker" Connector="Workday" ConnectionTable="WorkdayExport_workers">  <Property Identifier="Worker_ID" ConnectionColumn="bsvc:Worker_Data/bsvc:Worker_ID" IsUniqueKey="true" />  <Property Identifier="User_ID" ConnectionColumn="bsvc:Worker_Data/bsvc:User_ID" IsUniqueKey="true" /></EntityTypeMapping>

This example exports only the entity workers, so the connector generates the output to WorkdayExport_workers.csv in the directory ExportOutput.

The CSV file will include three columns: Command; bsvc:Worker_Data/bsvc:Worker_ID and bsvc:Worker_Data/bsvc:User_ID.

Authentication

Credential protection

You can protect data through:

• RSA encryption, configured in the appsettings.encrypted.agent.json file;
• an Azure Key Vault safe;

Attribute	Naming Convention for the Key in Azure Key Vault
InputFilePath	Connections--<identifier>--InputFilePath
Login	Connections--<identifier>--Login
Password	Connections--<identifier>--Password
Server	Connections--<identifier>--Server

• a CyberArk Vault able to store Workday's Login, Password and Server.

Usercube stores protected attributes inside a safe in CyberArk, in an account whose identifier it retrieves from appsettings.cyberark.agent.json.

For example:

appsettings.cyberark.agent.json
{
  ...
  "Connections": {
    ...
    "WorkdayExport": {
        "Login": "WorkdayExport_Account",
        "Password": "WorkdayExport_Account"
    }
  }
}